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!