ata55x7 test mode

marshmellow · 2017-04-03 03:20:00

does anyone have any information on the ata55x7 (t55x7) test mode commands? and how you enter test mode?

the chip datasheets tease some information:

AFE set-up:
Notes: if the option key is 6 then the complete page 1 cannot be overwritten by any test write command. This means that if the lock bits of the three blocks of page 1 are set and the option key is 6, then all of page 1's blocks are locked against change.

reading between the lines this means that even if the lock bit is set there may be a test write command that can still overwrite it.

it also specifies that test mode access is enabled unless the "master key" of the config block is 6.

it also says

test-mode access allows re-configuration of the tag

and finally

The fourth opcode "01" precedes all test mode write operations. Any test mode access is ignored after master key (bits 1 to 4) in block 0 has been set to "6". Any further modifications of the master key are prohibited by setting the lock bit of block 0 or the OTP bit.

but I haven't been able to find any indication of what commands are supported
or if there is any physical access to pins on the chip required to start test mode.

so, has anyone found anything on this before?

0xFFFF · 2017-04-03 04:44:13

Looks like you already have the same information as what I've got on hand.

AT5567 in Extended Mode (X-mode)
In general, the block 0 setting of the master key (bits 1 to 4) to the value "6" or "9" together with the X-mode bit will enable the extended mode functions.
● Master key = 92: Test mode access and extended mode are both enabled.
● Master key = 6: Any test mode access will be denied but the extended mode is still enabled.
Any other master key setting will prevent the activation of the AT5567 extended mode options, even when the X-mode bit is set.

ATA5577C in Extended Mode (X-mode)
In general, setting of the master key (bits 1 to 4) of block 0 to the value 6 or 9 together with the X-mode bit will enable the
extended mode functions such as the binary bit-rate generator, OTP functionality, fast downlink, inverse data output and
sequence start marker.
● Master key = 9: Test mode access and extended mode are both enabled.
● Master key = 6: Any test mode access will be denied but the extended mode is still enabled.
Any other master key setting will prevent activation of the Atmel® ATA5577C extended mode options, even when the Xmode
bit is set.

Might be worthwhile trying to get a few SO8's? The pin configuration indicates that the test pins are not connected. Might be worthwhile checking how true that is?
There are 5 unexposed pads on the die for testing (including Vdd, Vss). I have a few potted Txxxx ICs somewhere. I'll decap one or two to see if I can find them.

marshmellow · 2017-04-04 15:19:02

hmmm... well i made my t5577 chip mad.
https://pastebin.com/KwhhAmUu

it appears testmode does NOT need physical access to any pins. just send the right command..

unfortunately i cannot get out of it. resetting the tag does not turn test mode off.

Edit... i found the testmode command i stumbled on actually wrote block 0 to all 1s even though block 0 was locked... rewriting block 0 restored the tag.

marshmellow · 2017-04-04 15:43:20

hmmm.. testmode has interesting results. it can write locked and pwd protected tags...

marshmellow · 2017-04-05 02:11:10

Unfortunately it appears it is designed to overwrite the entire memory. So any and all data on the tag is lost upon a single successful testmode write.

And if there is a testmode read i have not found it...

Btw I implemented testmode write as an option to lf t55xx write in my fork.

0xFFFF · 2017-04-05 02:25:36

Nice!
Good to see that physical access is not required.
I'll have check it out

Flintstone.S · 2017-04-05 12:16:43

@Marshmellow

Very nice indeed!

When the tag is overwritten in test mode what are the new contents and configuration block settings?
Did you just try to write only 32 bits to block 0?

I'll have to check it out myself but not able atm.

Thanks!

marshmellow · 2017-04-05 14:35:31

the following is an example:

start with a blank tag:

proxmark3> lf t5 det
Chip Type  : T55x7
Modulation : PSK1
Bit Rate   : 2 - RF/32
Inverted   : No
Offset     : 57
Seq. Term. : No
Block0     : 0x00081040

proxmark3> lf t5 dump
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | 00000000 | 00000000000000000000000000000000
  2 | 00000000 | 00000000000000000000000000000000
  3 | 00000000 | 00000000000000000000000000000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000
Reading Page 1:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | 00000000 | 00000000000000000000000000000000
  2 | 00000000 | 00000000000000000000000000000000
  3 | 00000000 | 00000000000000000000000000000000

now use testmode to write block 0

proxmark3> lf t5 write b 0 d 87654321 t
Writing page 0  block: 00  data: 0x87654321
#db# TestMODE
proxmark3>

Write block 0 back to something we can read:

proxmark3> lf t5 write b 0 d 00081040
Writing page 0  block: 00  data: 0x00081040
proxmark3> lf t5 det
Chip Type  : T55x7
Modulation : PSK1
Bit Rate   : 2 - RF/32
Inverted   : No
Offset     : 57
Seq. Term. : No
Block0     : 0x00081040

dump all memory

