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