I messed up a T5577 tag, is it bricked? [Solved!]

TelxonHacker · 2020-03-01 20:44:55

First off, I was trying to determine if this was a legit t5577 tag, and changed the downlink mode from fixed to leading zero, I then changed the PM3 to use leading zero, but it appears the tag is now corrupted!

[usb] pm3 --> lf t55 info
          
-- T55x7 Configuration & Tag Information --------------------          
-------------------------------------------------------------          
 Safer key                 : 15          
 reserved                  : 15          
 Data bit rate             : 63 - RF/128          
 eXtended mode             : Yes - Warning           
 Modulation                : 0x1F (Unknown)           
 PSK clock frequency       : 3 - (Unknown)           
 AOR - Answer on Request   : Yes           
 OTP - One Time Pad        : Yes - Warning           
 Max block                 : 7          
 Password mode             : Yes           
 Sequence Start Marker     : Yes           
 Fast Write                : Yes           
 Inverse data              : Yes           
 POR-Delay                 : Yes           
-------------------------------------------------------------          
 Raw Data - Page 0          
     Block 0  : 0xFFFFFFFF  11111111111111111111111111111111          
-------------------------------------------------------------

A dump shows that ALL blocks are set to FFFFFFFF in both p1 and p0.

This doesn't change regardless of what I have the downlink of the PM3 set at

I cannot write to any block with the normal write commands, I've even tried writing to B3 P1 with the test mode

lf t55 write b3 1 d 00000000 t

and it won't work. (same for writing block 0 page 0 to 000880e0)

This is a Chinese tag that came with my blue cloner, I did remove the cloner password successfully, and had used it to clone HID tags with the PM3, and it worked fine up until I changed the downlink.

I recovered a genuine Atmel T5577 that had a similar problem by changing the downlink of the PM3 to that of the card, rewriting the card to defaults, and switching the PM3 back to the default fixed downlink, that fails to work on this fob

Is this bricked?

Last edited by TelxonHacker (2020-03-07 16:44:16)

mwalker · 2020-03-01 23:59:35

Maybe, maybe not.
The fact that is spitting out data means its modulating (you can double check this by doing a read then data plot and if there is a wave... its modulating)
So if its modulating then a config of FFs would be invalid.

If you send a command to the card and it cant understand it, it will ignore it and spit out the bit stream for blocks from 1 to max blocks.
i.e. Normal card use

So if you are seeing FF everywhere, then I think this is more likely that the data on the card is FF (blank, sometimes seen as FF when it is 00).
If its modulating data out and lf t55 det does not work, then either the downlink mode is incorrect or it has a password (or both).
In the rrg repo, detect will auto try all downlink modes, else you could try the lf t55 det r 0, then r 1 .. r 3
If all those fail to get a good detect, I expect it will have had the password set (and maybe a different downlink mode).
Since the card is sending out FFs, i expect the password could be 00000000 or FFFFFFFF, but I would leave the FF password to all else has failed as that could brick the card if the password has not been set (but it could be the original password you found).

TelxonHacker · 2020-03-02 00:50:24

Ok, it still sounds promising then.
The only thing that confuses me is, all the other fobs that came with the cloner were able to be wiped, and the block 0 page 0 data and blocks 0-3 of page 1 are as they should be, (on the blank working fobs) only block 1-7 are all FFFFFFFFF

I have tried detect with all downlink modes, I've tried the recover PW with the cloner PW as well as all F and all 0, and still no luck.

Wouldn't all F's in block 0 set invalid options though?

What's odd is, I never modified block 0 directly, at least not to anything other than the default.

I just checked the demod on the graph, and it's showing all 1's, just a series of evenly spaced square waves. I tried with a EM410 tag and got a waveform I'd expect to see, showing the raw binary in the graph.

