Stuck removing the Password on t5577

mwalker · 2019-05-14 12:39:05

I am sure this has been addressed but as yet I cant seem to find the answer.

I am playing with a cheap cloner (blue) and t5577 cards running as em4100

As we know these cheap units do some things to make life interesting.
So, that said, what have i done.

I have a Proxmark 3 Easy - Lastest firmware as published (binary) win64 and have flashed the unit.

I can create a em4100 tag on both a stock rfid unit and also on the PM3, so I know both are reading and writing ok.
Antenna tune looks ok.
With the em4100 (on the t5577) no password set, i can read the t55 blocks and update as needed, so again no issue reading/writing.
if i clone a "blank" config with the cloner it sets the password, which I can then remove as needed on the pm3, so I know I can to that.
Note: the blank config allows me to read Block 7 and it is the same password as i decoded.

I took a sniff of the em4100 copy/write to the t5577
Very happy with the decode.
Very happy with the password being stock : 51243648
The config line set was : 00148252
which I believe is as follows
   Master Key    None
   Data Rate    RF/64
   Modulation    Manchester
   PSKCF    RF/2
   AOR (request)    Yes
   Max Block          2
   PWD       Yes

I assume Manchester is ASK (?) as thats the same as the non password card and works with ASK RF/64
When I set the lf t55 config to the above, I can send a command and get a constant response from the card.
The response is the same, so i assume its the "em4100" tag response and not an actual t55 block read.

99% of the time my attempts to reset the config to remove the password and AOR flag does nothing.
I have tried the following... I have also tried the lf t55 wake <password> then the write block 0 as below
lf t55 write b 0 d 00148040 p 51243648 t
lf t55 write b 0 d 000880E8 p 51243648 t
lf t55 write b 0 d 00148040 p 51243648
lf t55 write b 0 d 000880E8 p 51243648

Every now and then I managed to reset block 0, so go back through my history to see what I did, then try to repeat with no luck
So, I believe that I just some how leave the software/unit in a state that then accepts the write.

One thing I did notice is the cloner had the following bit stream prior to the write commands.
00000000000010000000000000000000000000000000000000000000000000010000000010
I was wondering if that was the write/start gap sequence for the t5577
were it expects some 0's then a 1 where the number of zeros is between 8 and 50

For reference, this was my decode of the write.

S OP <---- Password ----> L <---- User Data ----> adr
0 10 0101 0001 0010 0100 0011 0110 0100 1000 0 0101 0001 0010 0100 0011 0110 0100 1000 111 <- P0 B7 : Password write
5 1 2 4 3 6 4 8 5 1 2 4 3 6 4 8

1 10 0101 0001 0010 0100 0011 0110 0100 1000 0 0101 0001 0010 0100 0011 0110 0100 1000 111 <- P0 B7 : Password write
5 1 2 4 3 6 4 8 5 1 2 4 3 6 4 8

1 10 0101 0001 0010 0100 0011 0110 0100 1000 0 0000 0000 0001 0100 1000 0010 0101 0010 000 <- P0 B0 : Config
5 1 2 4 3 6 4 8 0 0 1 4 8 2 5 2

1 10 0101 0001 0010 0101 0011 0110 0101 1000 0 1111 1111 1101 1010 0101 0001 1000 1011 001 <- P0 B1 : EM Data
5 1 2 4 3 6 4 8 F F D A 5 1 8 B

1 11 0101 0101 0010 0101 0011 0110 0100 1000 0 1111 1111 1101 1010 0101 0001 1000 1011 001 <- P1 B1 : EM Data/Config ??
5 1 2 4 3 6 4 8 F F D A 5 1 8 B

1 10 0101 0001 0010 0100 0011 0110 0100 1000 0 1101 1110 1100 0110 0010 1001 0101 0010 010 <- P0 B2 : EM Data
5 1 2 4 3 6 4 8 D E C 6 2 9 5 2

I feel that i am missing something very simple or have not set something prior to the write b 0. I am happy to read, so any pointers or hints would be great.

Thanks

iceman · 2019-05-14 12:44:01

I suggest you read Tom's excellent post on Dangerous things forum.

https://forum.dangerousthings.com/t/xem … oners/1547

mwalker · 2019-05-14 13:34:23

Thanks for the link.
I have seen that and tried all of that, no go.
I am using cards so less of an issue with the antenna.
The lf t55 trace shows nothing or incorrect modulation.
I think there is something with the block 0 config. as the x config bit is not set, as such the inverse data bit should be 0 (n/a), but the inverse bit is set.
I would assume the modulation etc should all be stock em4100, so I did an t55 detect on the original card to set the values for the t55 config.
I will keep looking as there must be a way as the cloner can do it.

