RFIDler - An open source Software Defined RFID Reader/Writer/Emulator

I've said it before and I'll say it again: I don't understand how it works.

Not only that, but I don't want to understand, and I don't need to understand!

Well, that's not quite true - I need to understand enough to know which bits I don't need to understand, but then that's it! Stop! Enough already!!!

RFID is, as with a lot of these technologies, mysterious by nature. It relies on strange physical phenomena like "induction" and "electro-magnetism" and "near-fields", etc. Yes, what we Code Monkeys like to call "Magic Moonbeams". It's all very nasty and analoguey. I don't like it. Give me the nice binary digital, please!

So in my never ending quest to find tools that convert the scary analogue world into a nice friendly digital one, RFID is clearly a prime candidate. There are lots of RFID/NFC devices out there these days, and you've probably got one or two in your pocket right now - whether it's your car keys, alarm fob, door entry card, credit card, etc. Of course, there are endless varieties of RFID readers to access them with, but what I'd like is something that reads them all, and meets my standard criteria: small and cheap.

To be fair, there are plenty of readers out there that seem to meet this criteria.  You can buy a simple RFID USB reader for as little as 10-15 quid, but you'll find that it's of limited use as it will almost certainly be dedicated to one 'standard', and you'd therefore need dozens of them to be able to read 'everything'. There are also tools like the Proxmark3 that are truly universal and can read pretty much anything, but, unfortunately, these are not cheap.

However, it is certainly worth looking at the PM3 as it really is quite an amazing bit of kit - often described as the 'Swiss Army Knife of RFID', it is versatile enough to read pretty much any tag in the standard LF/HF frequency ranges, so will at least be useful in giving us an idea as to what we're up against... We'll be using it later to look at some specific examples.

So, going right to the beginning, what does an RFID tag actually do?

Well, it depends. There are basically two functions, and the rest is 'details':

Firstly, pretty much every RFID tag will IDENTIFY itself. That is function one. 

Secondly, some tags will store DATA. That is function two. 

The 'details' revolve around how it does those two things - is it blindly spitting out an ID and/or DATA, or is there some security or other command structure built around it? That's the simple view, and if you want the longer, more detailed explanation, there are entire volumes written about it. The 'details' can run into hundreds of pages, so I'm not going to even start. My goal, here, is to talk about the low level fundamental communications that seperate the evil analogue underworld from the lovely, friendly digital fairy garden, where we all like to play.

And it all begins with our friend "induction". At the very low level, RFID/NFC relies on the fact that if you energise a coil and place another coil near it, the second coil will pick up some of that energy through induction. Moreover, the two coils become magically (or magnetically, depending which world you come from)  'coupled', so it's possible for the second coil to effect the voltage on the first, and it does this by shorting itself out. If it does so, there will be a drop in the voltage on the first coil, and this is called "DAMPING". That's it. In a nutshell, that's how RFID works: the coils 'talk' to each-other by either sending energy (from the READER), or causing an energy drop (from the TAG).