So if I understand, it's showing that the raw data really is all 1's in binary? (that's what the dump shows too)

Last edited by TelxonHacker (2020-03-02 00:51:15)

mwalker · 2020-03-02 02:41:36

to speed things up, what repo are you using as the commands can be different between the two ?

Note: Since its a wave from, the card is modulating the data.
Since the data is all "1's" then its a good chance that is the data in block 0 to max block.
That would mean it does not like the lf t55 commands and falling back to default mode (which is to send out the programmed data in the programmed modulation).

mwalker · 2020-03-02 09:39:02

an update from some testing.
Sorry for the long post, I am trying to show what I would expect.
I took a real T5577 and wiped it back to default
Next, just to make it clear what I am talking about, I have set blocks 1 and 2 to different data.

[usb] pm3 --> lf t55 det
    Chip Type      : T55x7
    Modulation     : ASK
    Bit Rate       : 2 - RF/32
    Inverted       : No
    Offset         : 32
    Seq. Term.     : Yes
    Block0         : 0x000880E0
    Downlink Mode  : default/fixed bit length
    Password Set   : No

[usb] pm3 --> lf t55 write b 1 d 11223344
[=] Writing page 0  block: 01  data: 0x11223344
[usb] pm3 --> lf t55 write b 2 d aabbccdd
[=] Writing page 0  block: 02  data: 0xAABBCCDD
[usb] pm3 --> lf t55 det
    Chip Type      : T55x7
    Modulation     : ASK
    Bit Rate       : 2 - RF/32
    Inverted       : No
    Offset         : 32
    Seq. Term.     : Yes
    Block0         : 0x000880E0
    Downlink Mode  : default/fixed bit length
    Password Set   : No

[usb] pm3 --> lf t55 dump
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E0 | 00000000000010001000000011100000 | ....
[+]  01 | 11223344 | 00010001001000100011001101000100 | ."3D
[+]  02 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  04 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  05 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  06 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  07 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E0 | 00000000000010001000000011100000 | ....
[+]  01 | FF800000 | 11111111100000000000000000000000 | ....
[+]  02 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....

Next, I will change the downlink mode and re-dump
Note: I did NOT do a re-detect.
So the original detect config is still in play, and it will read the data from offset 32.... ie. 32 bits, so block 2 data

[usb] pm3 --> lf t55 dump
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  01 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  02 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  03 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  04 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  05 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  06 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  07 | AABBCCDD | 10101010101110111100110011011101 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  01 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  02 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  03 | AABBCCDD | 10101010101110111100110011011101 | ....

Now, if I re run the lf t55 det and re-dump. the RRG repo tries all downlink modes and finds the correct one.

[usb] pm3 --> lf t55 det
    Chip Type      : T55x7
    Modulation     : ASK
    Bit Rate       : 2 - RF/32
    Inverted       : No
    Offset         : 32
    Seq. Term.     : Yes
    Block0         : 0x000880E0
    Downlink Mode  : leading zero reference
    Password Set   : No

[usb] pm3 --> lf t55 dump
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E0 | 00000000000010001000000011100000 | ....
[+]  01 | 11223344 | 00010001001000100011001101000100 | ."3D
[+]  02 | AABBCCDD | 10101010101110111100110011011101 | ....
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  04 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  05 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  06 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  07 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E0 | 00000000000010001000000011100000 | ....
[+]  01 | FF800000 | 11111111100000000000000000000000 | ....
[+]  02 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  03 | 90000800 | 10010000000000000000100000000000 | ....

Now lets add the password flag (but leave block 7 as per wipe 00000000)
Now a read of block 0 without correct password (should be 000880F0)
But look at that... its still block 2 data.

[usb] pm3 --> lf t55 rea b 0
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | AABBCCDD | 10101010101110111100110011011101 | ....

now lets detect with password and then use the password to read b 0
Now we can see the correct data.

[usb] pm3 --> lf t55 det p 00000000
    Chip Type      : T55x7
    Modulation     : ASK
    Bit Rate       : 2 - RF/32
    Inverted       : No
    Offset         : 32
    Seq. Term.     : Yes
    Block0         : 0x000880F0
    Downlink Mode  : leading zero reference
    Password Set   : Yes
    Password       : 00000000

[usb] pm3 --> lf t55 read b 0 p 00000000 o
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[=] Safety check overridden - proceeding despite risk
[+]  00 | 000880F0 | 00000000000010001000000011110000 | ....

now lets try a test mode write with the correct downlink mode.
Look at that , the card accepted the command due to the correct downlink mode, but no password and reset. Downlink mode back to default and no password needed. The test mode "t" reset the card. The only thing you need to do is ensure you send it in the correct downlink mode.

[usb] pm3 --> lf t55 write r 2 b 0 d 000880E0 t
[=] Writing page 0  block: 00  data: 0x000880E0
#db# Using Test Mode
[usb] pm3 --> lf t55 det
    Chip Type      : T55x7
    Modulation     : ASK
    Bit Rate       : 2 - RF/32
    Inverted       : No
    Offset         : 32
    Seq. Term.     : Yes
    Block0         : 0x000880E0
    Downlink Mode  : default/fixed bit length
    Password Set   : No

iceman · 2020-03-02 16:37:10

hm.. the reappearing of old data is worrying me.

TelxonHacker · 2020-03-02 16:51:45

Ok, I'm still following you so far. As for my repo, I'm running the latest RRG/Iceman.
I can not get it to detect it at all, and I've used t55 config to set the PM3 to all 4 downlink modes and tried both t55 det and dump, t55 det always fails, and the dump is always all ffffffff.

[usb] pm3 --> lf t55 detect
[!] Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

I've used t55 config to set the modulation to every option, and reran the t55 det with the same result. I kind of think the modulation is set to something impossible, due to block 0 being all F's

Can you change one of yours to all F for block 0 and see if it can be brought back?

If I do a test mode write with every downlink mode, still no change, and if I add a v to verify, I get a return that it can't be verified.

Update: I changed the t55 config to inverted, and it shows all blocks as 0 now, and valid options, but I still can't write any data to the blocks.

[usb] pm3 --> lf t55 config 
    Chip Type      : T55x7          
    Modulation     : ASK          
    Bit Rate       : 2 - RF/32           
    Inverted       : Yes           
    Offset         : 0          
    Seq. Term.     : No          
    Block0         : 0x00000000          
    Downlink Mode  : default/fixed bit length          
    Password Set   : No

Last edited by TelxonHacker (2020-03-02 17:11:36)

iceman · 2020-03-02 17:27:50

does wipe work?

TelxonHacker · 2020-03-02 17:56:20

No, I've tried about all I can think of. Even the blue cloner won't write to it. I've also tried cloning tags to it via the PM3, still no luck

mwalker · 2020-03-02 19:44:20

With the rrg repo, by default (with no r option) it will try all downlink modes with lf t55 det
so if the lf t55 det does not find the card, we are most likely down to 3 options.
1. Password protected
2. Invalid page 0 data (but its modulating)
3. broken/locked card (maybe)

If its a valid T5577 and test mode does not work, then an option to disable test mode will have been set.

See if the password can be found, you could try the lf t55 chk command and/or lf t55 recoverpw (check out the help)

I have managed to set all 0s to the config block. The lf t55 read, lf sea etc all showed a flat line. you can still send commands to the card and it will process it. You just need to remember how the card works.
- Was the command sent in the correct downlink mode ?
--- No, return to default "read" and send out data from block 1 to max blocks.
--- Yes, does the card require a password ?
------ No, process the command
------ Yes, was the correct password supplied ?
--------- No, return to default "read" and send out data from block 1 to max blocks.
--------- Yes, process the command.

I would try the password check and recovery to see if a password can be found. cant do any more harm:)
Also, i would be interested in a dump of the card from lf read (if you are happy to share).
I think the square wave you see is the "0" bits. so if the card was wiped, but somehow the password is set, it could send all blocks inc block 7 which will hold the password, so worth a look.

