| 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 |