proxmark3> lf t5 dump
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | 0ECA8642 | 00001110110010101000011001000010
  2 | 1D950C84 | 00011101100101010000110010000100
  3 | 3B2A1908 | 00111011001010100001100100001000
  4 | 76543210 | 01110110010101000011001000010000
  5 | ECA86421 | 11101100101010000110010000100001
  6 | D950C843 | 11011001010100001100100001000011
  7 | B2A19087 | 10110010101000011001000010000111
Reading Page 1:
blk | hex data | binary
----+----------+---------------------------------
  0 | 00081040 | 00000000000010000001000001000000
  1 | 6543210E | 01100101010000110010000100001110
  2 | CA86421D | 11001010100001100100001000011101
  3 | 950C843B | 10010101000011001000010000111011
proxmark3>

strange... takes given data and programs first block you send and then for each succeeding block it bitshift left the data and programs that data.

Flintstone.S · 2017-04-05 15:08:22

Very interesting.
What about if you try to write block 0 with something that we can read immediately after(instead of 87654321) and be able to make the dump without the need to reverse the block 0 back to original settings.

For example:
lf t5 write b 0 d 000880E8 t

then dump:
lf t5 dump

I feel this way we may get clearer image of what is going on...

marshmellow · 2017-04-05 15:31:49

i'll do 1 better, by altering the amount of time the antenna is on after the write i can limit it down to programming just one block (when programming block 0) unfortunately it appears the first step of this command is to wipe the data on all blocks then write the data sent.

