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
You've probably all come across these already, but thought I'd share by experience in cloning EM based RFID cards.
Devices are being sold out of Russia and China predominately which read the ID off a tag, and then write it to a r/w tag. My one arrived yesterday, and it works exactly as described. The result is a tag that looks the same as the original (or different - different form factors are available) with the same ID.
EM tags seem to be reasonably common here for access control (although well behind HID and Mifare based ones).
Always nice to have a new toy.
Offline
If you want to see what's going on 'under the hood', take a look at 'unique.py' in the RFIDIOt distribution, which will show you how the bitsream is arranged to generate an EM4x02/Unique ID.
I'll also upload the EM4102 datasheet which explains in detail how the parity etc. works.
BTW, I'd be very interested to know what kind of blank they send you - do you know if it's a Q5/Hitag2 or a programmable 4x02?
Offline
Thanks for the info Adam.
Sorry, I don't know what the blank is - no indication physically on the tag, and I don't have anything (I think) that would assist with identification. Any suggestions how I could determine? My level of technical knowledge is developing, but not deep at present.
Offline
I presume some of your RFIDOiT tools will help. Not sure if it will support one of my current readers under Windows, nor that I can utilsie python, but worth a try if I find some time.
Offline
If you can find someone with an ACG LF reader, the program 'lfxtype.py' will tell you what it is. If you are going to be at DEFCON, come and find me and I'll take a look, or if you've got a spare blank, send it to me and I'll take a look and then send it back to you. Contact me by email for delivery address etc.
I'm just building my LF antenna for the proxmark3, so I might start taking a look at low level identification techniques, but I wouldn't hold your breath...
Offline
Hey Duran,
Can you tell us which product you have bought? (hmm...what did it cost?)
I know there seem to be similar products available from RMXTECH?
I have never tested with those, it could be interesting to play with them for a while.
cheers, roel
Offline
The RMXTECH ones look interesting.
If you google "125KHz RFID Card Copier/Duplicator" you'll see the one I got. I think I found it for about $USD 66. I've also seen the same thing from Russian websites (with Russian characters on it rather than Chinese).
Offline
The RMXTECH ones look interesting.
If you google "125KHz RFID Card Copier/Duplicator" you'll see the one I got. I think I found it for about $USD 66. I've also seen the same thing from Russian websites (with Russian characters on it rather than Chinese).
It's got two buttons on it - one is read, the other is write. very simple really.
Offline
ahh... nice, I think I got the same one then. I bought that blue box with a lot of chinese characters on it
Do you know how it works? Mine does not give the second blinking led ever... Secondly it would be interesting to know what the commands (frames) are to set the UID in the "programmable tag".
Well anyway, when we got a LF snoop function ready we could look better into this I guess.
Offline
It defintely works.
I read the ID on one of the EM tags I had (using a standard 125KHz reader), put it on the device and pushed the read button. (the left buton) I then removed it, put the r/w tag on and pushed the write button (the right button). I checked the r/w tag ID on the reader, and it was the same as the original EM tag.
I had one of my staff translate the Chinese characters, and it said pretty much what I outlined above.
Strange that yours isn't working. It should come with an EM tag, and one r/w tag. It won't work if you try to read a non EM tag (I think you get three beeps), and it won't work if you try to write the ID to a non r/w tag (again three beeps I think).
I evaluate security for a job - IT, physical and the like. While EM tag access control systems are somewhat common here, they're not for the large corporates who tend to use HID and Mifare baed systems. A shame, makes things a bit harder lugging a proxmark around. I need a standalone device like the HID ones that have been demoed.
Offline
Speaking of EM4x02 tags, I believe I have a bunch of EM4102 tags that I can read with a Phidgets reader but haven't been able to correlate via proxmark3.
I read the datasheets for both the EM4100 and EM4102, both say they'll either be biphase coded, manchester coded, or PSK, though in Ed's awesome manual (https://www.lafargue.name/article2754.html), he used ASK + Manchester decoding for what is supposedly an EM4100 tag.
Looking at the waveform for the tag, it looks to me like ASK, not PSK, which does not correlate with the datasheet. However, using ASK + manchester on it did not result in tangible data (nor did it look manchester/biphase encoded after using ASK demodulation).
If anyone wants to check it out, I saved the sample using the proxmark tool so it can be reloaded and looked at (loread + losamples 6000): http://samy.pl/other/thick-card
Any suggestions would be great! Thanks!
Offline
Speaking of EM4x02 tags, I believe I have a bunch of EM4102 tags that I can read with a Phidgets reader but haven't been able to correlate via proxmark3.
I read the datasheets for both the EM4100 and EM4102, both say they'll either be biphase coded, manchester coded, or PSK, though in Ed's awesome manual (https://www.lafargue.name/article2754.html), he used ASK + Manchester decoding for what is supposedly an EM4100 tag.
Cheers :-)
-> Was definitely an EM tag. In fact, Manchester and Biphase are both ASK types, actually: you modulate using ASK (on/off really) , and you code the bitstream using manchester or biphase - with clock recovery and so on...
Have you managed to use the ASK/MAN demod routines on the PM3's CLI to decode your tags, btw?
Ed
Offline
Hey Ed
I've tried those routines, however once I askdemod it, it doesn't look like manchester coding at all (and the function returns no data if I try it). I know it's 4096 clock and 64 bit sequence (just like the tag you decode), but the waveform looks different.
Suggestions? I have the tag saved in my last post and can be loaded in the prox client to see what I was seeing...if it's using a new type of coding not supported in prox, I'll go ahead and add support, I just don't know what it is. It looks like ASK to me but I can't be sure with the little I know about waveforms and that fun stuff.
Offline
Hey Ed
I've tried those routines, however once I askdemod it, it doesn't look like manchester coding at all (and the function returns no data if I try it). I know it's 4096 clock and 64 bit sequence (just like the tag you decode), but the waveform looks different.
Suggestions? I have the tag saved in my last post and can be loaded in the prox client to see what I was seeing...if it's using a new type of coding not supported in prox, I'll go ahead and add support, I just don't know what it is. It looks like ASK to me but I can't be sure with the little I know about waveforms and that fun stuff.
Just had a look at your trace, it's weird :-) You can maybe try to generate other traces with the tag closer/further from the antenna in order to see if it looks different. By decimating the trace a few times it makes things a bit clearer but the manchester decoding routine gets confused indeed... Is there any marking on the tag by any chance?
Offline
No markings on the tag but I can read it with a Phidgets reader and software.
I'll try a few other traces today like you said and also provide what the Phidgets reader says for its ID. Stay tuned...
Offline
The time between each positive and negative peak is always 32 or 64: I think we need to decode by counting the time between each peak, with a "1" transition at each positive peak and "0" transition at each negative peak (or the other way around) and then do a Manchester demod on the result. Anyone care to either:
- Update the askdemod routine to support this
- Create a new demod routine?
Not sure what the modulation should be called, but it's some kind of ASK. I wonder to what extent we are actually seeing artifacts of the reception stage of the Proxmark3 instead of a clean trace...
Ed
Offline
Ed,
I'll go ahead and write that, although how do you handle the space between the negative peak and the positive peak? That is sometimes 32 and sometimes 64 -- but sometimes when it's 64, it's in a location where the positive to the negative peak on either side is only 32. In that situation, how would you code for it?
Basically, sometimes it's pos-32-neg-64-pos-32-neg, sometimes it's pos-32-neg-32-pos-64-neg-32
Offline
Samy using this as reference it shows that a tag has 64 bits of data stored on it. It also tells us that a bit of data is 64, 32 or 16 clock cycles depending on some internal programming of the tag. Looking at your tag data you posted it's obvious that the waveform repeats after exactly 4096 clock cycles. Therefore your tag has 64 bits with 64 cycles each.
Furthermore looking at your tag data and splitting it into 64 cycle chunks, each chunk has the following characteristics:
1. There is always a pulse in the middle of the chunk (just before the 32 cycle)
2. There is sometimes another pulse at the end of the chunk.
3. The polarity of the pulses changes sometimes from chunk to chunk.
Point three above is really an effect of the fact that you never ever have two consecutive pulses of the same polarity, therefore the pulses always alternate hi, lo, hi, lo and you have either 1 or 2 pulses per period. This means that the actual polarity of the pulses is irrelevant so you need to concentrate on what's left: do you have one or two pulses per chunk. Assign them a binary value, say 0 for one pulse, 1 for two pulses and then try to decode the data and see if it makes sense.
You know from page 4 that the datastream always starts with a stream of 9 ones as the header then the rest form an array with both vertical and horizontal parity. That helps tremendously to verify if you've decoded the data correctly.
Have fun with this puzzle
Offline
So on closer look, it's manchester encoded data as per the description on page 5. The data decoded manually (by visually eyeballing the waveform and transcribing each bit) comes out to 11111111 10001111 11000000 00000110 11100101 01110011 01010001 01011010 which further groups to this:
111111111
0001 (1)
1111 (0)
0000 (0)
0000 (0)
1101 (1)
1001 (0)
1011 (1)
0011 (0)
1010 (0)
0101 (0)
||||
(1101) 0
Parity bits are in () and last bit of the sequence is 0 = stop bit as per the datasheet.
Horizontal and vertical parity (even) checks out so the data encoded in the tag is 1F00D9B3A5
Oh and how'sthis for an interesting and somewhat relevant (not to mention cool ) hardware hack, especially if you read about how it's powered and clocked.
Last edited by d18c7db (2009-06-28 05:12:49)
Offline
d1,
Nice! Thanks for that -- good call! (Phidgets reader says f1009d3b5a, you're right)
I updated the `mandemod` command to support reading the waveform the way it is (as well as with a bitstream, the way it originally works). Works fine, though I think I should probably split out the logic and just have a command/function that does the conversion to a bitstream...do you agree or is that never necessary? If so, what would you call it?
Here's how it works now:
> load thick-card
loaded 24000 samples
> mandemod 64
Manchester decoded bitstream
---------
1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1
1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1
0 0 1 0 1 0 1 1 1 0 0 1 1 0 1 0
1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1
1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1
0 0 1 0 1 0 1 1 1 0 0 1 1 0 1 0
1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1
1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1
0 0 1 0 1 0 1 1 1 0 0 1 1 0 1 0
1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1
1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1
0 0 1 0 1 0 1 1 1 0 0 1 1 0 1 0
1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1
1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1
0 0 1 0 1 0 1 1 1 0 0 1 1 0 1 0
1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 1
1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1
I'll go ahead and create an EM4102 function for this as well...next is trying to emulate (which I haven't been successful with losim)
Offline
A simple hardware to clone EM and HID based tags. Use Google to translate. RFID.KZ
Last edited by zghen (2010-02-18 08:54:34)
Offline
A simple hardware to clone EM and HID based tags. Use Google to translate. RFID.KZ
Provided SW only emulates EM cards.
You will surely find this one more interesting (it works and only requires the coil and 2 capacitors):
http://micah.navi.cx/2008/09/using-an-a … -rfid-tag/
Regards.
Offline
I've acquired myself a KeyMaster Pro 4 from RMXLabs - claims to be able to produce a PHYSICAL CLONE of a range of 125Khz tags. I've tested on a HID Prox II, and it certainly can.
It apparently can do Indala cards as well (among a range of others), but I've had no luck with my Indala card.
Not cheap, but a nice standalone machine with a screen with memory for 500 tags. Also does touchkeys.
Offline
In my opinion hardware cloning of simple EMxxxx chip is not worth. It is much easier to use Q5 card to emulate EM card. It costs belowe $1, it looks like a card, it can be reprogrammed many times. I have seen some commercially available software which can program Q5 card to look like exact EM chip.
Offline
Yes, buying hardware such as this just for cloning EMxxx cards is of limited value, albeit you still need hardware to program the Q5, not just software. Given that such hardware can also clone HID (Prox II), Indala and a range of other low frequency cards, it becomes of more value (perhaps).
Offline
Yes, buying hardware such as this just for cloning EMxxx cards is of limited value, albeit you still need hardware to program the Q5, not just software. Given that such hardware can also clone HID (Prox II), Indala and a range of other low frequency cards, it becomes of more value (perhaps).
I mean software and hardware set from same supplier.
I have a feeling that Q5 card is also capable of emulation of Indala or HID (or even any kind of 125kHz RFID system which does not use dynamic challenge-response), it is very flexible with configuration and sends pure data stored in eeprom. It just need some research.
Offline
Sorry for doing "auto-marketing", but you should check the Open RFID Tag...
Offline
Pages: 1