Oddball T5577 card

[Aoxhwjfoavdlhsvfpzha]

@Aoxhwjfoavdlhsvfpzha

this is the deranged rantings of a lunatic trying to figure out T5577s

I’ve got this weird-o T5577 that’s not making any sense to what I’m learning about the chip:

It has an HID Corporate 1000 credential on it, and no matter what I do I don’t seem to be able to change or kill the darn thing

I can’t write to Page 0 Blocks 0-3, or Page 1 Blocks 0-2, but can write to the rest, even though no password seems to be set and the lock bits seem clear. Just to be sure, I did try some stuff with an all '00’s password too though

To check where I can write to, I wrote all 'FF’s to the blocks:

Which I now realize should have set the lock bits and permanently set those blocks? But I can still write to them no problem, so it seems to ignore them…

I decided to try lf t5 chk on it, to see if that’d do anything neat:

but it didn’t break anything, and finds a different password each time, none of which seem to do anything at all

lf t5 detects, dumps and everything else are all consistent, so I don’t think it’s just a bad connection or something like that…

Is there another locking mechanism to the T5577 that I’m missing, or is this just an anomalous chip?

[Aoxhwjfoavdlhsvfpzha]

Alright, I realized I could learn a little more about this by restoring the dump onto a more trust-worthy T5577 (In hind-sight, I should have reverted all the “FF” blocks first…)

Doing so does successfully copy the HID credential, but now the second card doesn’t respond to lf t5 detect at all…

Setting config manually with lf t5 config -c 60107C60 to match the original also doesn’t seem to work…

So there does appear to be something weird with the data, if not the original card as well…

Test mode writes don’t seem to work on either, which makes sense if the master key is set to 6?

[amal]

Have you tried the t5577 test mode recovery steps?

Reviving a bricked T5577

The T5577 chip is a great wonder of the world. [The T5577 chip is awesome!] That said, it is sensitive. The chip’s memory is arranged in blocks, and block 0 is a critical block that holds configuration data for how the chip should behave, if a password is set or not, and other critical settings. It is vulnerable to tearing - the act of leaving writable memory corrupted if the write operation is interrupted or suffers from insufficient power available to complete properly. If you h…

Also.. I don’t know this to be the case but it is definitely possible that the bit order of the data is causing some bit of challenge for the proxmark3. The t5577 is programmed through basic bit banging, not a robust “protocol”. As such, timing is absolutely critical. It might be possible that the bit pattern of the specific data is proving to be a challenge.

[Aoxhwjfoavdlhsvfpzha]

@amal

Have you tried the t5577 test mode recovery steps?

I have, but I think test mode is disabled:

@amal

Also.. I don’t know this to be the case but it is definitely possible that the bit order of the data is causing some bit of challenge for the proxmark3. The t5577 is programmed through basic bit banging, not a robust “protocol”. As such, timing is absolutely critical. It might be possible that the bit pattern of the specific data is proving to be a challenge.

Interesting… I did try to overwrite them with the Flipper too, although I’m not sure that would have any better luck…
I’m not sure if there’s any way I could confirm this, maybe I could sniff a write command somehow or something?