proxmark3/doc/system.txt

This is outdated.

---

INTRODUCTION TO THE proxmark3
=============================

The proxmark3 device is designed to manipulate RFID tags in a number of
different ways. For example, a proxmark3 can:

    * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,
      including the ISO-standard tags; standards that require
      bidirectional communication between the reader and the tag are
      not a problem

    * emulate a low- or high-frequency tag, in a way very similar to the
      way that a real tag behaves (e.g., it derives its timing from the
      incident carrier)

    * eavesdrop on the signals exchanged between another reader and tag

    * measure the resonant frequency of an antenna, to a certain extent
      (this is a convenience when building a test setup for the previous
      three functions)

The proxmark3 may be thought of as a direct-sampling software radio.
There is some complication, though, because of the usual dynamic range
issue in dealing with signals in RFID systems (large signal due to
the reader, small signal due to the tag). Some analog processing is
therefore used to fix this before the signal is digitized. (Although,
it is possible to digitize the signal from the antenna directly, with
appropriate population options. It is just not usually a good idea.)

SYSTEM ARCHITECTURE
===================

The ANTENNA sends and receives signals over the air. It is external to
the board; it connects through SV2. Separate pins on the connector are
used for the low- and high-frequency antennas, and the analog receive
paths are separate. The antennas are inductive loops, which are resonated
by on-board capacitors.

On the transmit side, the antennas are excited by large numbers of
paralleled bus driver buffers. By tri-stating some of the buffers, it
is possible to vary the transmit strength. This may be used to generate
a modulated carrier. The buffers are driven by signals from the FPGA,
as are the output enables. The antennas are excited as series circuits,
which permits a large input power for a relatively small input voltage.

By driving all of the buffers low, it is possible to make the antenna
look to the receive path like a parallel LC circuit; this provides a
high-voltage output signal. This is typically what will be done when we
are not actively transmitting a carrier (i.e., behaving as a reader).

On the receive side, there are two possibilities, which are selected by
RLY1. A mechanical relay is used, because the signal from the antenna is
likely to be more positive or negative than the highest or lowest supply
voltages on-board. In the usual case (PEAK-DETECTED mode), the received
signal is peak-detected by an analog circuit, then filtered slightly,
and then digitized by the ADC. This is the case for both the low- and
high-frequency paths, although the details of the circuits for the
two cases are somewhat different. This receive path would typically
be selected when the device is behaving as a reader, or when it is
eavesdropping at close range.

It is also possible to digitize the signal from the antenna directly (RAW
mode), after passing it through a gain stage. This is more likely to be
useful in reading signals at long range, but the available dynamic range
will be poor, since it is limited by the 8-bit A/D. These modes would be
very appropriate, for example, for the heavily-discussed attacks in which
a tag's ID is learned from the data broadcast by a reader performing an
anticollision loop, because there is no dynamic range problem there. It
would also be possible to program the proxmark3 to receive broadcast AM
radio, with certain changes in component values.

In either case, an analog signal is digitized by the ADC (IC8), and
from there goes in to the FPGA (IC1). The FPGA is big enough that it
can perform DSP operations itself. For some high-frequency standards,
the subcarriers are fast enough that it would be inconvenient to do all
the math on a general-purpose CPU. The FPGA can therefore correlate for
the desired signal itself, and simply report the total to the ARM. For
low-frequency tags, it probably makes sense just to pass data straight
through to the ARM.

The FPGA communicates with the ARM through either its SPI port (the ARM
is the master) or its generic synchronous serial port (again, the ARM
is the master). The ARM connects to the outside world over USB.

DETAILS: POWER DISTRIBUTION
===========================

I make a half-hearted attempt to meet the USB power specs; this adds a
bit of complexity. I have not made measurements to determine how close
I come to succeeding, but I think that the suspend current might turn
out to be a pain.

The +3V3 rail is always powered, whenever we are plugged in to USB. This
is generated by an LDO, which burns a quiescent current of 150 uA
(typical) already. The only thing powered from the +3V3 rail is the ARM,
which can presumably do smart power control when we are in suspend.

The ARM generates two signals to switch power to the rest of the board:
FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to
about five volts (the filtered-but-unregulated USB voltage). This powers
most of the analog circuitry, including the ADC and all of the opamps
and comparators in the receive path, and the coil drivers as well. Vdd
also feeds the +3V3-FPGA and +2v5 regulators, which power only the
FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered
only when NVDD_ON is asserted low, and FPGA_ON is asserted high.

DETAILS: FPGA
=============

The FPGA is a Spartan-II. This is a little bit old, but it is widely
available, inexpensive, and five-volt tolerant. For development, the FPGA
is configured over JTAG (SV5). In operation, the FPGA is configured in
slave serial mode by the ARM, from a bitstream stored in the ARM's flash.

Power to the FPGA is managed by regulators IC13 and IC12, both of which
have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)
supplies. I am a little bit worried about the power-on surge, since we
run off USB. At the very minimum, the FPGA should not get power until
we have enumerated and requested the full 500 mA available from USB. The
large electrolytic capacitors C37 and C38 will presumably help with this.

The logic is written in Verilog, of course for webpack. I have structured
the FPGA in terms of `major modes:' the FPGA's `major mode' determines
which of several modules is connected to the FPGA's I/O pins. A separate
module is used for each of the FPGA's function; for example, there is
now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to
an ISO 15693 tag, and receive from an ISO 15693 tag.

DETAILS: ANALOG RECEIVE PATH
============================

