]>
Commit | Line | Data |
---|---|---|
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 |