Hardware Description
- CPU : ARM, 256/512kB (AT91SAM7S256 or AT91SAM7S512) of flash memory, 64kB of RAM
- FPGA : Xilinx Spartan-II
- Two independent RF circuits, HF and LF
- Power : through USB port
- Connectivity : mini-USB port
- User interface : one button, four LEDs.
- Fully open-source design, both HW and SW
Basically, the idea is that the FPGA is just powerful enough to do the low level modulation/demodulation (-A, -B, ASK, OOK, etc), whereas the CPU should handle the coding/decoding of the frames (Manchester, Miller, etc) as well as more advanced functions.
AT91SAM7x512 Datasheet / Documentation
This hardware description was borrowed with the kind authorization of the author, from the thesis of Gerhard de Koning Gans, called "Analysis of the Mifare Classic used in the OV-chipkaart project
This device supports both low frequency (125 kHz-134 kHz) and high frequency (13.56 MHz) signal processing. This is achieved by implementing two parallel antenna circuits that can be used independently. Both circuits are connected to a 4-pin Hirose connector which functions as an interface to an external loop antenna. For the purpose of acting like a PCD or reader it is possible to drive the antenna coils with the appropriate frequency. This is not needed when the Proxmark is used for sniffing or when it emulates a card. In that case the field is generated by a reader.
The signal from the antenna is routed through a Field Programmable Gate Array (FPGA). This FPGA relays the signal to the microcontroller and can be used to perform some filtering operations before relaying. The software implementation allows the Proxmark to eavesdrop communication between an RFID tag and a reader, to emulate a tag and to emulate a reader.
Despite the basic hardware support for these operations the actual processing of the digitized signal and (de)modulation needs to be programmed for each specific application.
The analog signal that comes from the antenna circuit is fed into an 8-bit Analog to Digital Converter (ADC). This delivers 8 output bits in parallel which represent the current voltage retrieved from the field.
The 8 output pins from the ADC are connected to 8 pins of the Field Programmable Gate Array (FPGA). An FPGA has a great advantage over a normal microcontroller in the sense that it emulates hardware. A hardware description can be compiled and flashed into an FPGA.
Because basic arithmetic functions can be performed fast and in parallel by an FPGA it is faster than an implementation on a normal microcontroller. Only a real hardware implementation would be faster but this lacks the flexibility of an FPGA.
The FPGA can therefore be seen as dynamic hardware. It is possible to make a hardware design and flash it into the memory of the FPGA. This gives some major advantages :
- "Hardware" errors can be corrected, the FPGA can be flashed with a new hardware design.
- Although not as fast as a real hardware implementation, an FPGA is faster than its equivalent on a microprocessor. That is, it is specialized for one job.
The FPGA has two main tasks. The first task is to demodulate the signal received from the ADC and relay this as a digital encoded signal to the ARM. Depending on the task this might be the demodulation of a 100% Amplitude Shift Keying (ASK) signal from the reader or the load modulation of a card. The encoding schemes used to communicate the signal to the ARM are Modified Miller for the reader and Manchester encoding for the card signal.
The second task is to modulate an encoded signal that is received from the ARM into the field of the antenna. This can be both the encoding of reader messages or card messages. For reader messages the FPGA generates a electromagnetic field on pwr hi and drops the amplitude for short periods.
The microcontroller is responsible for the protocol part. It receives the digital encoded signals from the FPGA and decodes them. The decoded signals can just be copied to a buffer in the EEPROM memory. Additionally, an answer to the received message can be send by encoding a reply and communicating this to the FPGA.
The microcontroller (ARM) implements the transport layer. First it decodes the samples received from the FPGA. These samples are stored in a Direct Memory Access (DMA) buffer. The samples are binary sequences that represent whether the signal was high or low. The software on the ARM tries to decode these samples. When the Proxmark is in sniffing mode this is done for both the Manchester and Modified Miller at the same time. Whenever one of the decoding procedures returns a valid message, this message is stored in another buffer (BigBuf ) and both decoding procedures are set to an unsynced state. The BigBuf is limited to the available memory on the ARM. In the current firmwares, 40 KB of memory is reserved for the traces (Besides the traces the buffer also stores some temporary data that is needed in the processing). When the BigBuf buffer is full the function normally returns. A new function call from the client is needed to download the BigBuf contents to the computer. The BigBuf is especially useful for protocol investigation. Every single message is stored in this buffer. When a card is emulated or when the Proxmark is used as a reader the BigBuf can be used to store status messages or protocol exceptions.
The USB interface interconnects the Proxmark with an external power supply and / or a computer for advanced functionality.
The antenna connector is a Hirose Electric low profile, surface mount, right-angle 4 pin connector. This connector allows for the simultaneous connection of a low and high frequency antenna.
- The low frequency antenna (125/134 kHz) connects to Pin 1 (TP5) and Pin 2 (TP2).
- The high frequency antenna (13.56MHz) connects to Pin 3 (TP4) and Pin 4 (TP3).
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.
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.
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.
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 centered around the generated voltage Vmid.
In LF read mode, the received signal goes through an analog AM demodulator (around D1). The result is typically an AC component in the tens of millivolts, sitting on top of 50 V of DC offset. The signal is then high-pass filtered to remove the DC offset and amplified.
The ADC samples at the carrier frequency exactly, 125 kHz by default.
LF sniffing would not be very hard, though Verilog tweaks would indeed be required. It would work essentially the same as LF read, except that the PWR_LO signal is held steady low. And the module is clocked off CROSS_LO (the received carrier) instead of a carrier that we generate ourselves.
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.
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.
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.
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).
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.
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.
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.
The software description below is also taken from the thesis of Gerhard de Koning, and is slightly biased towards the description of the ISO14443-A software, but is nevertheless very relevant for most modes, and is current for the versions of the firmware released at the end of 2008.
The Proxmark is able to operate in three modes. These modes are the sniffing mode, the card emulation mode and the reader mode. A few requirements need to be fulfilled to implement these functions. First, we need an underlying physical layer which takes care of the Digital Signal Processing (DSP), this is implemented in the FPGA. Next, the modes of operation should be implemented as functions on the microcontroller. Finally, a client should be able to call the functions and display the results. This leads to a rough division of the software into three parts :
Client software, calls the functions implemented on the Proxmark, responsible for representation of the results. The client can be seen as the application layer in the communication. It makes use of the underlying protocol to receive information about an RFID card. Microcontroller software, implements the different modes of operation. This is done by defining which protocol messages should be sent in which format and in what order. This can be seen as the transport layer of the communication. FPGA software, is responsible for the DSP and therefore responsible for the physical layer of the communication.
The figure above shows the different components of the Proxmark application and their different responsibilities. The processing and generation of the protocol messages is partly done by the FPGA and partly by the Microcontroller (ARM).
The FPGA mainly does the edge detection and communicates to the ARM whether the signal was high or low. The ARM then tries to decode the retrieved bit stream using Manchester or Modified Miller. For generation of messages the ARM will send a bit stream to the FPGA that represents the Manchester or Modified Miller encoded message. The FPGA will modulate according to this bit stream. The design choice to split this DSP in two parts was mainly because of the limited capacity of the FPGA. It does not have enough space to do flash a design that does the signal processing and message decoding/encoding at the same time. The next subsections are about the way different communication modes are implemented in each different component.
The client application is written by Jonathan Westhues and connects to the Proxmark via the standard HID protocol. The operating system on the ARM does not represent a proper real-time operating system in the sense that it still polls for things like USB packets. This way it is not possible to stream the retrieved samples on real-time to the PC. So when the ARM retrieves a command from the client it runs this command and stores any useful messages in its memory buffer. After the command finishes the client should send a new command to capture the data from the ARM buffer.