lf read
data save
then upload to a file share service and post the link.

TelxonHacker · 2020-03-02 21:14:29

Ok, I now have something interesting to report! I have a T5577 in card format that was having similar problems, T55 info showed sector 0 as all F's, so I issued a wipe command, no luck, so I issued a few more wipe commands while moving the card around between writes, and bingo! with the card laying longways across the reader (at 90 degree angle to each other) it reads the card just fine and shows it's a raw T55x7, with the card parallel with the reader, (completely covering it) it shows all F's!?!? This is repeatable every time, card parallel, no go, card at 90 degrees, reads fine.

I tried this with the fob that this post is about, and no luck. I moved the fob to everywhere on the reader I could, held it on it's edge, etc. I have also changed the antenna switches from 125KHz and range to 125 and accurate, and 134 and range/ accurate with no luck.
It seems there's issues with coupling the LC circuits of the tag to the reader. I plan to get a Prox LF ferrite antenna and try that.

Now on to the fob
Here's the dump file from LF readhttps://drive.google.com/file/d/1m7hvUa … sp=sharing

I have also tried the password commands, both using the dictionary, and supplying passwords of FFFFFFFF, 00000000, 11111111, etc. they all fail to find a password.

I believe coupling may be part of it, but I think there's more to it as well.

mwalker · 2020-03-02 21:26:57

