[solved] LF unknown ASK modulated & manchester encoded tag experiment

hexa3e8 · 2016-09-13 10:57:46

After some dog-tag reading with the proxmark3 (works great) time for a new project so in the ongoing learning process of the proxmark3 I have experimented with a LF tag and tried to duplicated it on a t55xx.
I think I have succeeded but somehow the "cardnumber" of the original tag seems to change between a few numbers. I get some strange results. So hopefully some tips from you guys.
here's what I did.

lf se u
data plot
data save sample1

It is a unknown ASK modulation with Manchester encoding, clock 32
So I want to see the raw hex-data instead of all the binary for easier understanding

data printdemod x

I see a nice pattern of 00016C3F6730000000016C3F6730000000016C3F6730000000016C3F67300000000

great! I wrote my t55xx (after controlling the block0 with the sticky notes page about the t55xx)

lf t55xx write b 0 d 00088040
lf t55xx write b 1 d 00000000
lf t55xx write b 2 d 16c3f673
lf t55xx write b 3 d 00000000
lf t55xx write b 4 d 16c3f673

question: I started with the zero's and then the number (block 1 and 2), does it matter because the pattern is repeating itself? or should I start with the number and then the zero's. Is it possible to find a sort of start position?
Unfortenately I do not have a reader now to test, but I can soon test it with the actual system.
Now I use the proxmark to read the programmed t55xx and the results look similar.

Then when I try to read the original tag again with

lf se u
data printdemod x

the 16C3F673 changed in 5B0FD9CC and sometimes to B61FB398. hmmm what's going on. I tried 'data buffclear' but that doesn't seem to work. when I exit the software and unplug the proxmark and start all over again I get the initial data 16C3F673. after a while I have one of the other codes again.
and after some reading of the t55xx and then returning to the tag it changes. is there an other 'reset' command?

I have the first sample in pastebin. http://pastebin.com/UjFkhF8d

I think I am on the right way but learning by doing resulted in these questions. Hopefully there is a sort of logical explanation.
Are my thoughts correct in copying the hex-data and putting it like this in the t55xx?
If you need more info let me know. (I can post the results of 'lf se u' if needed)

Last edited by hexa3e8 (2016-09-18 16:10:12)

hexa3e8 · 2016-09-13 18:14:38

I guess my previous post was a bit too long and unclear. So the one remarkable thing I have is that when I repeat the following commands a few times

lf se u
data rawdemod am
data printdemod x

the values keep changing but always in one of the following.

-B0FD9CC000000005B0FD9CC000000005B0FD9CC000000005B0FD9CC000000005B0FD9CC0000000......
-B61FB39800000000B61FB39800000000B61FB39800000000B61FB39800000000B61FB39800000000B61FB3980.....
-002D87ECE6000000002D87ECE6000000002D87ECE6000000002D87ECE6000000002D87ECE6000000002D87E.....
-00016C3F6730000000016C3F6730000000016C3F6730000000016C3F67300000000......

I thought that the tag should always output the same code. what is happening? anyone an idea?

iceman · 2016-09-13 18:40:35

starting offset.. look at the binary pattern instead

hexa3e8 · 2016-09-13 19:22:35

Thanks Iceman. that makes indeed a lot of sense. Why couldn't I think of that.... anyway thx for the hint.
I could reproduce the different hex-values with the ' data printdemod o 16 and 17 etc. then 'data printdemod x o 16 and voila,I see the results.

Is there a trick or command to determine the startingpoint exactly without a reader to test it?
looking at the binary there still remain 4 possible options.
between

0001011011000011
1111011001110011
0000000000000000
0000000000000000
0001011011000011
1111011001110011
0000000000000000
0000000000000000

and (moving the bits to the left)

1011011000011111
1011001110011000
0000000000000000
0000000000000000
1011011000011111
1011001110011000
0000000000000000
0000000000000000

edit:
or maybe it doesn't matter because the order of the long row of bits is still right and the reader gets the right order??

Last edited by hexa3e8 (2016-09-13 19:48:23)

iceman · 2016-09-13 22:33:36

Its confusing going from signal convertion to looking at data interpretation. Two different view points but very easy to mix up.
Understanding that a zero signal is hard to find in a stream of zero signals. Where to start?

Once you get the data, its easier. A signal communicates bits of data, in a stream, but a byte starts a a fixed point. Where to start? you tell me.

marshmellow · 2016-09-14 15:02:00

If the tag happens to be a t55xx compatible the 'lf t55 resetread' may shed light on a starting point.

Also knowing the tags id may help if the raw data read can be converted to that id.

But usually it is not important to know the exact start unless the reader is overly sensitive.