but this works good as a wipe command (as long as you don't mind losing the tracability data)

i'm still testing different times. and when the timing is different changing the block # appears to do strange things...

Flintstone.S · 2017-04-05 16:05:49

Yeah, the test mode could at least work for people who want to reuse some password protected tag without needing the password. That's great news anyway.

BTW I was able to implement the 01 opcode on another T55xx reader and it did exactly the same thing as you with PM3.

I'm afraid it is not the command that wipes the data. This maybe the way the chip is supposed to react on test mode ... wiping itself entirely.

Very intersting and intiguing topic you started!
Looking forward to your further findings.
Cheers!

marshmellow · 2017-04-05 17:16:15

i can confirm, as soon as a testmode command is accepted the whole tag is wiped to 0's. if the test mode is not accepted nothing is changed.

Flintstone.S · 2017-04-05 18:06:09

Are you stopping the antenna after opcode 01, before sending any other data to write?

marshmellow · 2017-04-05 19:47:45

just the opcode 01 is not accepted as a valid command. it has to be accompanied by the full write command
(the standard direct read command with 01 opcode does not seem to be valid either)

so after the last bit of the write command is done i can wait 5184us (probably with some leeway) then turn off the antenna and it will only re-program one block (if that block is block 0)

Flintstone.S · 2017-04-05 20:12:10

If you manage to write just one block "0" this will be amazing...

marshmellow · 2017-04-05 20:38:30

Unfortunately I cannot seem to prevent the wipe.

Flintstone.S · 2017-04-05 21:24:02

Pardon maybe a dumb question, but why do you have to wait 5184us before turning off the antenna?
"Each transmission of the direct access command (two opcode bits, 32-bit password, "0" bit plus 3 address bits = 38 bits) needs about 18 ms."
... which should be about the same for the test mode write.

marshmellow · 2017-04-05 21:34:55

18ms = 18000us

marshmellow · 2017-04-05 21:35:54

And the 18ms is for the old q5 not the newer chips. They complete in about 5.6ms.

Flintstone.S · 2017-04-05 21:59:03

Ooops my bad. I missed one 0 while considering...
The 18ms quote is from a T5567 datasheet, but it is not doing any good if the memory is wiped for 5.6 ms

marshmellow · 2017-04-05 23:00:04

i'm mainly working with ata5577c chips. results will vary per chip for the timings.

i have found that the block variable does some interesting items (with the 5184us cutoff applied)
block set to 0-3 writes set block with sent data.
block set to 4 or 6 (4bit set and 1 bit not set) it writes every other block starting with block 0 with sent data
block set to 5 or 7 (4bit set and 1 bit set) it writes every block with sent data.
(all within the 5184us)

Flintstone.S · 2017-04-06 09:35:01

Wierd things happen.

Unfortunately there is very limited information published about test mode.
What we can say for sure is that the test mode is not working the way it is described in the blueprints, not adhering to the "stated" limitations and the supposed operation logic.
This makes me think that test mode is just intentionally obscured flaw(backdoor), which is worth exploring more and more.

I now have your implementation of the test mode and my PM3 flashed, so it is ready for beta testing.
Unfortunately I'm not aware how to cut antenna power like you do.
I have few password protected cards and will soon get more, and they will be put under stress.

What about cutting off the antenna even earlier? What is the time limit where the completion of the command will be impaired?

I don't know how easy this could be to do, but maybe inroducing an intentional Error or Reset after the command may produce other results?!?

marshmellow · 2017-04-06 13:29:40

In the little bit testmode is mentioned it hints to the functionality I have confirmed. As I showed in the first post here, testmode was intended to ignore lockbits and passwords.

It is designed for chip testing at the factory. They carefully suggest setting the config to disable testmode in multiple places.

There has been no flaw exposed yet. Especially since it always wipes before it writes.

On the t5577 I can confirm changing the timing of the antenna off cannot prevent the wipe. (It can break the command entirely, or it wipes there is no in-between in my tests). Btw the wipe happens in under 600us way before the write block.

If you add bits sent that are not part of the command format it breaks the command and the chip does nothing.

There may be a different command structure that works differently but there may not be.

My next push will adjust the timing of the test cmd to the 5184 as this appears to be most useful and controllable.

Feel free to test more, results may vary on older chips.

iceman · 2017-04-08 19:47:36

bit jitter in the first 600us by turning off/on antenna might introduce some funny writes on the tag ?

marshmellow · 2017-04-13 06:11:10

Unlikely. Modulating the antenna is likely to just make the tag see an invalid command. I tried sending various bits after the last bit of the cmd and it always resulted in the tag ignoring the cmd.

Due to the timing I think the chip is hard wired to wipe bits upon a successful testmode command being accepted.

That is the only explanation I can see how it writes all blocks so quickly with 0s. Especially when a single block write takes almost 10 times longer.

iceman · 2017-04-14 01:02:34

Didnt mean when sending the signal, introduce jitter in power (antenna) during tag command execution.

anybody · 2017-04-22 22:51:36

marshmellow, you wrote

marshmellow wrote:

just the opcode 01 is not accepted as a valid command. it has to be accompanied by the full write command
(the standard direct read command with 01 opcode does not seem to be valid either)

Do I understand correctly that to write a block 0 in test mode, I have to send
StartGap-0-1-StartGap-1-0-L-data(32)-Addr(3)

marshmellow · 2017-04-25 02:03:04

Not quite.

anybody · 2017-04-25 13:25:33

Thanks for the answer. I will experiment.

marshmellow · 2017-04-25 14:39:17

Have a look at the code if you are unsure. It is implemented in the pm3 master repo.

anybody · 2017-04-25 21:21:05

Thanks again.

doegox · 2019-10-30 12:21:15

Having fun with test mode : https://blog.quarkslab.com/eeprom-when- … issue.html
Thanks @Marshmellow for having shared your experiments!

marshmellow · 2019-10-30 13:57:33

Well, done. I suspected there was a series of timings that may just do what you've illustrated. But it is still very limited, especially if you have only one tag to attack.

Proxmark3 community

Announcement

#1 2017-04-03 03:20:00

ata55x7 test mode

#2 2017-04-03 04:44:13

Re: ata55x7 test mode

#3 2017-04-04 15:19:02

Re: ata55x7 test mode

#4 2017-04-04 15:43:20

Re: ata55x7 test mode

#5 2017-04-05 02:11:10

Re: ata55x7 test mode

#6 2017-04-05 02:25:36

Re: ata55x7 test mode

#7 2017-04-05 12:16:43

Re: ata55x7 test mode

#8 2017-04-05 14:35:31

Re: ata55x7 test mode

#9 2017-04-05 15:08:22

Re: ata55x7 test mode

#10 2017-04-05 15:31:49

Re: ata55x7 test mode

#11 2017-04-05 16:05:49

Re: ata55x7 test mode

#12 2017-04-05 17:16:15

Re: ata55x7 test mode

#13 2017-04-05 18:06:09

Re: ata55x7 test mode

#14 2017-04-05 19:47:45

Re: ata55x7 test mode

#15 2017-04-05 20:12:10

Re: ata55x7 test mode

#16 2017-04-05 20:38:30

Re: ata55x7 test mode

#17 2017-04-05 21:24:02

Re: ata55x7 test mode

#18 2017-04-05 21:34:55

Re: ata55x7 test mode

#19 2017-04-05 21:35:54

Re: ata55x7 test mode

#20 2017-04-05 21:59:03

Re: ata55x7 test mode

#21 2017-04-05 23:00:04

Re: ata55x7 test mode

#22 2017-04-06 09:35:01

Re: ata55x7 test mode

#23 2017-04-06 13:29:40

Re: ata55x7 test mode

#24 2017-04-08 19:47:36

Re: ata55x7 test mode

#25 2017-04-13 06:11:10

Re: ata55x7 test mode

#26 2017-04-14 01:02:34

Re: ata55x7 test mode

#27 2017-04-22 22:51:36

Re: ata55x7 test mode

#28 2017-04-25 02:03:04

Re: ata55x7 test mode

#29 2017-04-25 13:25:33

Re: ata55x7 test mode

#30 2017-04-25 14:39:17

Re: ata55x7 test mode

#31 2017-04-25 21:21:05

Re: ata55x7 test mode

#32 2019-10-30 12:21:15

Re: ata55x7 test mode

#33 2019-10-30 13:57:33

Re: ata55x7 test mode

Board footer