HID Hacking: Part 1

Two things.

One. Access control systems--the majority of them, at least--are weird. They're based on the principle of confirming identities and choosing to allow or deny access, but from my experience, that confirmation is dependent on an ID card, a tag, a keycode, a key--all things that a person can have but not something that has anything at all to do with the person's actual intrinsic identity. Fingerprint or retinal scanners are the only devices to correct this oversight but they certainly aren't widespread.

Two. The widely known quote "It's easier to ask forgiveness than it is to get permission" comes from Grace Hopper, who created the first compiler and was an all-around badass, if you'll pardon my French. Do your homework on Grace Hopper, because she is a role model for the ages. Visual proof of said badassery:



Look at that stance. I'd wet myself if someone was looking at me like that.

With that in mind, a certain series of events that will here remain unmentioned prompted me to examine the access control systems used at many institutions, specifically mine. Like a lot of places, RPI uses RFID card access to control entry to specific buildings, and also like a lot of places, they use HID products for their solution. As I mentioned in the first paragraph, most access control systems suddenly seem much less secure when you realize that they aren't verifying the identity of a person, they're verifying the identity of a token. People can be relatively difficult to spoof; tokens much less so. I jumped at the thought, then, of trying to emulate the RFID tag found in our ID cards.

Enter the brilliant AVRFID project, headed up by Micah Scott (AKA scanlime). There are a lot of reasons why I love this project. It's minimalist, for one. It requires, at the absolute least, a microcontroller and wire. Nothing else. It's also hacky as all get-out; read about how the chip is powered by bleedout from the antenna coil,the same coil which also keeps the chip in sync with the reader's frequency by being hooked to the clock pin. The only other thing at which I've physically cracked up for being so ingenious was a Bach fugue. I ordered an ATtiny and procured some wire, and was all set to go--until I realized that there was no better way to test whatever I soldered together than by programming in data, running to the reader outside of my hall, testing it, running back in, and reprogramming it. Brute forcing a valid ID number was completely out of the question. Thus, I had to pause work with the tags to deal with readers. How could I invert my hacking goals and pull the data off of my card? I researched a few solutions for DIY readers, but I quickly realized that the best avenue I had in terms of reliability and time would be using a genuine HID reader.

I'm going to take a quick detour here and talk for a moment about HID as a company (or, at least, as much as my limited knowledge of them will allow). The phrase "security through obscurity" is used to identify tools that mainly rely on confusion to stay opaque. That is, the tools can be analyzed, they're just kept secret or obfuscated to the point where analysis is either irritating, too difficult to be worth anything, or both. HID seems to take that approach, but extends it to "security through obscurity and expense"; I'll talk about the second part in a bit. Almost all of HID's website is designed to sell products, not to provide worthwhile information on products. I can understand this for sales reasons, but I dug up the vast majority of the reader-specific information I found on other websites from people who had gone through some of the same steps. By default, the readers output data in an alternative manner to the standard clock-and-data serial (when the clock line is set high, the value on the data line is recorded). Instead they use a data transfer protocol called Weigand, where one line represents 1 bits and the other represents 0 bits. Data is recorded as either line drops low for a few microseconds to indicate a value. HID has a proprietary format for storing info on the card that is spectacularly incompatible with EM4100 (the other, near-universal 125kHz RFID standard). There is documentation available on the format but, again, it's pretty hard to pull up. In short, it seems to me like HID relies on people not caring enough to try and break their stuff. Which is a bad decision, because there's always a person who cares enough.

The second stumbling block is cost. The readers I was looking at usually go for $250-$350 new (I think, HID's website wasn't even clear about pricing), but every once in a while on eBay you'll find a kind soul who is selling them off at $20 each because his place of business is transitioning away from them. It wasn't long, therefore, until I found myself with a genuine HID reader on my hands, and one of the exact models for which I was searching to boot. I pried the thing open and immediately shed a few tears of happiness, because this is what I saw:

![](/content/images/2015/11/readerguts.jpg)

Let's break it down, shall we? Most apparent is the giant label that points to everything of importance in the reader. Pin identifiers, switch explanations...it's like a map. Second, screw terminals for connections. No soldering necessary. Not even a sketchy twisted-wire connection. Finally, switches and pushbutons. In fact, an entire bank of switches that toggle settings for the reader--turns out we can use regular clock-and-data instead of Weigand! HID's obscurity extends only as far as the casings of their products, and I respect that--they need to make their products user-friendly for as many people as possible. But it made my job much, much easier.

I spliced an old power cable to get a nice 16V supply, and the reader seems like it's fully functional; it beeps when a card is nearby and definitely spits something out in terms of data. My current problem is making that data readable. All of the code I've borrowed from others online seems to produce either inconsistent or confusing results, so I'm almost definitely going to have to write my own code to make sense of the bits it spits out. At the moment, I'm prevented from doing this because I'm away from my Arduino--my primary serial interface tool--but I'll be back around it within the week and I'm excited to keep hacking.

I've strayed from the original project, but it's for the better--I'm learning more than I'd expected to. Stay tuned! There's much more down the road.