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.
An unknown tag with (enclosed, magnetic) ferrite core coil is excited with 125 kHz using a randomly wound coil approx. 10 mm length, 5 mm diameter, 100 turns on an unknown ferrite core, connected via 500 Ohm resistor. The cores are aligned in parallel. Although the 'coupling' is probably very bad (analog/HF newbie), surprisingly, it looks like the tag is sending some data. The SNR is bad, however, this is only visible through the scaling of the oscilloscope.
The data looks like it's Manchester-coded, but this cannot apply to what I guess might be the preamble / stop-"bit" that is captured 3 times and shown in the zoom window on the bottom half. It looks like 3 to 5 or 2 to 3 bit times of "1" (tag modulating) and "0" (tag not "pulling down" the carrier).
Since I just started looking into RFID, this is unknown to me and I could not find it in the sticky post in this sub-forum. I was successful in manually decoding a EM4xxx read-only tag using another coil (with much better SNR).
I am hoping someone has seen this code and could point me to a tag type / datasheet / protocol ..
Offline
PS: excitation of coil via 500 R is by sine generator @ 125 kHz or so (a little less, I think, resulted in slightly better data visibility).
Offline
Looks like a standard hid FSK modulated Manchester encoded tag except maybe the preamble. See http://www.proxmark.org/forum/viewtopic.php?id=1767 (third picture)
Last edited by marshmellow (2015-07-08 12:42:26)
Offline
Thanks for your interest! I don't see the FSK in http://i.imgur.com/gPMUnay.png though. Pulse time seems constant, could be 32 cycles (* 8 us = 240 us) but might be longer (I can't be sure, the amplitude seems to decay after a "0"). FFT does not show other frequency peaks, but that probably only means that FFT does not properly find "pulses" either.
Offline
it just looked awful similar to:
which is an HID tag
Offline
which when you zoom in is this:
where the amplitude of the waves are not important but the distance or time between each wave is. in this case:
~5 waves in 50 cycles = 1
~6+ waves in 50 cycles = 0... there is a specific rule to make up the difference for the 6 into 50.
if your tag is truly 32 cycles per bit (or RF/32) and FSK it would be one i've never seen.
if however your graphing metrics are different than i think they are then i could be way off as i'm not as familiar with oscilloscopes as i'd like to be.
Last edited by marshmellow (2015-07-08 20:09:25)
Offline
Ok, thanks. I'm hoping to find the time to try building a properly tuned oscillator and coil, firstly in order to get a better SNR (amplitude modulation), but also because I suspect that the tag would not be able to detune the signal-generated 125 kHz to achieve FSK.
Offline
A somewhat tuned resonant LC "antenna" gives much a better amplitude ratio between baseband mark and space. I have to at least demodulate the scope data before being able to try the proxmark client.
However, I still don't see FSK, neither in the carrier (is it at all possible for the tag to affect the interrogator oscillation?) nor a subcarrier frequency.
The tag
- initializes/waits for approx 17.5 ms before starting to talk
- symbol duration is 32 T
- Sync word MAARK = approx 128 T, SPAAAACE = approx 196 T
- sends 8 packets of about 70 ms length before repeating itself
- could be 128 bit per packet (including some sync data like in first packet header)
- Different preamble/stop data types? INIT A P0 B P1 A P2 A P3 A P4 C P5 D P6 D P7 D .. P0
B and C are weird because they seem to have SPACE-MARK-SPACE within two symbol times where all others have MARK-SPACE (MARK being attenuated by tag). Both then are followed by 3 packets of same stop symbol (A, B, AAA, C, DDD).
So I think it makes more sense these are stop symbols and the long MAAARK-SPAAACE is the preamble for synchronization. This could mean the first A after INIT does not carry valid information.
Offline
Thanks to the upload function, the 6000 px wide image is now completely useless..
Offline
lol... i'm still trying to figure out how you uploaded the image to proxmark.org...
Offline
The 3rd "Image" tool icon above the reply lets you upload a file or specify URL.
Here's the full image on imgur - embedded:
With FireFox, RMB and "View image" lets you zoom in.
It's URL: http://i.imgur.com/SyzTKx1.png (sorry, but "You are not allowed to post links" so you'll have to C&P).
Edit: It seems I now am enabled to post links: http://i.imgur.com/SyzTKx1.png
Last edited by n0ne (2015-07-22 08:21:38)
Offline
I meant to write "... above the reply text field ... ".
I could not find HITAG (1/2/S) traces in the repository [1] to compare - maybe you could point me to one or upload one?
[1] https://github.com/Proxmark/proxmark3/tree/master/traces
Offline
I have "moved" the Hitag question to http://www.proxmark.org/forum/viewtopic.php?pid=17268
Offline
I have now managed to get "the data" into proxmark.exe, but I am unable to decode the Manchester.
"The data" is already thresholded.
Attempt to upload a .pm3 trace as fake PNG "image":
-> http://www.proxmark.org/forum/img/6874/1437549316_05_final.pm3.png
This works! Just "Save as" and remove the trainling ".png".
Last edited by n0ne (2015-07-22 08:20:09)
Offline
As a "bonus", this is how proxmark3.exe plots the start of the data after "data askdemod 1":
Last edited by n0ne (2015-07-22 08:26:25)
Offline
Update your pm3 firmware. Askdemod has been replaced by rawdemod (options).
Offline
But I do not have a pm3, so I cannot update the firmware.
The windows client build 2.1.0 (available in this forum) fails demodulation silently:
>proxmark3.exe n
ERROR: invalid serial port
proxmark3> data load 05_final.pm3
loaded 100000 samples
proxmark3> data plot
proxmark3> data rawdemod am
proxmark3> exit
(askdemod does not seem to do anything either in this version).
I'll have to resort to my scripts..
Offline
Can you compile the latest GitHub sources and use that client?
Offline
I suspect that the proxmark client will not be of much help with a tag that even you guys don't recognize - or did my data uploaded previously happen to yield some results?
- the first modulation after sync (Atmel calls this "start of frame" or SOF) must belong to the sync symbol, otherwise Manchester does not make sense (my "decoder" does not use the clock, so this might be part of https://en.wikipedia.org/wiki/Manchester_code : "Transitions at the period boundaries do not carry information. They exist only to place the signal in the correct state to allow the mid-bit transition.")
- packets 1,2,3 and 5,6,7 decode to 128 bits, packets 0,4 have those weird endings (which I don't know how to interpret) so Manchester only gets 127 bits.
- this tag is in "tag-talk-first" (TTF) mode aka "public mode" (PM) aka "regular read mode" by default
- it is a read-write tag
- it is probably an old tag (5 years +)
- TTF sends 8 packets with 128 bits = 16 bytes (except for the two weird ones), so approx. 1024 bits = 1 kBit = 128 bytes
- I don't know if this is all the data there is or which is configuration / protocol / user data
- I don't know of any checksums or packet counters though it is likely there are some
- data bits could be transmitted in reverse
- sync headers may be configurable in preamble length and may also have a (Manchester) code violation sequence
I have searched "the whole internet" for a datasheet matching these specs but I don't think I have found a chip that just has the "128 bit packets/blocks/frames" property..
Last edited by n0ne (2015-07-25 18:38:33)
Offline
does your tagdata repeat? in the image you clearly see 8 blocks of data. the 9th might be a repeat of the first (but not enough is captured to tell.) if it is repeating then you might have a variety of EM4X50 tags. they have a start bit and a marker bit between each dumped block. i have never seen one that outputs 128 bit blocks though. (most are 32 or 64) also the marker bit appears different than the EM4x50s. but it could be one of the less popular varieties.
Offline
Yes, it does. None of the EM datasheets I have found match. Also, I went through the freely available chapter "market overview" of the German edition "RFID Handbook". Some of those manufacturer's/vendor's websites have not been touched since '99.. but those don't have datasheets available.
Oh well, I'll have to think of something else.
Offline