In a little more detail, what happens is this (and for the purpose of this section, we'll assume the TAG is the dumbest type that just spits out an ID): the READER energises its coil by powering it on and off repeatedly. For a standard LF system, this will be 125,000 times per second, or 125KHz. This is known as the 'CARRIER'. The TAG, when placed in this field, will scavenge some power from its now inductively-coupled coil and come to life. If the reader needs to send an extra 'wake up' (or any other)  command, it can do so by simply switching it's CARRIER off altogether for short periods. The TAG stores enough energy that it can keep running for long enough to interpret these gap periods, even though it's temporarily lost its power source. The length of the CARRIER signal between the gaps will usually signify a 0 or a 1, so like this the READER can send binary messages.

In other words, they're talking 'ASK': Amplitude Shift Keying. Data is sent by shifting the amplitude of the signal. More accurately, they're talking 'OOK': On Off Keying. A message going from the READER to the TAG is signalled by the CARRIER being ON or OFF and the message coming back is either DAMPED or UN-DAMPED.

Things get a lot easier to understand if we visualise them, so here is a plain 125KHz CARRIER viewed from an oscilloscope:

And here is the READER sending a message to the TAG:

In this case it's using a long pulse to represent a '1' and a short a '0', so the message here is '11000', or 'START_AUTH' if you're a HITAG2.

As I mentioned, the TAG can also send messages back to the READER by shorting it's own coil and DAMPING the READER's coil. The result looks something like this:

 
It looks quite similar to when the READER sends a message, but you'll note that it can't reduce the CARRIER all the way down to nothing - instead it's either a 'DAMPED' or 'UN-DAMPED' wave. This is because it's not directly controlling the voltage on the READER's coil, only affecting it through induction. However, it is clearly still perfectly readable. In this case, if we take the damping action as a '1' and non-damped as a '0', we get '1010101010010110011010', which is, in fact, a MANCHESTER encoded bitstream.

So what has MANCHESTER got to do with anything? Well, this is where it starts to get interesting - if you look in details at the specs for these kind of tags, you'll find that they mention modulation schemes such as 'Manchester', 'Bi-Phase', 'FSK', 'PSK', 'NRZI', 'ASK'...

WTF? We've already established that the two devices can only do ASK, so where does all this FSK/PSK/Manchester malarky come from???

This is where I think a lot of the confusion lies. Once you start trying to do something other than what a particular manufacturer intended with an RFID tag, you quickly get lost in a mire of conflicting modulation schemes and other irrelevancies. This particularly applies to the readers as well - if I want to find a reader that gives me access to the raw data, just forget it. Most readers want to go that little bit further and fully de-modulate the signal for me. And to do that, they need to know exactly how the signal was modulated in the first place... And to know that, they need to know which standard tag type they're going to read, and so on, and so on...

It's easy to see how we've ended up with this situation. A lot of these devices were built back in the days when computing power didn't come cheap, so the designers tried to do as much as possible in the analogue world before handing over to the digital at the last moment. This meant building circuitry that not only handled the low-level ASK communication, but also the secondary modulation schemes that were layered on top. The RF world have been going through a revolution, moving to SDR, in which they're doing the same thing - handling only the very low level analogue stuff in circuitry and doing the rest in software on small powerful microcomputers, and it's time we did the same for RFID!

So when I asked our tame (well, nearly... he's mostly house-trained and has at least stopped biting the postman) Chip Monkey to build me an RFID reader that only gave me the lowest level data, he was somewhat surprised to be unable to find an existing reference circuit that exactly fit the bill. We both thought it would be simple, but no - every circuit was tied to a further demodulation scheme - FSK, PSK, Bi-Phase, etc., and some of them were horrendous! They look more like they're designed to take you to the moon, rather than read a few bits from a wibbly coil! For example, here is Microchip's 200 page document with separate example circuits for ASK, PSK and FSK.

However, after a bit more searching, we found a 'simple' design:  'The World's Simplest RFID Reader'.  This led to an 'improved' version, although it's still described as a 'DIY FSK RFID Reader', so possibly still not quite what we're looking for.

But hang on a minute, surely it doesn't matter what type of tag they were using it to read. We've established that the low level communication is ALWAYS using ASK, so the final demodulation of FSK/PSK/Manchester/Whatever is going to be handled by the microprocessor, so we should be able to use this circuit to do any type of tag, not just FSK.
So this brings us back to the question of these 'extra' modulation schemes. Where do they come from, and how do we deal with them?

Let's use the PM3 to take a look at the raw data we get from each type of tag... The PM3 will act as a basic reader circuit and filter out the CARRIER, leaving only the effect of the DAMPING.

This is an ASK modulated tag:

Exactly what we would expect - a straightforward square wave created by the CARRIER either being DAMPED or UN-DAMPED.


Here is an FSK tag:

Note the two different pulse types - thin ones and fat ones, so we really are seeing different frequency pulses. Weird!

And the strangest yet, PSK:

Now that's just crazy. What the hell is that all about?

First, it helps to understand exactly what we're looking at. The green line is showing us the voltage on the READER coil, after the tag has done it's DAMPING (or not). We don't really care what the scale is, just that the bottom of the screen is 0 volts or fully DAMPED and the top of the screen is *some* volts or UN-DAMPED. The circuit that produces this is effectively looking for the presence of a 125KHz CARRIER and raising or lowering the output line accordingly. How it works is irrelevant. I just don't care. That is Chip Monkey's problem! :)

So now I know what the lines mean, the question is how they get to look like they do. The first one is simple: ASK/OOK modulation is either ON or OFF, so we get a line at the top of the screen when we're UN-DAMPED and a line at the bottom when we're DAMPED.

If we think of what the tag's doing as creating a mask which either lets the CARRIER through or not, this makes perfect sense. Here I've marked the image with a red blob whenever the tag is DAMPING its coil:

So far, so obvious. Let's look at the FSK signal in the same way:

So now, instead of signalling data directly by DAMPING for a 0 or a 1, we are creating a whole new CARRIER by DAMPING for different periods and allowing short or long pulses of the original CARRIER through. The fully DAMPED signal doesn't mean anything, it's the width and number of pulses of the UN-DAMPED signal that carries the information. In this case, 5 fat spikes means '0' and 7 thin spikes means '1' (or 12 thin spikes means '11'), so we've got '011010'. Neat!

OK, so what about the crazy PSK guy?

Well, this is interesting because what's actually happening here is that the coil is being DAMPED relative to the frequency of the original CARRIER itself. In this case, it's going at exactly half the speed, so it's effectively blocking half the CARRIER pulses, and most of the time producing a signal that isn't quite strong enough to reach the top of the screen, and doesn't have time to reach the bottom either, which gives us the chunky bits in the middle. However, whenever there is a phase change, the resulting half-bit repetition means that the DAMPING or UN-DAMPING now lasts for a full clock cycle of the original CARRIER, so we get a little burst of HIGH or LOW popping through, hence the spikes. In this images I've marked the mask in pink for where we're DAMPING 50% of the time, and the phase shifts are red or black as normal.

We can see that the fully DAMPED sections line up with the LOW spikes and the UN-DAMPED with the HIGH. It's harder to read these by eye, but basically whenever there is a phase change (i.e. a spike in either direction), the bit value changes. If there is no phase change, the bit value stays the same. The number of bits depends on how long the gap is between the spikes, so if one was to overlay a grid and you knew how long a bit period was, you could simply count off the periods between bit changes and you've got your bitstream.

If we assume we're starting with a 0, this decodes as: '01101010001111100111000100010110000111010011100101101100001'. Easy-peasy! :)

Great, so now we understand what's going on, let's see if the circuit we've found will do the job...

As it turned out, the answer was 'not quite' for two reasons:

1. It couldn't handle the 'down' spikes of PSK.

2. As soon as we started playing with it, we were hit with a flurry of feature-creep! Yes, we wanted it to do more...

For a start, why have only a reader when you could also have a writer? Unlike some technologies, there is really no difference in the RFID world between a reader and a writer. As long as the reader can send signals to the tag, it can send 'write' and 'data' commands, just as easily as reading the tag's emissions.  Well, almost as easily - it just needs to be able to switch off it's coil as well as modulating it. Clearly that's not an issue.

And why have only a writer when you could have an emulator? Again, the only fundamental difference between a TAG and a READER/WRITER is that one energises it's coil and the other grounds it. Everything else works pretty much the same, so given the right hardware, we have the perfect platform for a Software Defined device...

So Chip Monkey built us one. And it was good. In fact, it was so good that we decided that instead of just publishing the schematics and blogging about it, we would try and give it life and free it into the world...

Accordingly, RFIDler was born, and is now live on Kickstarter:

  http://www.kickstarter.com/projects/1708444109/rfidler-a-software-defined-rfid-reader-writer-emul

The full details and some videos of the prototype in action are be on the project page, but in short the aim is to produce a tool for LF RFID research, for under £30.00, and a cut-down version that be embedded into your own hardware projects for under £20.00.

I have started a firmware project based around the PIC32, which runs on the aforementioned UBW32 BitWhacker, to get the ball rolling, and will add ports to other platforms as we (or you) test them...

The firmware will live here:

  https://github.com/ApertureLabsLtd/RFIDler

If you'd like to have one of these to play with, please go and sign up!