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