Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Hi proxmark community,
I am trying to read a tag but I am kinda stuck
None of the 'hf search', 'lf search' or 'data rawdemod' give anything sensible, so I think that this tag is not very common.
Well, I don't want to give up that easily, so I start a more manual approach, by looking at the data plot.
Step 1: The tag answers to a LF carrier frequency but not HF
Step 2: The tag repeats, every 4096 samples. I am getting somewhere...
Step 3: The tag short period is 64 samples, so we should probably expect 64 bits of data. Everything's good so far.
Now, when I look at the plot, things look kinda odd:
Waves are very short, and the negative waves always do some sort of noise on the positive side.
I decide to give it a shot with 134kz and things look a bit better. I took the screenshot on the exact same window, so you can compare.
Now how should I demodulate this? This is obviously not some sort of amplitiude modulation, because the wave always reaches its peak. Doesn't seem to be phase modulation either, because there is always a full period, ie, I don't see an up wave followed by another up. So I bet there is some sort of frequency modulation.
This is where I am a bit lost. With frequency modulation, I would expect the wave to alternate between two frequencies, however, I see that sometimes the wave has a period of 64 samples (on the far right), 92 samples (center left) or even longer than that.
Anyone could give me pionters on how to look at this? I could give you the raw data, but I think that going through the learning process would be much better.
Thanks
Offline
If you save and share the data trace, we also would be able to test and detect.
Offline
Here: https://temp-share.com/f/ktjolzdebk/431053e0751c1e3f1c3ff13ac5ef7ffcb72da8ed62591a1e1324cd7b799e13fe
Offline
I got an clean demod from your sample 134kz
pm3 --> data raw nr
Tried NRZ Demod using Clock: 32 - invert: 0 - Bits Found: 620
NRZ demoded bitstream:
0101000101000101
1001011000010100
0100011101010110
1100100110010011
0110110110000011
1111111100100000
0100100110010000
0110110001000111
0101000101000101
1001011000010100
0100011101010110
1100100110010011
0110110110000011
1111111100100000
0100100110010000
0110110001000111
0101000101000101
1001011000010100
0100011101010110
1100100110010011
0110110110000011
1111111100100000
0100100110010000
0110110001000111
0101000101000101
1001011000010100
0100011101010110
1100100110010011
0110110110000011
1111111100100000
0100100110010000
0110110001000111
pm3 --> data print x
DemodBuffer:
514596144756C9936D83FF2049906C47514596144756C9936D83FF2049906C47
514596144756C9936D83FF2049906C47514596144756C9936D83FF2049906C47
Offline
Thanks for your answer iceman.
On my version of proxmark, the nr demod default to a clock of 100, which doesn't gives a clean demod. I had to force it to 32 to get the same result as you ('data raw nr 32'). Just wondering, what made you select 32 vs 64 or any other value? I'm just trying to understand the thought process, instead of just taking an answer without understanding the logic.
Offline
Also, by looking at the graph, what hinted you that it was an nr demod?
Offline
I'm guessing you don't run @marshmellow 's fork, he has some updates to LF, that isn't in the PM3 master (or in aspers pre-compiled) and thats why the clock worked better for me. You can measure the distances and get a feeling for it but I didn't have to do that. Or I would just have tried all clocks manually.
The graf looks like a ASK, and the difference between ASK and NRZ/direct modulation is almost none.
So I tried all ask demods and then nrz. The one which return a demoding result without 0x77 in it is most likely to be the right one. All that is verified with the hex printing of the demod, where the demodulation repeates itself.
Offline
Nrz is a form of ask, just without encoding. Unlike ask/Manchester or ask/biphase... Nrz is apparent in your graph because of the multiple long flat near 0 values that exceed the clock. (Encoding forces at least one peak change per clock.)
I have been afk, and have not loaded the trace yet, but iceman's demod looks correct from eyeing the image.
The nrz clock adjustments are in the main github repo. Just a few q5 chip detect adjustments I've done hasn't made it there yet... So a new compile from the latest official code would likely yield the same results that iceman got.
Offline
Pages: 1