One thing i do note is when ready ANY data its the same and will loop with the read offset bits
As such I am thinking this is NOT the data we are trying to read, rather the em4100 tag response as we have not put the 5577 into downlink mode.

Last edited by mwalker (2019-05-14 13:40:55)

mwalker · 2019-05-15 05:17:12

Time for some testing and playing.

OK, the important bit upfront: I fully understand that playing with what gets sent to the card COULD lock the card and or blocks with a permanent fuse write. Since this is test/dev... time to break something.

My thinking at the moment, (as per above) is that we need to send a "wake up and go into downlink mode" signal.
This should be achieved by sending a "1" bit then some zeros (8-50) then a 1 bit i.e. something like the above leading bit stream.

So, to check I am looking in the correct place, could someone check the following and let me know if it sounds about right (high level)
Note: I am not asking for code or if it sounds like a good idea (we can discuss that based on my outcomes), just a sanity check and if i need to consider anything else. This is about the approach to change the code, compile and test with what what I want to do as the reference.

Code changes (for T5577)
From looking through the source code the proxmark3.exe file will format and upload 4*32bit blocks of data to the OS/Firmware on the card.
Then the firmware will work out what to write and send to the fpga.

So I would need to set the flag in the proxmark3.exe and also update the os function to implement the action i want, if the flag is set.

If i wanted to add an option to the t55xx write

- Update proxmark3.exe : "cmdlft55.c"
Function : CmdT55xxWriteBlock

Set option flag in the UsbCommand->asBytes[0]
bit 0 0x1 : Use PWD
bit 1 0x2 : page
bit 2 0x4 : Test Mode

Are there others ?
i.e. for my test/dev can I use bit 7 0x80 ?

- Edit Firmware OS "lfops.c"
Function : T55xxWriteBlockExt

something like
bool Test1 = arg & 0x80;

then at the correct place for my test

if (Test1) {
.... do what I want to test
}

Is there something else I need to consider ?

If I am only changing the OS image, I assume that it will either work or wont and the boot loader will allow me to re flash.
If that all goes down hill, then I can jtag the boot loader back and re flash some good firmware.

Again, I fully acknowledge that I can brick the t5577.

Thanks

iceman · 2019-05-15 06:47:50

yes, the flags byte is the perfect place to set your own flag. 0x8 would be the next free available flag, bits 3-7 is still unused.
you will flash fullimage. No need for bootrom.
If you don't touch bootrom, you will always be able to flash a new fullimage.

mwalker · 2019-05-18 07:37:02

I have spent a fair amount of time tuning my skills at snooping and decoding the data.
I now believe I have a fairly good capture and decode of the write of the data by the cloner to the card.

Every thing looks as I would expect it to be, but I still cant update the card when I know the password, yet the cloner can.

The config on Page 0 Block 0 is 100% what I would expect, limit max blocks and set the password, infact all page 0 is as expected.
No blocks written have the lock bit set.

The interesting thing is the update of Block 3 Page 1, it sets Option key to 6 and Long Leading Reference as the demod delay.
Also the Page 1 Blocks 1 and 2 are a copy of the EM Tag Data (same as Page 0 block 1 and 2).

From the tech sheet:

If Option Key is 6 or 9, the front end options are activated; for all other values they take on the default state (all 0). If Option
Key is 6 then the complete page 1 (i.e., option register and traceability data) cannot be overwritten by any Test Write Command.
This means, 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.

So, yes its 6, so the front end options are active, I read that as if it was not a 6 or 9, it ignores these settings (and uses all 0).
So 6 is set which also means all Page 3 CAN be locked (and lock out the test write), but since they did not have the lock bit set, they should be open to change (via the test write command).

So, at this point I am thinking it has something to do with the long leading reference.

In my snoop, prior to the commands to the card, i have some unknown data. I expect some will be noise and some miss-decoded bits, but there is a fair amount.

I suspect that the card is sending its "EM Tag ID" when every it does not like a command (and resets back to read mode).

Any ideas, hints or tips ?

Thanks

mwalker · 2019-05-19 01:07:08

Some more information.
I feel I am very close.
First, some updates/corrections. While most of my data was good, it was not 100% perfect. A snoop with the card present added noise to the snoop data. The snoop with just the cloner writing is much cleaner. I believe this is due due to the card sending its Tag ID or just drawing power affecting the field during the snoop, does that sound correct ?

A new very clean snoop (there is more data, but this should be enough)
Everything but the very first line looks 100% as expected, so very happy with my snoop and decode.
The two things of interest.
The very first packet sends a 011 (a different snoop of the send "blank" had 110) These bits are very clear in the wave form.
After the first 3 bits, the rest is the same for all card writes (outside of tag id data values).

The 2nd bit of interest is the tailing "1" bit. I assume this is a stock bit at the end of a packet ?