Nice to see progress.
What model proxmark to you have?
The newer rdv4 have a high/low Q switch on the lf antenna, if you have one of those try the low Q

TelxonHacker · 2020-03-02 23:45:42

I've tried the switches, no change. Do you see anything in the dump that might show what's up?

mwalker · 2020-03-02 23:55:42

Wont be able to look at the dump until i get home after work (Im in Australia)

TelxonHacker · 2020-03-03 00:03:41

Ah, no problem! I forgot to mention earlier, I have an RDV4

mwalker · 2020-03-03 09:02:06

Had a quick look at the dump, and yep, it looks like all "1"s
If you have the newer RDV4 antenna (which I think you do), I would ensure 125 and 7 for the switches.
For reference, run a hw tune to make sure things look good (I expect it will be ok as the trace is strong).

edit:
if you have a fob, like you found, placement can help.
I find on mine, with the fobs, i get good results if I place it such that the top of the fob is on the case line and one edge.

Try repeating the wipe, detect, test write etc with it in a place where you get a "good" read.

Last edited by mwalker (2020-03-03 09:08:09)

TelxonHacker · 2020-03-03 23:48:55

I've tried with it in every position on the case, and even directly on the antenna with the cover off, still no luck.
Why do you think the card would show good data in one position, and errors when it's turned 90 degrees? This also happens with the T5577 card that came with the RDV4. The cards are just a bigger loop of wire inside, but still the same principle of inductive coupling. I wouldn't see how that would affect data.

I'm leaning towards it being a problem with the cheap fobs, maybe they don't have good coupling, or aren't real T55x7 chips, although t55 trace shows mfr info.

mwalker · 2020-03-04 12:28:40

I used to see the read change with the right angle trick on my original PM3 Easy. Then the rdv4 (original) without the Low Q switch I would get improved reading when I placed the unit on some tin foil (table - foil - pm3 - card). But once I update to the antenna with the Q switch low Q fixed all that.

I agree with the fob coupling can be a bit tricky, but never had an issue with the full size cards. With the fobs I have all mine working when placed correctly (and for me its not an exact thing), but i would expect different fobs may have their own challenges.

So far the key difference I have seen between the T5577 and a "clone" that I call the T5200 is the cheap clone does NOT allow the page 1 block 3 config, it makes no difference when you write data to it. And the test write does not work.

Its a little tricky when I don't have the card in front of me where I can just try things, but the fact that the data modulates means that block 0 page 0 is valid. As you said, the trace data from blocks 1 and 2 page 1 must be there, and if the info can get that then the read of those blocks must be working and the data must be there.

So, that card seems to be working.
What we don't know is why its not responding to normal reads/writes.

