ARM code cleanup (lfops)

[proxmark3-svn] / doc / system.txt

\r
This is outdated.\r
\r
---\r
\r
INTRODUCTION TO THE proxmark3\r
=============================\r
\r
The proxmark3 device is designed to manipulate RFID tags in a number of\r
different ways. For example, a proxmark3 can:\r
\r
    * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,\r
      including the ISO-standard tags; standards that require\r
      bidirectional communication between the reader and the tag are\r
      not a problem\r
\r
    * emulate a low- or high-frequency tag, in a way very similar to the\r
      way that a real tag behaves (e.g., it derives its timing from the\r
      incident carrier)\r
\r
    * eavesdrop on the signals exchanged between another reader and tag\r
\r
    * measure the resonant frequency of an antenna, to a certain extent\r
      (this is a convenience when building a test setup for the previous\r
      three functions)\r
\r
The proxmark3 may be thought of as a direct-sampling software radio.\r
There is some complication, though, because of the usual dynamic range\r
issue in dealing with signals in RFID systems (large signal due to\r
the reader, small signal due to the tag). Some analog processing is\r
therefore used to fix this before the signal is digitized. (Although,\r
it is possible to digitize the signal from the antenna directly, with\r
appropriate population options. It is just not usually a good idea.)\r
\r
SYSTEM ARCHITECTURE\r
===================\r
\r
The ANTENNA sends and receives signals over the air. It is external to\r
the board; it connects through SV2. Separate pins on the connector are\r
used for the low- and high-frequency antennas, and the analog receive\r
paths are separate. The antennas are inductive loops, which are resonated\r
by on-board capacitors.\r
\r
On the transmit side, the antennas are excited by large numbers of\r
paralleled bus driver buffers. By tri-stating some of the buffers, it\r
is possible to vary the transmit strength. This may be used to generate\r
a modulated carrier. The buffers are driven by signals from the FPGA,\r
as are the output enables. The antennas are excited as series circuits,\r
which permits a large input power for a relatively small input voltage.\r
\r
By driving all of the buffers low, it is possible to make the antenna\r
look to the receive path like a parallel LC circuit; this provides a\r
high-voltage output signal. This is typically what will be done when we\r
are not actively transmitting a carrier (i.e., behaving as a reader).\r
\r
On the receive side, there are two possibilities, which are selected by\r
RLY1. A mechanical relay is used, because the signal from the antenna is\r
likely to be more positive or negative than the highest or lowest supply\r
voltages on-board. In the usual case (PEAK-DETECTED mode), the received\r
signal is peak-detected by an analog circuit, then filtered slightly,\r
and then digitized by the ADC. This is the case for both the low- and\r
high-frequency paths, although the details of the circuits for the\r
two cases are somewhat different. This receive path would typically\r
be selected when the device is behaving as a reader, or when it is\r
eavesdropping at close range.\r
\r
It is also possible to digitize the signal from the antenna directly (RAW\r
mode), after passing it through a gain stage. This is more likely to be\r
useful in reading signals at long range, but the available dynamic range\r
will be poor, since it is limited by the 8-bit A/D. These modes would be\r
very appropriate, for example, for the heavily-discussed attacks in which\r
a tag's ID is learned from the data broadcast by a reader performing an\r
anticollision loop, because there is no dynamic range problem there. It\r
would also be possible to program the proxmark3 to receive broadcast AM\r
radio, with certain changes in component values.\r
\r
In either case, an analog signal is digitized by the ADC (IC8), and\r
from there goes in to the FPGA (IC1). The FPGA is big enough that it\r
can perform DSP operations itself. For some high-frequency standards,\r
the subcarriers are fast enough that it would be inconvenient to do all\r
the math on a general-purpose CPU. The FPGA can therefore correlate for\r
the desired signal itself, and simply report the total to the ARM. For\r
low-frequency tags, it probably makes sense just to pass data straight\r
through to the ARM.\r
\r
The FPGA communicates with the ARM through either its SPI port (the ARM\r
is the master) or its generic synchronous serial port (again, the ARM\r
is the master). The ARM connects to the outside world over USB.\r
\r
DETAILS: POWER DISTRIBUTION\r
===========================\r
\r
I make a half-hearted attempt to meet the USB power specs; this adds a\r
bit of complexity. I have not made measurements to determine how close\r
I come to succeeding, but I think that the suspend current might turn\r
out to be a pain.\r
\r
The +3V3 rail is always powered, whenever we are plugged in to USB. This\r
is generated by an LDO, which burns a quiescent current of 150 uA\r
(typical) already. The only thing powered from the +3V3 rail is the ARM,\r
which can presumably do smart power control when we are in suspend.\r
\r
The ARM generates two signals to switch power to the rest of the board:\r
FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to\r
about five volts (the filtered-but-unregulated USB voltage). This powers\r
most of the analog circuitry, including the ADC and all of the opamps\r
and comparators in the receive path, and the coil drivers as well. Vdd\r
also feeds the +3V3-FPGA and +2v5 regulators, which power only the\r
FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered\r
only when NVDD_ON is asserted low, and FPGA_ON is asserted high.\r
\r
DETAILS: FPGA\r
=============\r
\r
The FPGA is a Spartan-II. This is a little bit old, but it is widely\r
available, inexpensive, and five-volt tolerant. For development, the FPGA\r
is configured over JTAG (SV5). In operation, the FPGA is configured in\r
slave serial mode by the ARM, from a bitstream stored in the ARM's flash.\r
\r
Power to the FPGA is managed by regulators IC13 and IC12, both of which\r
have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)\r
supplies. I am a little bit worried about the power-on surge, since we\r
run off USB. At the very minimum, the FPGA should not get power until\r
we have enumerated and requested the full 500 mA available from USB. The\r
large electrolytic capacitors C37 and C38 will presumably help with this.\r
\r
The logic is written in Verilog, of course for webpack. I have structured\r
the FPGA in terms of `major modes:' the FPGA's `major mode' determines\r
which of several modules is connected to the FPGA's I/O pins. A separate\r
module is used for each of the FPGA's function; for example, there is\r
now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to\r
an ISO 15693 tag, and receive from an ISO 15693 tag.\r
\r
DETAILS: ANALOG RECEIVE PATH\r
============================\r
\r
For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,\r
which is more than enough for the low-frequency stuff, and enough for\r
all of the subcarrier frequencies that I know of at high frequency. In\r
practice, the `slow' signals are all the signals following the peak\r
detector. These signals are usually centred around the generated\r
voltage Vmid.\r
\r
For `fast' signals, I use an AD8052. This is a very fast voltage-feedback\r
amplifier (~100 MHz GBW). I use it immediately after the antenna for\r
both the low- and high-frequency cases, as a sort of an ugly LNA. It is\r
not optimal, but it certainly made the design easy.\r
\r
An ordinary CD4066 is used to multiplex the four possible signals\r
(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential\r
problem at startup, when the ARM is in reset; there are pull-ups on the\r
lines that control the mux, so all of the switches turn on. This shorts\r
the four opamp outputs together through the on-resistance of the switch.\r
All four outputs float to the same DC voltage with no signal, however,\r
and the on-resistance of the switches is fairly large, so I don't think\r
that will be a problem in practice.\r
\r
Comparators are used to generate clock signals when the device is\r
emulating a tag. These clock signals are generated from the signal on the\r
antenna, and therefore from the signal transmitted by the reader. This\r
allows us to clock ourselves off the reader, just like a real tag would.\r
These signals go in to the FPGA. There is a potential problem when the\r
FPGA is powered down; these outputs might go high and try to power the\r
FPGA through the protection diodes. My present solution to this is a\r
couple of resistors, which is not very elegeant.\r
\r
The high-frequency peak-detected receive path contains population options\r
for many features that I do not currently use. A lot of these are just\r
me guessing that if I provide options for different series and shunt\r
passives, perhaps it will come in handy in some way. The Zener diodes D10\r
and D11 are optional, but may protect the front end from an overvoltage\r
(which will fry the peak detector diodes) when the `simulated tag'\r
is read by a powerful reader.\r
\r
DETAILS: ANALOG TRANSMIT PATH\r
=============================\r
\r
The coil drivers are just ACT244 bus buffers. I parallel eight of them\r
for each antenna (eight for the high-frequency antenna, eight for the\r
low-frequency antenna). This should easily provide a hundred milliamps\r
coil drive or so, which is more than enough for anything that I imagine\r
doing with the device. The drivers hit the coil with a square wave\r
voltage, however, which means that it is only the bandpass filter effect\r
of a resonant antenna that suppresses the odd harmonics. In practice it\r
would probably take heroic efforts (high antenna Q) to meet the FCC/CE\r
harmonic specs; and in practice no one cares.\r
\r
The tx strength, given good antenna tuning, is determined by the series\r
resistors. Choose the ratios to stay within the rated current of the\r
buffers, and to achieve the desired power ratios by enabling or disabling\r
nOEs for the desired modulation index. It is useful to populate one of the\r
resistors as a high value (~10k) for the simulated tag modes; this allows\r
us to look at the incident carrier without loading the reader very much.\r
\r
DETAILS: ARM\r
============\r
\r
Atmel makes a number of pin-compatible ARMs, with slightly different\r
peripherals, and different amounts of flash and RAM. It is necessary\r
to choose a device with enough flash not just for the ARM's program,\r
but also for the FPGA image (which is loaded by the ARM).\r
\r
The ARM is responsible for programming the FPGA. It also supplies a\r
clock to the FPGA (although the FPGA clock can also run off the 13.56\r
MHz clock not used for anything else, which is obviously asynchronous\r
to anything in the ARM).\r
\r
It is necessary to use JTAG to bring the ARM for the first time; at\r
that point you can load a bootrom, and subsequently load new software\r
over USB. It might be possible to use the ARM's pre-loaded bootloader\r
(see datasheet) instead of JTAG, but I wanted the JTAG anyways for\r
debugging, so I did not bother. I used a Wiggler clone, with Macraigor's\r
OCD Commander. More expensive tools would work as well.\r
\r
USB SOFTWARE\r
============\r
\r
At present I enumerate as an HID device. This saves me writing a driver,\r
but it forces me to do interrupt transfers for everything. This limits\r
speed and is not very elegant. A real USB driver would be nice, maybe\r
even one that could do stuff like going isochronous to stream samples\r
from the A/D for processing on the PC.\r
\r
PRETENDING TO BE A TAG\r
======================\r
\r
It is not possible, with the given topology, to open-circuit the antenna\r
entirely and still look at the signal received on it. The simulated tag\r
modes must therefore switch between slight loading and heavy loading,\r
not open- and short-circuts across the antenna, evening though they do\r
not depend upon the incident carrier for power (just timing information).\r
\r
RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS\r
===========================================\r
\r
There is a path straight from the antenna to the A/D, bypassing the peak\r
detector assembly. This goes through a gain stage (just a fast voltage\r
feedback opamp), and from there straight in to the mux.\r
\r
It is necessary to energize the relay to connect these paths. If the\r
coil is driven (as if to excite and read a tag) while these paths are\r
connected, then damage will probably result. Most likely the opamp\r
will fry.\r
\r
READING A TAG\r
=============\r
\r
The tag is excited by a carrier transmitted by the reader. This is\r
generated by IC9 and IC10, using some combination of buffers. The transmit\r
power is determined by selecting the right combination of PWR_OEx pins;\r
drive more of them low for more power. This can be used to modulate the\r
transmitted signal, and thus send information to the tag.\r
\r
The received signal from the antenna is first peak-detected, and then\r
high-pass filtered to reject the unmodulated carrier. The signal is\r
amplified a bit, and goes in to the A/D mux from there. The A/D is\r
controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything\r
synchronous to the 13.56 MHz carrier.\r
\r
INTERFACE FROM THE ARM TO THE FPGA\r
==================================\r
\r
The FPGA and the ARM can communicate in two main ways: using the ARM's\r
general-purpose synchronous serial port (the SSP), or using the ARM's\r
SPI port. The SPI port is used to configure the FPGA. The ARM writes a\r
configuration word to the FPGA, which determines what operation will\r
be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz\r
vs...). The SPI is used exclusively for configuration.\r
\r
The SSP is used for actual data sent over the air. The ARM's SSP can\r
work in slave mode, which means that we can send the data using clocks\r
generated by the FPGA (either from the PCK0 clock, which the ARM itself\r
supplies, or from the 13.56 MHz clock, which is certainly not going to\r
be synchronous to anything in the ARM), which saves synchronizing logic\r
in the FPGA. The SSP is bi-directional and full-duplex.\r
\r