For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,
which is more than enough for the low-frequency stuff, and enough for
all of the subcarrier frequencies that I know of at high frequency. In
practice, the `slow' signals are all the signals following the peak
detector. These signals are usually centred around the generated
voltage Vmid.

For `fast' signals, I use an AD8052. This is a very fast voltage-feedback
amplifier (~100 MHz GBW). I use it immediately after the antenna for
both the low- and high-frequency cases, as a sort of an ugly LNA. It is
not optimal, but it certainly made the design easy.

An ordinary CD4066 is used to multiplex the four possible signals
(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential
problem at startup, when the ARM is in reset; there are pull-ups on the
lines that control the mux, so all of the switches turn on. This shorts
the four opamp outputs together through the on-resistance of the switch.
All four outputs float to the same DC voltage with no signal, however,
and the on-resistance of the switches is fairly large, so I don't think
that will be a problem in practice.

Comparators are used to generate clock signals when the device is
emulating a tag. These clock signals are generated from the signal on the
antenna, and therefore from the signal transmitted by the reader. This
allows us to clock ourselves off the reader, just like a real tag would.
These signals go in to the FPGA. There is a potential problem when the
FPGA is powered down; these outputs might go high and try to power the
FPGA through the protection diodes. My present solution to this is a
couple of resistors, which is not very elegeant.

The high-frequency peak-detected receive path contains population options
for many features that I do not currently use. A lot of these are just
me guessing that if I provide options for different series and shunt
passives, perhaps it will come in handy in some way. The Zener diodes D10
and D11 are optional, but may protect the front end from an overvoltage
(which will fry the peak detector diodes) when the `simulated tag'
is read by a powerful reader.

DETAILS: ANALOG TRANSMIT PATH
=============================

The coil drivers are just ACT244 bus buffers. I parallel eight of them
for each antenna (eight for the high-frequency antenna, eight for the
low-frequency antenna). This should easily provide a hundred milliamps
coil drive or so, which is more than enough for anything that I imagine
doing with the device. The drivers hit the coil with a square wave
voltage, however, which means that it is only the bandpass filter effect
of a resonant antenna that suppresses the odd harmonics. In practice it
would probably take heroic efforts (high antenna Q) to meet the FCC/CE
harmonic specs; and in practice no one cares.

The tx strength, given good antenna tuning, is determined by the series
resistors. Choose the ratios to stay within the rated current of the
buffers, and to achieve the desired power ratios by enabling or disabling
nOEs for the desired modulation index. It is useful to populate one of the
resistors as a high value (~10k) for the simulated tag modes; this allows
us to look at the incident carrier without loading the reader very much.

DETAILS: ARM
============

Atmel makes a number of pin-compatible ARMs, with slightly different
peripherals, and different amounts of flash and RAM. It is necessary
to choose a device with enough flash not just for the ARM's program,
but also for the FPGA image (which is loaded by the ARM).

The ARM is responsible for programming the FPGA. It also supplies a
clock to the FPGA (although the FPGA clock can also run off the 13.56
MHz clock not used for anything else, which is obviously asynchronous
to anything in the ARM).

It is necessary to use JTAG to bring the ARM for the first time; at
that point you can load a bootrom, and subsequently load new software
over USB. It might be possible to use the ARM's pre-loaded bootloader
(see datasheet) instead of JTAG, but I wanted the JTAG anyways for
debugging, so I did not bother. I used a Wiggler clone, with Macraigor's
OCD Commander. More expensive tools would work as well.

USB SOFTWARE
============

At present I enumerate as an HID device. This saves me writing a driver,
but it forces me to do interrupt transfers for everything. This limits
speed and is not very elegant. A real USB driver would be nice, maybe
even one that could do stuff like going isochronous to stream samples
from the A/D for processing on the PC.

PRETENDING TO BE A TAG
======================

It is not possible, with the given topology, to open-circuit the antenna
entirely and still look at the signal received on it. The simulated tag
modes must therefore switch between slight loading and heavy loading,
not open- and short-circuts across the antenna, evening though they do
not depend upon the incident carrier for power (just timing information).

RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS
===========================================

There is a path straight from the antenna to the A/D, bypassing the peak
detector assembly. This goes through a gain stage (just a fast voltage
feedback opamp), and from there straight in to the mux.

It is necessary to energize the relay to connect these paths. If the
coil is driven (as if to excite and read a tag) while these paths are
connected, then damage will probably result. Most likely the opamp
will fry.

READING A TAG
=============

The tag is excited by a carrier transmitted by the reader. This is
generated by IC9 and IC10, using some combination of buffers. The transmit
power is determined by selecting the right combination of PWR_OEx pins;
drive more of them low for more power. This can be used to modulate the
transmitted signal, and thus send information to the tag.

The received signal from the antenna is first peak-detected, and then
high-pass filtered to reject the unmodulated carrier. The signal is
amplified a bit, and goes in to the A/D mux from there. The A/D is
controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything
synchronous to the 13.56 MHz carrier.

INTERFACE FROM THE ARM TO THE FPGA
==================================

The FPGA and the ARM can communicate in two main ways: using the ARM's
general-purpose synchronous serial port (the SSP), or using the ARM's
SPI port. The SPI port is used to configure the FPGA. The ARM writes a
configuration word to the FPGA, which determines what operation will
be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz
vs...). The SPI is used exclusively for configuration.

The SSP is used for actual data sent over the air. The ARM's SSP can
work in slave mode, which means that we can send the data using clocks
generated by the FPGA (either from the PCK0 clock, which the ARM itself
supplies, or from the 13.56 MHz clock, which is certainly not going to
be synchronous to anything in the ARM), which saves synchronizing logic
in the FPGA. The SSP is bi-directional and full-duplex.