I still think its a password.
I just setup a card, added the trace data to block 1 and 2 page 1
Tested the lf t55 trace, results as expect
I then set the password bit on the config page 0 block 0
lf t55 detect - fails (as expected as no vaild password)
lf t55 trace, shows the correct trace data - with no password (special feature of the t5577).

So matching what you are saying.

If the config had a 6 written in the first nibble, then test mode would be disabled, which could explain why that did not work.
So if for some reason a data block with that set and use pwd bit set, then we get a locked card without knowing the password.

mwalker · 2020-03-04 12:37:45

Just a thought, do you have a .proxmark3 folder with logs in it.
If so, it may be worth scanning the log files to see if you sent something to block 0 that looks a little off e.g. anything but a 0 in the first nibble (e.g. 6xxxxxxx).

TelxonHacker · 2020-03-04 20:24:23

I only have logs of dumps, not writes. Wouldn't a bit of 6 show up in the dump?

[+] Reading Page 0:          
[+] blk | hex data | binary                           | ascii          
[+] ----+----------+----------------------------------+-------          
[+]  00 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  01 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  02 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  04 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  05 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  06 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  07 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+] Reading Page 1:          
[+] blk | hex data | binary                           | ascii          
[+] ----+----------+----------------------------------+-------          
[+]  00 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  01 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  02 | FFFFFFFF | 11111111111111111111111111111111 | ....          
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....

I can also upload the physical file too.

I did just try writing block 3 data on a good fob, and it worked, so these must be T55x7 then, and not 5200. What would happen if you uploaded the dump into one of your tags, would that be a perfect clone of mine?

As for the password, if the first bit was a 6, and block 7 had a password, it would still show all F's, right? (wouldn't be secure if you could just read the password!)

I may run a bruteforce on it, and see what happens.

Interesting note, now the working cards read in any direction, I think I had the q switch set to accurate earlier.

mwalker · 2020-03-05 04:10:45

what os are you using.
I have a .proxmark folder in the folder i run the client from. That is full of session logs.
If on linux, the "." will hide it, so try ls -a

TelxonHacker · 2020-03-05 20:48:02

Kubuntu 18.04
I did find the logs, and looking through them for awhile and searching for t55 commands didn't net me anything that looks suspicious. I was writing several tags back to block 0 default, and then later in the logs, it shows the bad data, so I can't figure out what happened, bad tags maybe?

mwalker · 2020-03-06 00:38:40

Maybe.
If it lost power during the write you could end up in an unknown state. From memory the chip is meant to ensure it has enough power to complete the write, but that does not 100% mean it will (e.g. leaky cap in the fob)

TelxonHacker · 2020-03-06 02:09:42

Is there anything else I should try? I'm almost thinking of calling the 2 tags a loss and just getting some more, as they aren't too expensive on Ebay/Amazon.
I'll also not mess with the config block unless I know for sure what it'll do. Since I'm mainly cloning HID/AWID and other formats on them, I think sticking to the basic HID/AWID /EM write or clone commands should be fine.

On the other hand, I'm not averse to tinkering, and potentially breaking things (as long as it's not the PM3!) in the name of learning and or science!

mwalker · 2020-03-06 08:35:43

If you need to get things working, I would buy some spare fobs/cards anyway

I just want to know what is settings are

I found some time today to have a play.
I now think the card modulation setting is that of a hid card.
i.e. FSK2/FSK2a and RF/50

I made a card and fob then read a zeroed block and compared that to you .pm3 file.
The timing is the same. waveform as a little different, but I think that is just due to my setup and fobs etc as a full card and the fob also have a some difference in the shape of the wave.
But the important part, the peek-peek was the same spacing with a simular shape to the wave.

So from your original post

This is a Chinese tag that came with my blue cloner, I did remove the cloner password successfully, and had used it to clone HID tags with the PM3, and it worked fine up until I changed the downlink.

That seems to match.

So I set my tag to the HID config block page 0 block 0 of 00107060 and the downlink mode changed to leading 0 page 1 block 3 of 00107060. All other blocks were set to 0's

