Strange T5577 behavior

socalrds · 2015-11-04 11:10:53

I have both generic T55x7 and genuine Atmel T5577 fobs. The generic fobs work fine, I can read \ write block 0 and any other of the data blocks. However the Atmel T5577 fobs I am unable to successfully write block 0 or even detect the type using the t55xx commands.

Anyone have an experience like this?

iceman · 2015-11-04 11:56:02

is @marshmellow's latest PR merged yet? It contains fixes and code cleanups for lf t55x7 / lf pcf7391 among others...

Try his fork and see if it helps. I've some different times in my fork t55x7 write1 / write0 gaps.. You could test that as well.

marshmellow · 2015-11-05 04:47:26

generic t55x7? curious...

i haven't had trouble writing ata5577's in a long time. so either your firmware is old, or something is "different" about your tags.

tag antenna size? (keyfob or tiny sticker, or large tag?)
are they password protected or can you be sure they are factory default?
PM3 LF antenna voltage? (hw tune)

Last edited by marshmellow (2015-11-05 04:50:43)

marshmellow · 2015-11-05 04:48:37

oh, and, no my PR is not in the main as of yet. (i just issued it recently) but this shouldn't affect writing. (detection maybe...)

socalrds · 2015-11-05 08:09:19

They are key fobs if I try enough times I can get one to write once in a while and when I set it to 0x00107060 config and pull the trace info they are Atmel France T5577M1 chips. My generic T5577 chip fobs work fine... go figure.. lol.. If I can get them to accept the write they have no issue reading the tag data, however the T55xx detect command will not detect the modulation for these tags I have to set them manually.

Need to look at the exact firmware but I don't think Ive flashed since sometime in March, was going to try that tomorrow. Just fond it odd the fobs with genuine Atmel chips are the ones giving me issues.

socalrds · 2015-11-05 08:16:37

proxmark3> hw tune
Measuring antenna characteristics, please wait.........
# LF antenna: 30.11 V @ 125.00 kHz
# LF antenna: 27.36 V @ 134.00 kHz
# LF optimal: 33.96 V @ 127.66 kHz
# HF antenna: 0.07 V @ 13.56 MHz
# Your HF antenna is unusable.
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.
proxmark3>

iceman · 2015-11-05 10:16:04

update your firmware if its that old. A lot has happend with the LF t55xx commands since then.

socalrds · 2015-11-06 04:56:15

Firmware update fixed the issue... Thanks for the help. I did not immediately jump to that solution since I would not expect the genuine chips to give me a problem over the generics...

iceman · 2015-11-06 16:35:54

good, the issue wasn't so much your tags but how much the LF t55xx commands has changed.

There is a reason for everone getting the question about which firmware you are running. Just always update it to the latest.

broken_bad · 2015-12-29 07:49:51

I have updated to very last version and compiled custom firmware, but still no luck with T55xx communication. I would like to perform simplest test - write something to the card and read the same data back. I take untouched original card from the package and I perform simple read:

lf t55xx read b 0

but get no results:

Reading Page 0:
blk | hex data | binary

although data received don't look that bad:

Execution of "lf t55xx detect" says error:
Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

Updating to 2.5.0 or 2.4.0 produced similar results (but slightly different in certain cases). I have done also some experiments with manual config, but I haven't found any working combination that allows me to decode RF data.

Any ideas why this simple test doesn't work on latest firmware?

marshmellow · 2015-12-29 17:11:44

broken_bad wrote:

Any ideas why this simple test doesn't work on latest firmware?

just suggesting that it is a simple test explains that you don't understand what you are trying to do.

there is nothing simple about reading a t55xx chip that can be configured in dozens of possible modulations, bit rates, sequences, wake modes, and many others...

plus you do not include enough information to provide any help. the screenshot slightly helps but isn't zoomed out or wide enough to see modulation specifics. (plus you could have used the two markers to mark the distance between waves to identify the bitrate/clock)