Last edited by marshmellow (2016-09-14 15:05:15)

hexa3e8 · 2016-09-18 16:08:46

Thanks for all the info and explanations. I tried the 'lf t55 resetread' but no response, timed out. So probably not a t55 compatible chip. Unfortunately it is a complete black tag,nothing written on it so no comparison to a known id. I can test the cloned card in 1-2 weeks. I will assume it will work since it produces the same output. but of course with a real reader is the best test.
If somehow the clone did not work I will update this post but for now I will close it since my questions were answered and I assume my experiment has succeeded.
thumbs up for the forum!

marshmellow · 2016-09-18 16:58:38

The resetread works like lf read, you'll need to plot it and/or run a demod after.

hexa3e8 · 2016-09-19 19:37:07

@marshmellow, thanks for pointing that out. but I do not get any data. after the command 'lf t55xx resetread' it waits and doesn't respond,after about 10 seconds I hear a clicksound. when I use a different command it has no connection anymore.I have to restart my proxmark. So flashed the promark3 with the latest image. but no difference. No idea why it stops responding but no matter how I try, my proxmark is not happy with the 'lf t55xx resetread' command

pm3 --> lf t55xx resetread
command execution time out          
pm3 --> lf se u
Sending bytes to proxmark failed          
command execution time out          
Reading 30000 bytes from device memory
          
Data fetched          
Sending bytes to proxmark failed          
Waiting for a response from the proxmark...          
Don't forget to cancel its operation first by pressing on the button          
timeout while waiting for reply.

when I test with a real t55xx card, exact the same result,command execution time out. unfortunately my normal laptops ssd has crashed and right now I am using my backup laptop. So I don't know if it has anything to do with my laptop or with the code. does the command work for you with a real t55xx card?

marshmellow · 2016-09-19 22:26:22

interesting. in my environment it works fine. are you using the PM3 master or Iceman's fork for the current code? (just so i know where to look)

hexa3e8 · 2016-09-19 22:49:46

iceman's fork. thanks for looking into

bootrom: /master/v1.1.0-1513-ga5d8246-suspect 2016-09-19 18:08:21
os: /master/v1.1.0-1513-ga5d8246-suspect 2016-09-19 18:08:26
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at  9: 8: 8

iceman · 2016-09-19 23:24:07

I've been fiddeling a bunch in my latest commits,
does the release v1.6.4 work for you?

hexa3e8 · 2016-09-20 11:46:07

I wish I could tell you but I do not use the docker version (more for windows users?!?). I am using ubuntu. Is there a way to get that version 1.6.4 or a previous version from github pulled somehow? (compared to my v1.1.0-1513)
I thought pulling straight from the github and compiling was the best way to get the latest versions (compared to docker versions). but how to get back to an old version in linux is not known by me.
I hope you have some idea's.

iceman · 2016-09-20 16:08:31

That is easier than you think, https://github.com/iceman1001/proxmark3/releases
Just look at the releases and dl one of the earlier ones, compile and flash...

And no, docker is for all who just want it to be simple and return to a known state always.

hexa3e8 · 2016-09-20 18:29:16

great! I have been many times on your github page but never noticed the link with the releases. After testing 1.6.4 the same result. So I executed the entire process again with 1.6.3 and voila no more time outs. Also other ĺf t55xx commands worked (special / info) without becoming unresponsive and the clicking sound. So the next step is to diff the latest version and 1.6.3 for the lf t55xx command?

iceman · 2016-09-20 18:58:21

nay, I'm pretty sure of what it is... its the spindelayus calls I changed in lfops.c when I realized it ran 21.3us increments. Meaning the timings are pretty bad. I'm in the middle of making a nice "spindelay" but for ticks.. will come soon but not that fast.

Proxmark3 community

Announcement

#1 2016-09-13 10:57:46

[solved] LF unknown ASK modulated & manchester encoded tag experiment

#2 2016-09-13 18:14:38

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#3 2016-09-13 18:40:35

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#4 2016-09-13 19:22:35

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#5 2016-09-13 22:33:36

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#6 2016-09-14 15:02:00

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#7 2016-09-18 16:08:46

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#8 2016-09-18 16:58:38

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#9 2016-09-19 19:37:07

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#10 2016-09-19 22:26:22

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#11 2016-09-19 22:49:46

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#12 2016-09-19 23:24:07

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#13 2016-09-20 11:46:07

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#14 2016-09-20 16:08:31

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#15 2016-09-20 18:29:16

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

#16 2016-09-20 18:58:21

Re: [solved] LF unknown ASK modulated & manchester encoded tag experiment

Board footer