At this point no password or anything special.
Now, I reset the proxmark client (so the config block for the T55 will be default and wont match the card)

    Chip Type      : T55x7
    Modulation     : ASK
    Bit Rate       : 0 - RF/8
    Inverted       : No
    Offset         : 0
    Seq. Term.     : No
    Block0         : 0x00000000
    Downlink Mode  : default/fixed bit length
    Password Set   : No

The data graph shows the same as yours for an lf read
Also the lf t55 read b 0,1,2 all show FFFFFFFF

[usb] pm3 --> lf t55 read b 0
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | FFFFFFFF | .1111111111111111111111111111111 | ....
[usb] pm3 --> lf t55 read b 1
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  01 | FFFFFFFF | .1111111111111111111111111111111 | ....
[usb] pm3 --> lf t55 read b 2
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  02 | FFFFFFFF | .1111111111111111111111111111111 | ....

So at this point everything seems to match what you are seeing.
(correct me if you think you see something different)

Now, if I run the lf t55 det, mine finds the card settings.

[usb] pm3 --> lf t55 det
    Chip Type      : T55x7
    Modulation     : FSK2a
    Bit Rate       : 4 - RF/50
    Inverted       : Yes
    Offset         : 33
    Seq. Term.     : No
    Block0         : 0x00107060
    Downlink Mode  : leading zero reference
    Password Set   : No

Note: with the current rrg code, it will try all downlink modes until it finds a match or all modes have been tried. So the detect does not need the r x option unless you know the mode and want to speed things up.

Since the detect worked, the read and write commands will, by default use the downlink mode found in the detect.

I assume that all your attempts at the lf t55 detect have failed (that is normally due to a password needed, or a really bad config block)

Lets try something... please follow the order and not jump around at all.
exit and rerun the client.
1. open the data plot window and stretch out to make as wide as you can.
2. run : lf read
- At this point I expect you should see the same plot as before.
3. run : lf t55 read b 0
- And watch the graph, it may shift left/right a little, that will be normal, we are looking from something that changed.
4. run : lf t55 read b 0 r 1
- And watch the graph, it may shift left/right a little, that will be normal, we are looking from something that changed.
5. run : lf t55 read b 0 r 2
- And watch the graph, it may shift left/right a little, that will be normal, we are looking from something that changed.
6. run : lf t55 read b 0 r 3
- And watch the graph, it may shift left/right a little, that will be normal, we are looking from something that changed.

In my test, when I hit the correct downlink mode (I almost missed it), but it was different in parts of the wave.
you can run each a few times to see.

If none change, then I am back to the password needed.
If 1 changes, then that will be the downlink mode needed.
If that works, then you should be able to clear that. e.g. lets say the r 2 had something different.
then to clear : lf t55 write b 3 d 00000000 1 r 2

Note:
you can also just try this

lf t55 write b 3 d 00000000 1 r 0
lf t55 write b 3 d 00000000 1 r 1
lf t55 write b 3 d 00000000 1 r 2
lf t55 write b 3 d 00000000 1 r 3
lf t55 wipe
lf t55 detect

This is less about trying to track down the issue and more about resetting every thing.

mwalker · 2020-03-06 08:44:38

Ok, if that does not work, try a bigger hammer

lf t55 write b 0 d 000880E0 r 0 t
lf t55 write b 0 d 000880E0 r 1 t
lf t55 write b 0 d 000880E0 r 2 t
lf t55 write b 0 d 000880E0 r 3 t
lf t55 wipe
lf t55 det

TelxonHacker · 2020-03-06 17:45:20

Unfortunately, still no dice!

mwalker · 2020-03-07 03:12:50

