Versiunea în Română: https://glitch0ne.com/2023/10/12/aventuri-cu-rfid-la-frecventa-joasa/
Disclaimer: The things I’m about to tell you about should only be tried on personal devices or with the explicit consent of any targets. I’m not responsible for the malicious use of the information presented below. Thank you, and godspeed!
As an avid proponent of Dee Dee’s motto „Ooh! What does this button do?”, I oftentimes find myself in situations where my previous knowledge of a subject only takes me so far. One day, I decided to try and copy a Low Frequency RFID tag that I had, to see whether I could store and emulate it on my Flipper. And while it did seem to recognize the tag as an EM4100 chip, a classic chip type that it could easily emulate, the reader for that particular tag did not recognize my attempts at emulation. Without any other info, I decided to approach this issue at a later time, when I would have more powerful tools at my disposal.
And more powerful tools were on their way. Having gotten my hands on a Proxmark 3, a classic RFID research tool, I took another crack at emulating the chip, only to fail a second time. But what the Proxmark could do that the Flipper could not (or at least, not to my knowledge at the time) was to look further into the data received from the chip. And there the story truly begins.
For context, the EM4100 is a very common RFID chip. It’s used in a lot of access control systems, and it holds some basic data following a specific format, that looks like so:
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 9 bit header, all 1’s |
| 8 bit version number or customer ID | D00 | D01 | D02 | D03 | P0 | Each group of 4 bits is followed by one even parity bit | |||
| D04 | D05 | D06 | D07 | P1 | |||||
| 32 bits of data | D08 | D09 | D10 | D11 | P2 | ||||
| D12 | D13 | D14 | D15 | P3 | |||||
| D16 | D17 | D18 | D19 | P4 | |||||
| D20 | D21 | D22 | D23 | P5 | |||||
| D24 | D25 | D26 | D27 | P6 | |||||
| D28 | D29 | D30 | D31 | P7 | |||||
| D32 | D33 | D34 | D35 | P8 | |||||
| D36 | D37 | D38 | D39 | P9 | |||||
| 4 column parity bits | PC1 | PC2 | PC3 | PC4 | S0 | One stop bit, always 0 | |||
I took the binary data that I received from my unknown chip and tried to see whether it followed this format. And it did. At least, for a while. See, most of the binary data fit neatly into this format, which of course meant that for a basic reader, this would look, feel and behave like your run-of-the-mill EM4100.
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 9 bit header, all 1’s | |||
| 8 bit version number or customer ID | 0 | 0 | 0 | 0 | 0 | Each group of 4 bits is followed by one even parity bit | ||||||
| 0 | 0 | 1 | 1 | 0 | ||||||||
| 32 bits of data | 1 | 1 | 1 | 0 | 1 | |||||||
| 1 | 0 | 0 | 0 | 1 | ||||||||
| 1 | 0 | 1 | 1 | 1 | ||||||||
| 0 | 1 | 0 | 1 | 0 | ||||||||
| 1 | 1 | 1 | 0 | 1 | ||||||||
| 1 | 1 | 0 | 0 | 0 | ||||||||
| 0 | 1 | 0 | 1 | 0 | ||||||||
| 1 | 0 | 1 | 1 | 1 | ||||||||
| 4 column parity bits | 0 | 1 | 1 | 1 | 0 | One stop bit, always 0 | ||||||
| Additional data | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | ||||
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | |||||
| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |||||
| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |||||
But there was more data there beyond it. Specifically 4 more bytes of it, right at the end, after the EM4100 trailer. To make reading easier, we’ll just go with the hexadecimal representation from now on, because ones and zeroes are machine talk, and we’re not quite there yet. The data after the stop bit was essentially 0x7E1EAAAA.
Ultimately, the reason for which my initial attempts at reading and emulation failed were that both myself and my tools ran under the assumption that if it looks like a duck and quacks like a duck, then it is a duck. Unfortunately, this duck had a longer tail. So here we were. I had a tag that behaved “mostly” as an EM4100, but with data that could not fit into your normal EM4100 chip. How could I copy this onto another card?
Enter, the T5577
The T5577 is a chip that offers a lot of custom functionality as well as much more storage than an EM4100, and is able to emulate multiple different chip types and protocols. As long as you configure it properly, and write the correct data to it, it should work and behave like any other low-frequency RFID chip. Its storage format looks something like this:
| Page 1 | L | Analog front end option set up | Block 3 | |||
| 1 | Traceability data | Block 2 | ||||
| 1 | Traceability data | Block 1 | ||||
| L | Page 0 configuration data | Block 0 | ||||
| Page 0 | L | User data or Password | Block 7 | |||
| L | 32 bit user data | Block 6 | ||||
| L | 32 bit user data | Block 5 | ||||
| L | 32 bit user data | Block 4 | ||||
| L | 32 bit user data | Block 3 | ||||
| L | 32 bit user data | Block 2 | ||||
| L | 32 bit user data | Block 1 | ||||
| L | Configuration data | Block 0 | ||||
So, what do we know so far? We have an unknown LF chip, behaving roughly as an EM4100, holding more data than an EM4100, right after the trailer. This means that we could configure the T5577 to look and quack like our duck, writing the following data to the first block of the first page:
0x00148060
Which essentially tells the chip to work on a bit rate of 64 clock cycles, using Manchester encoding, and outputting data all the way out to block 3, which amounts to 96 bits of data. 64 bits of EM4100-like data and 32 bits of mysterious, much secure data. Just like our duck.
Right after that, we write the actual data on the card, block by block, which looks like this in hexadecimal:
0xFF80DD8D
0xD5DC2AEE
0x7E1EAAAA
Doing so made the T5577 chip transmit all of the data that was on the original fob, which made it recognizable by the readers I was targeting. The end!
Or is it? What was the mystery data? Well, I could make a few assumptions, but the main one is that the manufacturer wanted to add a little bit of security through obscurity, in order to thwart basic attempts at duplicating their tags. And while that almost worked for me as well, as soon as I got my hands on some dedicated tooling, the mysteries were unobscured and there went their security. Word on the street is that most if not all of these cards have the same data after the EM4100-like data ends, so it doesn’t seem to be anything of importance yet.
And the moral to the story is, if you’re a company that considers doing security through obscurity, just know that someone, somewhere, is gonna see right through the smoke and mirrors.
References
- EM4100 protocol description: https://www.priority1design.com.au/em4100_protocol.html
- T5577 Guide: https://github.com/RfidResearchGroup/proxmark3/blob/master/doc/T5577_Guide.md
- Flipper Zero: https://flipperzero.one/
- Proxmark 3: https://proxmark.com/proxmark-3-hardware/proxmark-3-rdv4
GLITCH ØNE 