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