OK, outside of the card being locked (so no more changes), the only thing I can think of is the password.
Given the all 1's, and assuming the password was cleared, ie set to 00000000, the password should still be 00000000
So you could try the test write with a password of 000000 for each d/l mode and maybe FFFFFFFF (i would have expect the password chk would have found that as both of those will be in the password file. But if the config block was not normal it may not detect the match.
Anyway, nothing to loose, so....

Important note for those reading: Using a password on the T55xx when no password has been set CAN result in the card being permanently locked. Since, in this thread we are long passed all the normal tricks, we are down to the last efforts.

If test mode was still enabled. (if the test mode write works, the card will be reset to all 00 then the write to the block noted, so no need for the password on the wipe.

lf t55 write b 0 d 000880E0 p 00000000 r 0 t
lf t55 write b 0 d 000880E0 p 00000000 r 1 t
lf t55 write b 0 d 000880E0 p 00000000 r 2 t
lf t55 write b 0 d 000880E0 p 00000000 r 3 t
lf t55 wipe
lf t55 det

if Test mode was blocked but we "know" the password. Try to clear the d/l mode with the password and wipe the card with the password

lf t55 write b 3 d 00000000 1 p 00000000 r 0
lf t55 write b 3 d 00000000 1 p 00000000 r 1
lf t55 write b 3 d 00000000 1 p 00000000 r 2
lf t55 write b 3 d 00000000 1 p 00000000 r 3
lf t55 wipe p 00000000
lf t55 detect

If still no go, without the card infront of me, I am out of idea.

TelxonHacker · 2020-03-07 16:42:52

I've gotten one tag restored! The last series of commands worked to bring it back, but the other one stubbornly resists.
I'm going to keep trying with the other, as there might still be life in it.

I must say, I'm amazed at your knowledge of this stuff, I've been learning quite a bit messing with these tags and following your guidance.

Thank you for your time and patience in helping me solve this! I'm going to mark it solved, as one fob restored is better than none!

Last edited by TelxonHacker (2020-03-07 16:43:53)

mwalker · 2020-03-08 06:10:18

Good to hear you got one back.
At a guess, I expect the other one will be the same, but a different password. So, try the steps that worked, but inject any other passwords you have been playing with, Just do it in the batch and check, then move to the next password to try.
e.g. cloner password.

TelxonHacker · 2020-03-08 15:04:18

I'm thinking the same, but the odd thing is, I never set a password on any of them, apart from the fobs I used with the cloner, but I recovered those. I did try a few other passwords, mainly the example passwords in the help menus (feedbeef,11223344, 01020304,
cloner, etc)

I'm going to put the last tag on the back burner for now, later on I may try it again, but at least I got one going. I'm going to order some more from Ebay too, so I will have plenty to mess with!

Proxmark3 community

Announcement

#1 2020-03-01 20:44:55

I messed up a T5577 tag, is it bricked? [Solved!]

#2 2020-03-01 23:59:35

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#3 2020-03-02 00:50:24

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#4 2020-03-02 02:41:36

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#5 2020-03-02 09:39:02

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#6 2020-03-02 16:37:10

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#7 2020-03-02 16:51:45

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#8 2020-03-02 17:27:50

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#9 2020-03-02 17:56:20

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#10 2020-03-02 19:44:20

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#11 2020-03-02 21:14:29

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#12 2020-03-02 21:26:57

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#13 2020-03-02 23:45:42

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#14 2020-03-02 23:55:42

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#15 2020-03-03 00:03:41

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#16 2020-03-03 09:02:06

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#17 2020-03-03 23:48:55

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#18 2020-03-04 12:28:40

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#19 2020-03-04 12:37:45

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#20 2020-03-04 20:24:23

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#21 2020-03-05 04:10:45

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#22 2020-03-05 20:48:02

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#23 2020-03-06 00:38:40

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#24 2020-03-06 02:09:42

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#25 2020-03-06 08:35:43

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#26 2020-03-06 08:44:38

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#27 2020-03-06 17:45:20

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#28 2020-03-07 03:12:50

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#29 2020-03-07 16:42:52

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#30 2020-03-08 06:10:18

Re: I messed up a T5577 tag, is it bricked? [Solved!]

#31 2020-03-08 15:04:18

Re: I messed up a T5577 tag, is it bricked? [Solved!]

Board footer