I picked up a batch of NFC tag stickers from you know where.
I started thinking they would be a fun way to host a hunt-type game during a conference, gathering, or other event where the playing field could be large enough and diverse enough, yet still somewhat controlled.
They look innocuous enough, just a plain white circle about 1″ in diameter.
You could direct someone to a landmark — a sign on a building or street, a shelf in a bookstore, a corner of a bar, etc., where you have pre-planted a preprogrammed tag, have them locate and scan the tag, on which they’ll find clues — a URL, a phone#, an email address, or just a block of text. The options are endless.
I think most modern phones support the NFC apps. On my Pixel 6, I’m using NFC Tools by WakDev. Here’s what it looks like on an empty tag:
You can see from this screenshot that it’s writable, can hold 540 bytes of data, and can be made read-only. This is useful to have this choice. In a hunt game, you may want to make the tag read-only so that players can’t corrupt your clue data. If you’re using these tags to exchange data with someone, however, you may want to leave it writable. Imaging using it as a stealth message delivery tool.
Here is the large list of types of data it supports. You’re limited by its 540-byte memory, but anything too large to fit on here can be put somewhere semi-privately on the web and just shared as a URL.
Finally got my Flipper Zero, been waiting it seems like forever for this cute little dangerous toy. So dangerous, in fact, that Ebay is prohibiting its sale. That’s fine. I’m not selling mine anyway.
First thing I tried was capturing a couple of RFID cards I had handy. The first one worked, and I was able to store it in the database for future emulation. The second one did not.
I started digging into why:
First theory: Well, maybe it’s just a weak reader. Let me go get my Dangerous Things RFID Diagnostic Card and see how strong the reader is. Hmm. Not registering at all. What on earth could that mean? Clearly it’s reading one card. Let me look closer…
Well dang. Maybe from now on I shouldn’t keep my RFID Diagnostic card in my wallet next to my gas card. Seems like I knocked one of the capacitors clean off. TANGENT: Fire off an email to Dangerous Things asking for the component value, put it on my to-do-list to replace either the component or the entire card.
Quick, fire off an uninformed Reddit post to see if other people are seeing this issue. Sure enough, the developer fires back. SOME EM4100 cards and SOME HID cards are supported. Recommends I open an issue on their github to give feedback so they can support more.
So now it’s time to search the basement for the Proxmark3 RDV4. Took a few passes, but eventually found it in the bottom of a bin from last time I shuffled surfaces. Oh wait, my current laptop doesn’t have the Proxmark software. Good news, I was able to install the Proxmark software (iceman fork FTW!) on the M1 with minimal effort. And then I flashed the Proxmark with the latest iceman firmware, and now I’m back in business. The difference between the two cards? The working card is 26-bit HID, and the unrecognized card is 34-bit HID.
Opened an issue on the FlipperZero github as requested, and now we wait.
I recently blogged about obtaining Chinese UID-writable magic backdoor Hello Kitty MIFARE fobs to test cloning HF RFID cards. My hope was that I’d be able to clone my kid’s college card, so she wouldn’t have to dig out a card every time she enters a space, just use a fob on her keyring, just like I cloned my LF HID card to a fob for work.
At the time I ordered them, she was away at school, so I had no way of knowing what format her card was. If her student card was MIFARE, I’d probably have a fighting chance. I believe I have successfully cloned MIFARE cards. I say I believe, because I don’t have access to a testing platform until my next hotel stay.
Alas, it seems like schools (at least her school) are a bit ahead of the RFID game compared to hotels. Rather than simple MIFARE, it’s DESFire EV1 2K, and from the searching I’ve been conducting tonight, it doesn’t seem like DESFire has been cracked as far as retrieving the master key. DESFire EV1 is not bleeding edge, though. According to MIFARE, it’s not recommended for new designs. Instead, MIFARE recommends DESFire EV3.
In any case, it’s a hell of a lot of fun to learn the ins and outs of the various formats, protocols, etc., and how these cards and readers work.
I’ll keep on it on the sideburner. I suspect if I do nothing and someone cracks it, it will make its way into the PM3 firmware rather quickly.
I did read something on the forums indicating that the master key might be derived through side-channel attacks involving response speed.
Today, one of the important accessories I was waiting for arrived. The SIM card reader extension. This extends a SIM card slot out via ribbon cable to a clear housing which fits, wait for it… a smart card. Inside the Proxmark3 RDV4 housing, in addition to all that delicious RFID goodness, is a SIM card slot. (If you didn’t already know this, SIM cards are basically the same technology in a different card profile.
So if you crack open the housing (and remove the BlueShark battery/BT module if you have one), you’ll see the SIM card slot. These adapters are less than $2 on aliexpress. Once you slide it in and slip a card into the housing (chip end first, of course, and chip facing the contacts), you have access to the sc commands in the Proxmark firmware (I’m running iceman’s fork, I don’t know how much of this is supported in the stock firmware).
A while back I ordered some stylish (by my standards) Chinese magic writable MiFare RFID fobs. They were clear acrylic with a visible embedded chip. I was excited, even though they were a month away in China.
Well about a week after I ordered them, I got an email from the vendor saying they were out of that model, and gave me three other models to choose from. I didn’t like any of them, but I also didn’t want to start the shopping and ordering process all over again, so I just said, “give me whatever you have.”
They arrived today, and I have to say, I kind of like them. Especially since one of my first clone tests on these fobs will be my daughter’s access card at school. Wish me luck.
Now that I can read, dump and clone cards, of course my natural inclinations lead me toward the next goalpost, which is determining what hidden data can be retrieved from the cards. All indications from that forums were that the issue date/time, expiration date/time and room number are stored somewhere on the card, so I knew vaguely what I was looking for, but still had some learning to do.
I wrote a quick script to dump what I know about the cards, which makes it easier to add further definitions as I learn the more detailed structure of the data:
Here’s what I’ve learned so far:
All of the MIFARE cards in my collection (63 of them at last count) have sixteen sector of data. Sector 0 is three blocks and if my understanding is correct, contains immutable manufacturer and other ata. This makes sense, as the very first thing in sector 0 is the UID of the card. What else is that hex data in sector 0? Dunno. Here’s a sector 0 example:
Sectors 1 through 15 are all four blocks of hex, structured identically. The first block is the keys and access bits. For each sector, there are two keys defined. The access bits define which key or keys are required to read from, or write to, that sector. Example:
In this case, Key A is 2A2C13CC242A, Key B is FFFFFFFFFFFF, and the access bits field is FF078069, which I found is a very common schema.
The remaining three blocks are data, and here’s where it gets fuzzy. I believe that there is no structure whatsoever to that data. No standard, no default, no pattern. In fact, the bulk of cards had no data stored in most sectors. And I have yet to find a discernible pattern in the data that is stored. I have looked for hex-to-decimal date translations, and so far been unlucky.
Here’s the breakdown of “data stored in sectors”:
Of my 63 cards:
48 had data stored in Sector 1
34 had data stored in Sector 2
3 had data stored in Sector 4
5 in Sector 5
1 in Sector 6
1 in Sector 7
Zero cards had data stored in Sector 3 or Sectors 8 through 15.
What I’d love to be able to do is to extract the “stay data” from all of these cards. Keep in mind that these are all actual cards from hotels that I and my family have stayed in over the past 4-5 years. So if the data is retrievable, I should be able to cross-reference it to a trip.
And now I just remembered that I have that batch of DEF CON room keys hanging in the basement that should scan and add to the collection.
So here’s my question for the hackers out there. How you determine, or CAN you determine the nature of hex data stored in blocks with no apparent standard of default structure?
The dumps are on https://github.com/dc540/hfdumps if you’re interested in exploring this data.
So if you’re like me and picked up your Proxmark3 RDV4 on the early side, you probably have the original stock antenna. Which is fine. No, it’s really fine. For all the things that are normally part of RFID experimentation, it’s fine. If you want to read and write implants, you get the ferrite antenna. If you’re looking for long range, you get the extended antenna set (a medium-range that fits in the case and a long range that doesn’t).
But what if like me, you realized that the stock LF antenna is fixed at 125KHz? What if you have a potential use case for 134KHz? There are 134KHz tags out there. Sure, you could go with the long-range set, but it’s $90.
Enter the RDV4.01 replacement antenna. Seems to be only sold by sneaktechnology and lab401, both overseas — doesn’t seem like Hacker Warehouse is carrying it. Probably a low demand item. But for $20 you can replace your stock 125KHz antenna with one that’s got switchable frequency (125KHz/134KHz) and switchable Q (7/14).
I don’t know if this will solve my particular use case, but it’s a lower bar financially than the long-range set, so I’m giving it a shot. I’ll let you know in a few weeks if it helped.
Since I had success with both commercial and maker-level LF RFID readers, i decided to move forward in time another decade, and picked up a HID RP40 multiclass reader.
I’m still in the learning process with HF RFID, so bear with me in this little logic exercise, if you please…
LF RFID is terrible because it’s just a tag ID and is easily cloned.
HF RFID (MIFARE etc) offer enhanced security because it adds the capability of generating a nonce, and I won’t go into further detail here because math… In short, you can write the UID of a tag to a UID-writable tag and the UID will present, but it won’t generate that nonce, so depending on the security application, it may or may not be more secure.
I have found at least one person providing a DIY HF RFID reading app for Arduino that simply validates the UID against a database. This defeats the entire purpose of the enhanced security of MIFARE-type tag protocols, and renders. It’s the equivalent of me being able to withdraw money from your checking account just by knowing your name.
That said, the pm3 with Iceman’s firmware can quickly crack the passwords and dump tag data. The pm3 can also copy that dumped data to a “magic Chinese backdoor” tag and then set the tag to the same UID. At that point, the copied tag seems to read the same as the original. I’d love to test that, but until my next hotel stay, I don’t have access to test that copied tag against an HF reader in situ.
If #4 is correct, given ~15 seconds of proximity to a users badge or fob, I can have a working cloned copy of it, rendering the HF tag literally no more secure than the UID-only LF tag.
I have pretty strong confidence that this will work after reading the following article, and I find the conclusion rather titillating. “While card cloning is a serious security risk, the main problem is not reading or copying the card itself, but being able to reverse engineer the card contents, which could lead to us making a “master key” that opens all the doors in a building.” By the way, I apologize for linking to a medium.com article. I hate everyone that implements paywalls in any form, even though theirs doesn’t kick in until after you’ve read a few articles.
In the process of imagining potential IoT RFID devices, I’ve been looking more closely at how RFID antennas are deployed (for reader and writer devices). Here are a few examples, and a source document to aid in design.
First, the commercial LF reader. This is a pretty beefy antenna, surprising that it still only gets a few cm of range. This is from a medium-range ProxPro 5355 reader.
Next is the RFID-RF522 which I posted about earlier this week. This is an HF reader, which allows the antenna to be much smaller (because the wavelength is much smaller) — small enough to be printed on the PCB itself, which lends itself well to IOT design, especially #badgelife.
Now let’s look at the Proxmark3 RDV4. Without looking, I had assumed they managed to get an LF antenna implemented on the PCB itself, but I was wrong. It’s another wire coil antenna, it’s just sandwiched between the HF antenna (printed on both sides of the larger PCB) and the other PCB.
Then I found this interesting piece — an RFID emulator circuit from kukata86.com (note: Website is dated and SLOW). I say it’s interesting because this person apparently implemented a cloning card that is programmable and passive, meaning it doesn’t require battery for emulation. Also, he seems to have managed to get a LF PCB antenna into production. It takes up a good amount of board space, which makes sense, but if you can print it, you can run the calculations and get the right capacitor(s) to tune it to become resonant. Even though this was made a few years ago, it’s interesting. I just wish they provided KiCAD or Eagle files, or Gerbers, rather than just PDFs.
Finally, here’s a PDF tutorial on HF antenna design, for those who are interested in digging much, much deeper.
Last night I successfully modified my RFID Arduino demonstration code to use the MFRC522 chip, by way of the RFID-RC522 module which was included with my CrowPi. Thanks, CrowPi!
The whole point of all of this exploration is for possible use in #badgelife, and the MFRC522 is a sea change from the commercial RFID reader in my last post. I’m not saying interfacing the Arduino with commercial readers isn’t useful, there are probably a number of people out there interested in DIY physical access control at a DIY-friendly price point. In fact, I found an electromagnetic cabinet lock for $6 from China!
But now that that point has been made, we’re on to exploring other creative uses.
Most importantly, the MFRC522 reads HF (13.56MHz) MIFARE tags rather than LF (125KHz) tags. This changes the game a little bit. It allows us to scan hotel room keys, which from my explorations are ALL HF tags nowadays, and the vast majority are MIFARE.
LF reader chips are more expensive and less available — generally…
Due to the size of the wavelength (125KHz LF wavelength is ~2400m, while 13.56MHz HF wavelength is more along the lines of 22m), it seems like it’s WAY easier to design a PCB-printed antenna for HF than LF.