011 00 01010001001001000011011001001000 0 00000000000000000000000000000000 011 1 Test mode write to block 3
10 01010001001001000011011001001000 0 01010001001001000011011001001000 111 1 Set Password (Page 0 Block 7)
10 01010001001001000011011001001000 0 01010001001001000011011001001000 111 1 Set Password (Page 0 Block 7)
10 01010001001001000011011001001000 0 00000000000101001000000001010000 000 1 Set Config 00148050
10 01010001001001000011011001001000 0 11111111110100101000001100101001 001 1 Tag ID Data (Page 0 Block 0)
11 01010001001001000011011001001000 0 11111111110100101000001100101001 001 1 Tag ID Data (Page 1 Block 1)
10 01010001001001000011011001001000 0 10010010101001100011111000110000 010 1 Tag ID Data (Page 2 Block 0)
11 010100010010010..... More data not sampled @ lf config d 1 ....

So assuming that to "update" the T5577 blocks, if it is in leading 0 mode (as per what is set via my cloner), then we need to send those bits.

Questions:
With a test mode write (00) does that apply to Page 1 ? i.e. the first command is sending 00's to Page 1 Block 3, so to clear its settings makes sense. Then the rest of the commands are in stock write mode.

I have tried sending those bit patterns, but no go.
i.e. In function T55xxWriteBlockExt, i used T55xxWriteBit(x); for each of the three bits. The snoop does not show any gaps or weird lengths so could not see any need to tweak anything there.

Pending new information, I am down to one of a few things.

1. The code changes I am making is not doing what I think its doing (I know its running the code). Is there a way to get the snoop wave form if the PM3 does the write? If not, i have me RDV4 coming soon so will use that.

2. Its a timing issue (e.g. not waiting long enough before sending the clear config packet, or waiting too long and card is resetting after timeout (same snoop as in 1 would help check this)

3. I am missing something

Thanks

mwalker · 2019-05-19 09:55:32

First up, some house keeping. Admin: This may be better in the 125 kHz section.

For those following the story and the newbies trying to learn.
So, getting the right data from the card is important. An extra bit here and there makes a big difference.
With my new skills and knowledge, I went back to the start to check everything again... mostly right.

As the card was in leading zero mode, i missed the key bit in the tech sheet every time I read it.

From my prev. post, the first command sent, is now fully understood.

0 11 00 01010001001001000011011001001000 0 00000000000000000000000000000000 011

0 leading 0 byte for leading 0 write
11 Page 1 Write
00 "fixed 0 in leading zero"
<32 bit password> <1 lock bit> <32 bit data> <3 bit addr (3)>

So it is a write all 0 to the config block on page 1. This would then clear the leading 0 mode for the remainder of the updates.

So now that's understood, i started to work on the code to send the leading 0 write command.
Good news and, well, some not so good news.
My code DID manage to change the card - Yeah, it made a difference - so i know i am now in the right area
Bad news... i forgot the 00 between the op code and password... so my testing would have had some interesting results.

While the smart people are most likely laughing at this point, I am now trying to see if the 2 cards can be revived.

I completed this on 2 cards just to make sure it was not some random thing, so the fact that both are in the same mode means things did what I told them.

The cards now seem to accept normal commands, and when I write things change, just in a very weird way.
The plot signal is a triangle wave (very sharp).

Happy to burn a few cards, but would be nice to revive and re-use.

Edit: My code can now reset the config and allow the removal of leading 0. I can then remove the password and block limit (with the sniffed password) and then dump the other blocks.

Yeah...

Last edited by mwalker (2019-05-19 10:25:45)

iceman · 2019-05-19 10:08:00

[moved]

mwalker · 2019-05-20 09:56:17

I managed to get my cards "un-bricked" so bonus

Bottom line, since I could see the data was changing with the write commands, I crafted the config blocks for Page 0 block 0 and Page 1 block 3 (stock t5577) and sent them as normal lf t55 writes and bingo.. open clean cards again....

So all in all a productive weeked.

Proxmark3 community

Announcement

#1 2019-05-14 12:39:05

Stuck removing the Password on t5577

#2 2019-05-14 12:44:01

Re: Stuck removing the Password on t5577

#3 2019-05-14 13:34:23

Re: Stuck removing the Password on t5577

#4 2019-05-15 05:17:12

Re: Stuck removing the Password on t5577

#5 2019-05-15 06:47:50

Re: Stuck removing the Password on t5577

#6 2019-05-18 07:37:02

Re: Stuck removing the Password on t5577

#7 2019-05-19 01:07:08

Re: Stuck removing the Password on t5577

#8 2019-05-19 09:55:32

Re: Stuck removing the Password on t5577

#9 2019-05-19 10:08:00

Re: Stuck removing the Password on t5577

#10 2019-05-20 09:56:17

Re: Stuck removing the Password on t5577

Board footer