--- /dev/null
+\r
+This is outdated.\r
+\r
+---\r
+\r
+INTRODUCTION TO THE proxmark3\r
+=============================\r
+\r
+The proxmark3 device is designed to manipulate RFID tags in a number of\r
+different ways. For example, a proxmark3 can:\r
+\r
+ * read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,\r
+ including the ISO-standard tags; standards that require\r
+ bidirectional communication between the reader and the tag are\r
+ not a problem\r
+\r
+ * emulate a low- or high-frequency tag, in a way very similar to the\r
+ way that a real tag behaves (e.g., it derives its timing from the\r
+ incident carrier)\r
+\r
+ * eavesdrop on the signals exchanged between another reader and tag\r
+\r
+ * measure the resonant frequency of an antenna, to a certain extent\r
+ (this is a convenience when building a test setup for the previous\r
+ three functions)\r
+\r
+The proxmark3 may be thought of as a direct-sampling software radio.\r
+There is some complication, though, because of the usual dynamic range\r
+issue in dealing with signals in RFID systems (large signal due to\r
+the reader, small signal due to the tag). Some analog processing is\r
+therefore used to fix this before the signal is digitized. (Although,\r
+it is possible to digitize the signal from the antenna directly, with\r
+appropriate population options. It is just not usually a good idea.)\r
+\r
+SYSTEM ARCHITECTURE\r
+===================\r
+\r
+The ANTENNA sends and receives signals over the air. It is external to\r
+the board; it connects through SV2. Separate pins on the connector are\r
+used for the low- and high-frequency antennas, and the analog receive\r
+paths are separate. The antennas are inductive loops, which are resonated\r
+by on-board capacitors.\r
+\r
+On the transmit side, the antennas are excited by large numbers of\r
+paralleled bus driver buffers. By tri-stating some of the buffers, it\r
+is possible to vary the transmit strength. This may be used to generate\r
+a modulated carrier. The buffers are driven by signals from the FPGA,\r
+as are the output enables. The antennas are excited as series circuits,\r
+which permits a large input power for a relatively small input voltage.\r
+\r
+By driving all of the buffers low, it is possible to make the antenna\r
+look to the receive path like a parallel LC circuit; this provides a\r
+high-voltage output signal. This is typically what will be done when we\r
+are not actively transmitting a carrier (i.e., behaving as a reader).\r
+\r
+On the receive side, there are two possibilities, which are selected by\r
+RLY1. A mechanical relay is used, because the signal from the antenna is\r
+likely to be more positive or negative than the highest or lowest supply\r
+voltages on-board. In the usual case (PEAK-DETECTED mode), the received\r
+signal is peak-detected by an analog circuit, then filtered slightly,\r
+and then digitized by the ADC. This is the case for both the low- and\r
+high-frequency paths, although the details of the circuits for the\r
+two cases are somewhat different. This receive path would typically\r
+be selected when the device is behaving as a reader, or when it is\r
+eavesdropping at close range.\r
+\r
+It is also possible to digitize the signal from the antenna directly (RAW\r
+mode), after passing it through a gain stage. This is more likely to be\r
+useful in reading signals at long range, but the available dynamic range\r
+will be poor, since it is limited by the 8-bit A/D. These modes would be\r
+very appropriate, for example, for the heavily-discussed attacks in which\r
+a tag's ID is learned from the data broadcast by a reader performing an\r
+anticollision loop, because there is no dynamic range problem there. It\r
+would also be possible to program the proxmark3 to receive broadcast AM\r
+radio, with certain changes in component values.\r
+\r
+In either case, an analog signal is digitized by the ADC (IC8), and\r
+from there goes in to the FPGA (IC1). The FPGA is big enough that it\r
+can perform DSP operations itself. For some high-frequency standards,\r
+the subcarriers are fast enough that it would be inconvenient to do all\r
+the math on a general-purpose CPU. The FPGA can therefore correlate for\r
+the desired signal itself, and simply report the total to the ARM. For\r
+low-frequency tags, it probably makes sense just to pass data straight\r
+through to the ARM.\r
+\r
+The FPGA communicates with the ARM through either its SPI port (the ARM\r
+is the master) or its generic synchronous serial port (again, the ARM\r
+is the master). The ARM connects to the outside world over USB.\r
+\r
+DETAILS: POWER DISTRIBUTION\r
+===========================\r
+\r
+I make a half-hearted attempt to meet the USB power specs; this adds a\r
+bit of complexity. I have not made measurements to determine how close\r
+I come to succeeding, but I think that the suspend current might turn\r
+out to be a pain.\r
+\r
+The +3V3 rail is always powered, whenever we are plugged in to USB. This\r
+is generated by an LDO, which burns a quiescent current of 150 uA\r
+(typical) already. The only thing powered from the +3V3 rail is the ARM,\r
+which can presumably do smart power control when we are in suspend.\r
+\r
+The ARM generates two signals to switch power to the rest of the board:\r
+FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to\r
+about five volts (the filtered-but-unregulated USB voltage). This powers\r
+most of the analog circuitry, including the ADC and all of the opamps\r
+and comparators in the receive path, and the coil drivers as well. Vdd\r
+also feeds the +3V3-FPGA and +2v5 regulators, which power only the\r
+FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered\r
+only when NVDD_ON is asserted low, and FPGA_ON is asserted high.\r
+\r
+DETAILS: FPGA\r
+=============\r
+\r
+The FPGA is a Spartan-II. This is a little bit old, but it is widely\r
+available, inexpensive, and five-volt tolerant. For development, the FPGA\r
+is configured over JTAG (SV5). In operation, the FPGA is configured in\r
+slave serial mode by the ARM, from a bitstream stored in the ARM's flash.\r
+\r
+Power to the FPGA is managed by regulators IC13 and IC12, both of which\r
+have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)\r
+supplies. I am a little bit worried about the power-on surge, since we\r
+run off USB. At the very minimum, the FPGA should not get power until\r
+we have enumerated and requested the full 500 mA available from USB. The\r
+large electrolytic capacitors C37 and C38 will presumably help with this.\r
+\r
+The logic is written in Verilog, of course for webpack. I have structured\r
+the FPGA in terms of `major modes:' the FPGA's `major mode' determines\r
+which of several modules is connected to the FPGA's I/O pins. A separate\r
+module is used for each of the FPGA's function; for example, there is\r
+now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to\r
+an ISO 15693 tag, and receive from an ISO 15693 tag.\r
+\r
+DETAILS: ANALOG RECEIVE PATH\r
+============================\r
+\r
+For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,\r
+which is more than enough for the low-frequency stuff, and enough for\r
+all of the subcarrier frequencies that I know of at high frequency. In\r
+practice, the `slow' signals are all the signals following the peak\r
+detector. These signals are usually centred around the generated\r
+voltage Vmid.\r
+\r
+For `fast' signals, I use an AD8052. This is a very fast voltage-feedback\r
+amplifier (~100 MHz GBW). I use it immediately after the antenna for\r
+both the low- and high-frequency cases, as a sort of an ugly LNA. It is\r
+not optimal, but it certainly made the design easy.\r
+\r
+An ordinary CD4066 is used to multiplex the four possible signals\r
+(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential\r
+problem at startup, when the ARM is in reset; there are pull-ups on the\r
+lines that control the mux, so all of the switches turn on. This shorts\r
+the four opamp outputs together through the on-resistance of the switch.\r
+All four outputs float to the same DC voltage with no signal, however,\r
+and the on-resistance of the switches is fairly large, so I don't think\r
+that will be a problem in practice.\r
+\r
+Comparators are used to generate clock signals when the device is\r
+emulating a tag. These clock signals are generated from the signal on the\r
+antenna, and therefore from the signal transmitted by the reader. This\r
+allows us to clock ourselves off the reader, just like a real tag would.\r
+These signals go in to the FPGA. There is a potential problem when the\r
+FPGA is powered down; these outputs might go high and try to power the\r
+FPGA through the protection diodes. My present solution to this is a\r
+couple of resistors, which is not very elegeant.\r
+\r
+The high-frequency peak-detected receive path contains population options\r
+for many features that I do not currently use. A lot of these are just\r
+me guessing that if I provide options for different series and shunt\r
+passives, perhaps it will come in handy in some way. The Zener diodes D10\r
+and D11 are optional, but may protect the front end from an overvoltage\r
+(which will fry the peak detector diodes) when the `simulated tag'\r
+is read by a powerful reader.\r
+\r
+DETAILS: ANALOG TRANSMIT PATH\r
+=============================\r
+\r
+The coil drivers are just ACT244 bus buffers. I parallel eight of them\r
+for each antenna (eight for the high-frequency antenna, eight for the\r
+low-frequency antenna). This should easily provide a hundred milliamps\r
+coil drive or so, which is more than enough for anything that I imagine\r
+doing with the device. The drivers hit the coil with a square wave\r
+voltage, however, which means that it is only the bandpass filter effect\r
+of a resonant antenna that suppresses the odd harmonics. In practice it\r
+would probably take heroic efforts (high antenna Q) to meet the FCC/CE\r
+harmonic specs; and in practice no one cares.\r
+\r
+The tx strength, given good antenna tuning, is determined by the series\r
+resistors. Choose the ratios to stay within the rated current of the\r
+buffers, and to achieve the desired power ratios by enabling or disabling\r
+nOEs for the desired modulation index. It is useful to populate one of the\r
+resistors as a high value (~10k) for the simulated tag modes; this allows\r
+us to look at the incident carrier without loading the reader very much.\r
+\r
+DETAILS: ARM\r
+============\r
+\r
+Atmel makes a number of pin-compatible ARMs, with slightly different\r
+peripherals, and different amounts of flash and RAM. It is necessary\r
+to choose a device with enough flash not just for the ARM's program,\r
+but also for the FPGA image (which is loaded by the ARM).\r
+\r
+The ARM is responsible for programming the FPGA. It also supplies a\r
+clock to the FPGA (although the FPGA clock can also run off the 13.56\r
+MHz clock not used for anything else, which is obviously asynchronous\r
+to anything in the ARM).\r
+\r
+It is necessary to use JTAG to bring the ARM for the first time; at\r
+that point you can load a bootrom, and subsequently load new software\r
+over USB. It might be possible to use the ARM's pre-loaded bootloader\r
+(see datasheet) instead of JTAG, but I wanted the JTAG anyways for\r
+debugging, so I did not bother. I used a Wiggler clone, with Macraigor's\r
+OCD Commander. More expensive tools would work as well.\r
+\r
+USB SOFTWARE\r
+============\r
+\r
+At present I enumerate as an HID device. This saves me writing a driver,\r
+but it forces me to do interrupt transfers for everything. This limits\r
+speed and is not very elegant. A real USB driver would be nice, maybe\r
+even one that could do stuff like going isochronous to stream samples\r
+from the A/D for processing on the PC.\r
+\r
+PRETENDING TO BE A TAG\r
+======================\r
+\r
+It is not possible, with the given topology, to open-circuit the antenna\r
+entirely and still look at the signal received on it. The simulated tag\r
+modes must therefore switch between slight loading and heavy loading,\r
+not open- and short-circuts across the antenna, evening though they do\r
+not depend upon the incident carrier for power (just timing information).\r
+\r
+RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS\r
+===========================================\r
+\r
+There is a path straight from the antenna to the A/D, bypassing the peak\r
+detector assembly. This goes through a gain stage (just a fast voltage\r
+feedback opamp), and from there straight in to the mux.\r
+\r
+It is necessary to energize the relay to connect these paths. If the\r
+coil is driven (as if to excite and read a tag) while these paths are\r
+connected, then damage will probably result. Most likely the opamp\r
+will fry.\r
+\r
+READING A TAG\r
+=============\r
+\r
+The tag is excited by a carrier transmitted by the reader. This is\r
+generated by IC9 and IC10, using some combination of buffers. The transmit\r
+power is determined by selecting the right combination of PWR_OEx pins;\r
+drive more of them low for more power. This can be used to modulate the\r
+transmitted signal, and thus send information to the tag.\r
+\r
+The received signal from the antenna is first peak-detected, and then\r
+high-pass filtered to reject the unmodulated carrier. The signal is\r
+amplified a bit, and goes in to the A/D mux from there. The A/D is\r
+controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything\r
+synchronous to the 13.56 MHz carrier.\r
+\r
+INTERFACE FROM THE ARM TO THE FPGA\r
+==================================\r
+\r
+The FPGA and the ARM can communicate in two main ways: using the ARM's\r
+general-purpose synchronous serial port (the SSP), or using the ARM's\r
+SPI port. The SPI port is used to configure the FPGA. The ARM writes a\r
+configuration word to the FPGA, which determines what operation will\r
+be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz\r
+vs...). The SPI is used exclusively for configuration.\r
+\r
+The SSP is used for actual data sent over the air. The ARM's SSP can\r
+work in slave mode, which means that we can send the data using clocks\r
+generated by the FPGA (either from the PCK0 clock, which the ARM itself\r
+supplies, or from the 13.56 MHz clock, which is certainly not going to\r
+be synchronous to anything in the ARM), which saves synchronizing logic\r
+in the FPGA. The SSP is bi-directional and full-duplex.\r
+\r
projects / proxmark3-svn / blobdiff