Hey Kyle, look, I took it apart!

Just kidding. When I was lining up to buy this year’s SAINTCON badge, I saw they had the board/LED display available super cheap, so I bought one. If I can’t have the full ENIGMA badge, at least I can have a fun replica. Never mind that I have no earthly idea how to connect to it to light it up. All in good time, my friends.

[Update] — OK, I figured out where it connects. That was easy. Just almost too tiny for my poor old man eyes.

New RFID tags arrived

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.

SAINTCON Hackers Challenge

SAINTCON’s Hackers Challenge opened up today. I spent a number of hours on it. I nailed the Wireshark tasks, the DD tasks, most of the crypto, and I slayed at Hacker Jeopardy. My weak spots right now are binary analysis and web app exploitation. Might spend more time on it this week and try to get farther along. As of now I’m still in the top five By morning that will be stolen from me. 🙂

Please, take care of your shit, I beg of you

One of the synths I picked up recently was a used Moog Mother32. The seller disclosed correctly. “It’s missing a few faceplate screws, and the wood’s a little banged up, but it works fine.” He wasn’t wrong. I contacted Moog for the replacement screws, because he also failed to provide the screws to the two-tier rack kit that came with it (I have screws that fit, but not in matching black). I figured with a few bucks everything would be good as new, and I can sell the two-tier rack to help fund my gadget habit.

When I went to apply the new screws, I found there was nothing to bite them. Dangit, I thought, now I have to take the extra time, take it back OFF the three-tier rack I had already installed it onto, pop it open and find out why. Of course, the Moog is about as close to Eurorack as you can get without actually going Eurorack, so it’s all Eurorack standard. This means that behind those nice black M3 front panel screws are square M3 slide nuts.

This dude, when he went to sell his gear, installed the bare minimum number of slide nuts in place (three out of eight) that would hold the front panel to the box, and called it a day. Interestingly, it did also include a spare switch. I haven’t noticed any switches malfunctioning yet, so maybe that’s just a spare.

Anyhow, I’ve got some slide nuts coming now, so it’ll be as good as new in a week or so. The Mother32 is the least important piece in my setup, so I’m just going to leave it out for now.

Dude sold it at a great price, so I guess I shouldn’t be complaining, but there’s still a market for this model. Had he just taken the few minutes and few bucks to replace the screws, he could have demanded much more for it.

Oh, and he also didn’t include the manual, so I got one of those from Moog too. At some point when I get bored with it and decide to sell it, I want everything I can get (to help fund whatever unnecessary gadgetry I’m into at that point).

Decoding MIFARE data — pointless?

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:

FD65D88ACA880400C825002000000017
E7C0995613BD20D15F58EA614C1020B6
8A000400010000000000000000000000

The bolded hex is the card’s UID.

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:

2A2C13CC242AFF078069FFFFFFFFFFFF
02D7C800000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

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.

Proxmark3 RDV4 Replacement Antenna

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.

Antenna is available here if you’re interested: https://sneaktechnology.com/product/proxmark3-rdv4-01-replacement-antenna/

Oh, you’re wondering about my use case? So far I haven’t been able to read the implant on my cat. I’m hoping this will help.

Another RFID reader on the way

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…

  1. LF RFID is terrible because it’s just a tag ID and is easily cloned.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

https://medium.com/exc3l/cracking-mifare-classic-cards-with-proxmark3-e42121cd968b

RFID Antennas

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 .

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.

RFID_antennas

Further RFID Reader Explorations

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 , 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!

https://www.newegg.com/p/0X6-04KT-2B699?Description=magnetic%20door%20locks&cm_re=magnetic_door%20locks–0X6-04KT-2B699–Product

But now that that point has been made, we’re on to exploring other creative uses.

  1. 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.
  2. LF reader chips are more expensive and less available — generally…
  3. 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.