Some ideas related to the t55xx brute force attact command ...

ntk · 2016-02-24 19:27:00

What is the matter with the password in T55xx.

Iceman Gotus Marshmellow have joined to reproduce a command to find the password in a t55xx fro tthe proxmark3 community. The problem is it is not realistic to run at the moment, if the command has to find the right password amongst the the large amount of over 4 billions possible combinations.

what to do?

ntk · 2016-02-24 19:37:39

a small question for the general understanding of this password problem

we have HEX password contains 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F SO 16 HEX digit, it make a key space of 16^8=4,29 billion password posssible.

According to AT5577 datasheet
"
When password mode is active (PWD = 1), the first 32 bits after the opcode are regarded as the password. They are
compared bit by bit with the contents of block 7, starting at bit 1. If the comparison fails, the Atmel ATA5577C will not
program the memory. Instead it will restart in regular-read mode once the command transmission is finished.

Note: In password mode, MAXBLK should be set to a value lower than 7 to prevent the password from being transmitted
by the Atmel ATA5577C.

Each transmission of the direct access command (2 opcode bits, 32-bit password, “0” bit, plus 3 address bits = 38 bits)
needs about 18ms. Testing all possible combinations (about 4.3 billion) would take about two years."

pressed on " Testing all possible combinations (about 4.3 billion) would take about two years", the 4.3 billions combination is correct.

16^8 / 1/(0.018)/3600/24/365 = 2.4 years is required to try all combination

also the warning "2 years to try ALL combinations" is correct with certain tolerance. Realistic crack? If one day it is a absolutely necessary must to crack such a password, we there are ways need less than 2 yrs, days months maybe but not year because we search for the password and we don't want to run all possible password combinations. Those are two very different things.

I could make the check use less than 2.4 yrs, but that is an other issue. The issue here is the
"Note: In password mode, MAXBLK should be set to a value lower than 7 to prevent the password from being transmitted
by the Atmel ATA5577C."

it could be a noe of a not so smart system ... a key to defeat this .

My question is when PW mode is used the password is stored in the system, and the fob has the PW written in block 7 too. So by the first transmission after the 2 OP code, the 32bits is then checked one bit by one bit, if not matched then the trasmission is imm. broken and fob rejected

What is about the PW bit? where or when it is checked? if the system work only with a PW then it would assume all the fobs belong to the access system with PW should have PW bit set, and armed with the correct PW.
It expects: A correct fob arrive with the correct PW bit set and the correct MDB <7. to start it transmissions and checking

Could the system sense to disregard any fob with no PW bit set?

So, when a fob arrive with PW bit set, but unfortunately this is a rogue fob with MDB bit=7 what will happen? It does not look like the system automatic know the sityuation otherwise there would not be a warning note neccessary.

Could you follow me? This note gives away the weakness. A rogue fob and a snoop and maybe you could defeat it.

ntk · 2016-02-24 19:48:05

In the time you dwell on the part with the note. There is something worth considering:

It says "When password mode is active (PWD = 1), the first 32 bits after the opcode are regarded as the password. They are
compared bit by bit with the contents of block 7, starting at bit 1. If the comparison fails, the Atmel ATA5577C will not
program the memory. Instead it will restart in regular-read mode once the command transmission is finished."

the password is 8 char long, the password in the configuraton block present a 32 bits, and bit by bit it is checked,
If the comparison fails the Atmel ATA5577C will not program the memory. Instead it will restart in regular-read mode once the command transmission is finished.

"Will not program memory, Instead it will restart in regular-read mode once the command transmission is finished."
If at timing point A we sent transmission in with correct PW then t5577 will program memory, when we send function to check memory is reprogrammed, we should see at time pooint B. that is period AB1

If at timing point A we sent transmission in with incorrect PW then t5577 will program memory, once the command transmission is finished, when we send function to check memory is reprogrammed, we should see at time point B. memory changed. that is period AB2

because the "once the command transmission is finished" mechanism, rweardless failed or pass PW, the length of the check period is shielded and looks like it can not be used as any timing indication to see the current combination has so far succeed or not

