6 INTRODUCTION TO THE proxmark3
7 =============================
9 The proxmark3 device is designed to manipulate RFID tags in a number of
10 different ways. For example, a proxmark3 can:
12 * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,
13 including the ISO-standard tags; standards that require
14 bidirectional communication between the reader and the tag are
17 * emulate a low- or high-frequency tag, in a way very similar to the
18 way that a real tag behaves (e.g., it derives its timing from the
21 * eavesdrop on the signals exchanged between another reader and tag
23 * measure the resonant frequency of an antenna, to a certain extent
24 (this is a convenience when building a test setup for the previous
27 The proxmark3 may be thought of as a direct-sampling software radio.
28 There is some complication, though, because of the usual dynamic range
29 issue in dealing with signals in RFID systems (large signal due to
30 the reader, small signal due to the tag). Some analog processing is
31 therefore used to fix this before the signal is digitized. (Although,
32 it is possible to digitize the signal from the antenna directly, with
33 appropriate population options. It is just not usually a good idea.)
38 The ANTENNA sends and receives signals over the air. It is external to
39 the board; it connects through SV2. Separate pins on the connector are
40 used for the low- and high-frequency antennas, and the analog receive
41 paths are separate. The antennas are inductive loops, which are resonated
42 by on-board capacitors.
44 On the transmit side, the antennas are excited by large numbers of
45 paralleled bus driver buffers. By tri-stating some of the buffers, it
46 is possible to vary the transmit strength. This may be used to generate
47 a modulated carrier. The buffers are driven by signals from the FPGA,
48 as are the output enables. The antennas are excited as series circuits,
49 which permits a large input power for a relatively small input voltage.
51 By driving all of the buffers low, it is possible to make the antenna
52 look to the receive path like a parallel LC circuit; this provides a
53 high-voltage output signal. This is typically what will be done when we
54 are not actively transmitting a carrier (i.e., behaving as a reader).
56 On the receive side, there are two possibilities, which are selected by
57 RLY1. A mechanical relay is used, because the signal from the antenna is
58 likely to be more positive or negative than the highest or lowest supply
59 voltages on-board. In the usual case (PEAK-DETECTED mode), the received
60 signal is peak-detected by an analog circuit, then filtered slightly,
61 and then digitized by the ADC. This is the case for both the low- and
62 high-frequency paths, although the details of the circuits for the
63 two cases are somewhat different. This receive path would typically
64 be selected when the device is behaving as a reader, or when it is
65 eavesdropping at close range.
67 It is also possible to digitize the signal from the antenna directly (RAW
68 mode), after passing it through a gain stage. This is more likely to be
69 useful in reading signals at long range, but the available dynamic range
70 will be poor, since it is limited by the 8-bit A/D. These modes would be
71 very appropriate, for example, for the heavily-discussed attacks in which
72 a tag's ID is learned from the data broadcast by a reader performing an
73 anticollision loop, because there is no dynamic range problem there. It
74 would also be possible to program the proxmark3 to receive broadcast AM
75 radio, with certain changes in component values.
77 In either case, an analog signal is digitized by the ADC (IC8), and
78 from there goes in to the FPGA (IC1). The FPGA is big enough that it
79 can perform DSP operations itself. For some high-frequency standards,
80 the subcarriers are fast enough that it would be inconvenient to do all
81 the math on a general-purpose CPU. The FPGA can therefore correlate for
82 the desired signal itself, and simply report the total to the ARM. For
83 low-frequency tags, it probably makes sense just to pass data straight
86 The FPGA communicates with the ARM through either its SPI port (the ARM
87 is the master) or its generic synchronous serial port (again, the ARM
88 is the master). The ARM connects to the outside world over USB.
90 DETAILS: POWER DISTRIBUTION
91 ===========================
93 I make a half-hearted attempt to meet the USB power specs; this adds a
94 bit of complexity. I have not made measurements to determine how close
95 I come to succeeding, but I think that the suspend current might turn
98 The +3V3 rail is always powered, whenever we are plugged in to USB. This
99 is generated by an LDO, which burns a quiescent current of 150 uA
100 (typical) already. The only thing powered from the +3V3 rail is the ARM,
101 which can presumably do smart power control when we are in suspend.
103 The ARM generates two signals to switch power to the rest of the board:
104 FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to
105 about five volts (the filtered-but-unregulated USB voltage). This powers
106 most of the analog circuitry, including the ADC and all of the opamps
107 and comparators in the receive path, and the coil drivers as well. Vdd
108 also feeds the +3V3-FPGA and +2v5 regulators, which power only the
109 FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered
110 only when NVDD_ON is asserted low, and FPGA_ON is asserted high.
115 The FPGA is a Spartan-II. This is a little bit old, but it is widely
116 available, inexpensive, and five-volt tolerant. For development, the FPGA
117 is configured over JTAG (SV5). In operation, the FPGA is configured in
118 slave serial mode by the ARM, from a bitstream stored in the ARM's flash.
120 Power to the FPGA is managed by regulators IC13 and IC12, both of which
121 have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)
122 supplies. I am a little bit worried about the power-on surge, since we
123 run off USB. At the very minimum, the FPGA should not get power until
124 we have enumerated and requested the full 500 mA available from USB. The
125 large electrolytic capacitors C37 and C38 will presumably help with this.
127 The logic is written in Verilog, of course for webpack. I have structured
128 the FPGA in terms of `major modes:' the FPGA's `major mode' determines
129 which of several modules is connected to the FPGA's I/O pins. A separate
130 module is used for each of the FPGA's function; for example, there is
131 now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to
132 an ISO 15693 tag, and receive from an ISO 15693 tag.
134 DETAILS: ANALOG RECEIVE PATH
135 ============================
137 For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,
138 which is more than enough for the low-frequency stuff, and enough for
139 all of the subcarrier frequencies that I know of at high frequency. In
140 practice, the `slow' signals are all the signals following the peak
141 detector. These signals are usually centred around the generated
144 For `fast' signals, I use an AD8052. This is a very fast voltage-feedback
145 amplifier (~100 MHz GBW). I use it immediately after the antenna for
146 both the low- and high-frequency cases, as a sort of an ugly LNA. It is
147 not optimal, but it certainly made the design easy.
149 An ordinary CD4066 is used to multiplex the four possible signals
150 (low/high frequency paths, RAW/PEAK-DETECTED). There is a potential
151 problem at startup, when the ARM is in reset; there are pull-ups on the
152 lines that control the mux, so all of the switches turn on. This shorts
153 the four opamp outputs together through the on-resistance of the switch.
154 All four outputs float to the same DC voltage with no signal, however,
155 and the on-resistance of the switches is fairly large, so I don't think
156 that will be a problem in practice.
158 Comparators are used to generate clock signals when the device is
159 emulating a tag. These clock signals are generated from the signal on the
160 antenna, and therefore from the signal transmitted by the reader. This
161 allows us to clock ourselves off the reader, just like a real tag would.
162 These signals go in to the FPGA. There is a potential problem when the
163 FPGA is powered down; these outputs might go high and try to power the
164 FPGA through the protection diodes. My present solution to this is a
165 couple of resistors, which is not very elegeant.
167 The high-frequency peak-detected receive path contains population options
168 for many features that I do not currently use. A lot of these are just
169 me guessing that if I provide options for different series and shunt
170 passives, perhaps it will come in handy in some way. The Zener diodes D10
171 and D11 are optional, but may protect the front end from an overvoltage
172 (which will fry the peak detector diodes) when the `simulated tag'
173 is read by a powerful reader.
175 DETAILS: ANALOG TRANSMIT PATH
176 =============================
178 The coil drivers are just ACT244 bus buffers. I parallel eight of them
179 for each antenna (eight for the high-frequency antenna, eight for the
180 low-frequency antenna). This should easily provide a hundred milliamps
181 coil drive or so, which is more than enough for anything that I imagine
182 doing with the device. The drivers hit the coil with a square wave
183 voltage, however, which means that it is only the bandpass filter effect
184 of a resonant antenna that suppresses the odd harmonics. In practice it
185 would probably take heroic efforts (high antenna Q) to meet the FCC/CE
186 harmonic specs; and in practice no one cares.
188 The tx strength, given good antenna tuning, is determined by the series
189 resistors. Choose the ratios to stay within the rated current of the
190 buffers, and to achieve the desired power ratios by enabling or disabling
191 nOEs for the desired modulation index. It is useful to populate one of the
192 resistors as a high value (~10k) for the simulated tag modes; this allows
193 us to look at the incident carrier without loading the reader very much.
198 Atmel makes a number of pin-compatible ARMs, with slightly different
199 peripherals, and different amounts of flash and RAM. It is necessary
200 to choose a device with enough flash not just for the ARM's program,
201 but also for the FPGA image (which is loaded by the ARM).
203 The ARM is responsible for programming the FPGA. It also supplies a
204 clock to the FPGA (although the FPGA clock can also run off the 13.56
205 MHz clock not used for anything else, which is obviously asynchronous
206 to anything in the ARM).
208 It is necessary to use JTAG to bring the ARM for the first time; at
209 that point you can load a bootrom, and subsequently load new software
210 over USB. It might be possible to use the ARM's pre-loaded bootloader
211 (see datasheet) instead of JTAG, but I wanted the JTAG anyways for
212 debugging, so I did not bother. I used a Wiggler clone, with Macraigor's
213 OCD Commander. More expensive tools would work as well.
218 At present I enumerate as an HID device. This saves me writing a driver,
219 but it forces me to do interrupt transfers for everything. This limits
220 speed and is not very elegant. A real USB driver would be nice, maybe
221 even one that could do stuff like going isochronous to stream samples
222 from the A/D for processing on the PC.
224 PRETENDING TO BE A TAG
225 ======================
227 It is not possible, with the given topology, to open-circuit the antenna
228 entirely and still look at the signal received on it. The simulated tag
229 modes must therefore switch between slight loading and heavy loading,
230 not open- and short-circuts across the antenna, evening though they do
231 not depend upon the incident carrier for power (just timing information).
233 RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS
234 ===========================================
236 There is a path straight from the antenna to the A/D, bypassing the peak
237 detector assembly. This goes through a gain stage (just a fast voltage
238 feedback opamp), and from there straight in to the mux.
240 It is necessary to energize the relay to connect these paths. If the
241 coil is driven (as if to excite and read a tag) while these paths are
242 connected, then damage will probably result. Most likely the opamp
248 The tag is excited by a carrier transmitted by the reader. This is
249 generated by IC9 and IC10, using some combination of buffers. The transmit
250 power is determined by selecting the right combination of PWR_OEx pins;
251 drive more of them low for more power. This can be used to modulate the
252 transmitted signal, and thus send information to the tag.
254 The received signal from the antenna is first peak-detected, and then
255 high-pass filtered to reject the unmodulated carrier. The signal is
256 amplified a bit, and goes in to the A/D mux from there. The A/D is
257 controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything
258 synchronous to the 13.56 MHz carrier.
260 INTERFACE FROM THE ARM TO THE FPGA
261 ==================================
263 The FPGA and the ARM can communicate in two main ways: using the ARM's
264 general-purpose synchronous serial port (the SSP), or using the ARM's
265 SPI port. The SPI port is used to configure the FPGA. The ARM writes a
266 configuration word to the FPGA, which determines what operation will
267 be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz
268 vs...). The SPI is used exclusively for configuration.
270 The SSP is used for actual data sent over the air. The ARM's SSP can
271 work in slave mode, which means that we can send the data using clocks
272 generated by the FPGA (either from the PCK0 clock, which the ARM itself
273 supplies, or from the 13.56 MHz clock, which is certainly not going to
274 be synchronous to anything in the ARM), which saves synchronizing logic
275 in the FPGA. The SSP is bi-directional and full-duplex.
projects / proxmark3-svn / blob