you do not show what version you are actually running with a `hw ver` (btw, 2.4 and 2.5 don't actually exist 2.2 was the last official release...)

and based on your image the read block command worked great. you just have to demodulate it.

if i were to guess i'd say your tag is configured to use a sequence terminator (though i cannot tell from that image.) which is not currently supported in the "automated" detection/read. but reading can still be successful if you know what you are doing...

Last edited by marshmellow (2015-12-29 17:13:10)

broken_bad · 2015-12-30 10:32:34

you do not show what version you are actually running with a `hw ver` (btw, 2.4 and 2.5 don't actually exist 2.2 was the last official release...)

I tried precompiled firmwares from this thread but none of the latest (tried 2.4.0 and 2.5.0) worked fine. I have no idea how 'official' these are but I wanted to save a bit of time by not compiling firmware by myself.

and based on your image the read block command worked great. you just have to demodulate it.

Yes and that was exactly my point - why detection didn't work and any attempts to set demodulation manually didn't produce acceptable results. But this was fixed by not using 'detect' command and setting the parameters directly (actually I had to turn off factory-default Manchester encoding and use NRZ, that helped).

However I am still not very successful reading and decoding traceability data. Datasheet says:

Receiving the op-code “11” results in the transmission of the Manchester encoded 64–bit traceability data of page 1 with the data rate of RF/64.
[...]
The Manchester encoded is ASK modulated with a fixed data rate of RF/64, independent from any other mode register settings.

So I would expect issuing 'lf t55xx trace' does all the job, because everything should be fixed, no variables. But again no luck, I always get error:

proxmark3> lf t55xx trace
The modulation is most likely wrong since the ACL is not 0xE0.

But if I perform demodulation manually using 'data rawdemod am 64 0' I get 64 bits as the documentation says, so demodulation is definitely correct. And what's even better, those bits are reported correctly according to documentation (9 header bits set to 1 etc.):

0 111111111 0011 0 0010 1 0001 1 0010 1 1101 1 1101 1 1110 1 0000 0 1000 1 1000 1110 0

It looks like my card (Q5B) is not that much compatible to the version implemented in proxmark which probably causes my 'simple test operations' to fail under certain circumstances. It needs a bit more investigation.

marshmellow · 2015-12-30 17:03:31

yet you still don't provide any helpful information. it sounds like you are using an old version of the code. the "Auto read" code was only recently adjusted (like 2 weeks ago) to semi function with Q5 tags as it has been known that Q5 has a different chip config style and is not 100% compatible with the t55x7s (which is what the auto read functions were made for). the adjustments will only be in the very latest github code.

the lf t55xx trace command has not been updated to output the correct data for the Q5. though if you were running the newest code it would tell you that...

the commands are labeled lf t55xx as they still get the correct read from any t55xx tag, you just have to manually demodulate it (like you always used to have to do with all tags before iceman and i added the autodetect/autoread functions for the t55x7s)

note: Q5 = t5555, ata5577 = t5577, there are also t5567 and t5557 chips.

broken_bad · 2015-12-31 11:06:56

Sorry, my bad, I flashed firmware but didn't properly update client exe (a bit tricky on windows 10 x64 because of dll hell). New version really says the function won't work as expected because it's not implemented.

broken_bad · 2015-12-31 11:49:49

I have extended cmdlft55xx.c to support Q5 traceability data decoding. I am not a github member, but I can send this file upon request. Seems to be working fine for all my Q5 cards:

lf t55xx config o 1 q5
lf t55xx trace
-- T55xx Trace Information ----------------------------------          
-------------------------------------------------------------          
     IC Revision  : 0          
 Manufactured          
     Lot          : W16987          
     Wafer number : 22          
     Die Number   : 1800          
-------------------------------------------------------------          
 Raw Data - Page 1          
     Block 1  : 0xFF98A32E  11111111100110001010001100101110          
     Block 2  : 0xF717822A  11110111000101111000001000101010

iceman · 2016-01-02 18:36:02

the q5 tracedata is not done in the current state. you can send the code to me or marshmellow and well push it.

marshmellow · 2016-01-05 04:38:10

@iceman, thanks for making me realize the last adjustments I made to the q5 detection has not been pushed to the main repo. I'll have to fix that...

iceman · 2016-01-05 08:54:22

take a lot at my fork, I got broken_bad's imp of q5 tracedata and pushed it. Needs to be tested.
I also added Q5 support for your "lf t55xx wipe" command.

marshmellow · 2016-01-06 04:51:35

if only i actually had a q5

Proxmark3 community

Announcement

#1 2015-11-04 11:10:53

Strange T5577 behavior

#2 2015-11-04 11:56:02

Re: Strange T5577 behavior

#3 2015-11-05 04:47:26

Re: Strange T5577 behavior

#4 2015-11-05 04:48:37

Re: Strange T5577 behavior

#5 2015-11-05 08:09:19

Re: Strange T5577 behavior

#6 2015-11-05 08:16:37

Re: Strange T5577 behavior

#7 2015-11-05 10:16:04

Re: Strange T5577 behavior

#8 2015-11-06 04:56:15

Re: Strange T5577 behavior

#9 2015-11-06 16:35:54

Re: Strange T5577 behavior

#10 2015-12-29 07:49:51

Re: Strange T5577 behavior

#11 2015-12-29 17:11:44

Re: Strange T5577 behavior

#12 2015-12-30 10:32:34

Re: Strange T5577 behavior

#13 2015-12-30 17:03:31

Re: Strange T5577 behavior

#14 2015-12-31 11:06:56

Re: Strange T5577 behavior

#15 2015-12-31 11:49:49

Re: Strange T5577 behavior

#16 2016-01-02 18:36:02

Re: Strange T5577 behavior

#17 2016-01-05 04:38:10

Re: Strange T5577 behavior

#18 2016-01-05 08:54:22

Re: Strange T5577 behavior

#19 2016-01-06 04:51:35

Re: Strange T5577 behavior

Board footer