But, it does not say it renders the reading in general as "unreadable" once the combination check has failed! It does not say if you have no password you can not copy/multiply the fob to 10, 20 exact the to be investigated fob.... Correct or not? Which means it is possible without knowing the password you still can multiply this fob?

What for ... one fob not possible to crack is useless, now why 20x more useless ... you say?

No, If that multiply is possible then it opens the way for the art of a Roman wolf pack total attack to do the job. and it wont need 2.4 yrs to crack the PW. a lot less.

iceman · 2016-02-24 20:34:31

To start,
the pwd is a 32bit value. A unsigned int, not 8 chars.

--BF
the BF is a card only attack, not a reader, not several other cards. If your idea is 20x same fob w pwd and 20 pm3 to BF, yes, that would reduce the time with a factor 20. That is all down to money vs time.

--Sniffing
The easiest way to get the pwd, is to use the pm3 to sniff the traffic between a valid reader and valid tag.
You only need one good trace and you get it.

--Bad configuration
if MAXBLOCKS allows to read block7, you can just read the pwd.

--Attacks on systems
If you have a system (reader and tags) which you want to pentest, sure, you would need to check if it allows for tags without the pwd-bit set. That would be part of your testing process.

This is all your ideas summarized which has little to do with the actual BF implementation.
I mentioned before, finding a better way to enhance the BF is always welcome.
But you need to become much more technical and specific in your ideas for it to be interesting.

ntk · 2016-02-24 22:01:17

it is still boiled down to a password of 8 characters long 11223344, or 1234ABCD, ABCDEF12 etc...

if ABCDEF12 is requested but you test BBCDEF12 then the check will fail at the "B" the first HEX digit/character of the password or "1011" in your definition.

I stay with the readable HEX digit/character definition for a reason, clearly not for enhance the implementation. I am not fantastic or illusionist to think I can enhance the trydetectmechanism to faster, more effective, more sophisticated.

The 4 digit bank PIN, many army safety CODE still rely on 4-digit.

The code breaker exist since how many years and no one can enhance the trydetect-mechanism, even with NASA, the NSA or all the brightest mind at Apple, to crack the screen code of 4 digit, there still be 10000 combinations to test and all those bright heads still just go simple with 0001, 0002, 0003 .... 9999 up and fort (why bother differently? they are good paid, the longer the expert take, the merrier their accounts are)

No, I don't promise a new programming technique or new piece of code which lighteningly finds your password. I only said, if one day necessary must have password, then there is way to cut down the test running time of 2.4 yrs.

and to do that, I have to simply the problem, I stick with the 8 HEX digits, and think how to feed the check system to catch the password (der hase) as quick as possible.

Feed the check system, not enhance the check mechanism or implementation! If I can enhance the tryanddetectmechanism, I am sure I could get the Nobel Price next year, or sitting with the brightest heads at NASA, NSA

They crunch number still one by one and just +1

It is true "... summarized which has little to do with the actual BF implementation". It has none to do with that. You are nice iceman but I can not help you with a better coding mechanism, i dont think any one can.

Last edited by ntk (2016-02-24 22:49:03)

iceman · 2016-02-24 22:07:42

the pwd check rutine inside chip, might stop when it encounters a faulty byte (or bit) in the pwd
but it doesn't respond until a certain amount of time has gone.

It is a counter-measure for simple side-channel attacks.

Proxmark3 community

Announcement

#1 2016-02-24 19:27:00

Some ideas related to the t55xx brute force attact command ...

#2 2016-02-24 19:37:39

Re: Some ideas related to the t55xx brute force attact command ...

#3 2016-02-24 19:48:05

Re: Some ideas related to the t55xx brute force attact command ...

#4 2016-02-24 20:34:31

Re: Some ideas related to the t55xx brute force attact command ...

#5 2016-02-24 22:01:17

Re: Some ideas related to the t55xx brute force attact command ...

#6 2016-02-24 22:07:42

Re: Some ideas related to the t55xx brute force attact command ...

Board footer