diff --git a/doc/cloner_notes.md b/doc/cloner_notes.md index 2802f4494..71cada411 100644 --- a/doc/cloner_notes.md +++ b/doc/cloner_notes.md @@ -1,82 +1,82 @@ -# Notes on Cloner guns - -This document is based mostly on information posted on http://www.proxmark.org/forum/viewtopic.php?pid=39903#p39903 - -- [Notes on Cloner guns](#notes-on-cloner-guns) -- [Blue and black cloners](#blue-and-black-cloners) -- [White cloner (pre 2015)](#white-cloner-pre-2015) -- [White cloner (after 2016)](#white-cloner-after-2016) -- [White cloner (after 2016 D Quality)](#white-cloner-after-2016-d-quality) -- [Restore page1 data](#restore-page1-data) -- [Sniffing the comms](#sniffing-the-comms) - - -# Blue and black cloners - -3 variants: -1. EM cloner -2. HID cloner -3. EM/HID cloner - -Quality varies my manufacturer (Quality A (Good) until D (Bad)) -They set a password on block 7 of the chip and set the password enable bit in block 0 -``` -Standard password is normally: 51243648 -``` -**Be sure to purchase the EM/HID version** - -# White cloner (pre 2015) - -Multifrequency -Buttons light up BLUE -Reads data correctly -Coil performance acceptable -``` -Standard password is normally (for T55xx): AA55BBBB -Standard password 13,56mHz: individual per white cloner -``` - - -# White cloner (after 2016) -Multifrequency -Buttons light up WHITE -Data scrambled (variable per individual cloner, possibly due to prevent legal issues) -Coil performance good -``` -Standard password is normally (for T55xx): AA55BBBB -Standard password 13,56mHz: individual per white cloner -``` - - -# White cloner (after 2016 D Quality) -Multifrequency (it says so but it doesn't) -Only works for EM/HID card (125kHz) -High frequency not working -``` -Standard password is normally (for T55xx): AA55BBBB -``` -**Note: Sets the HID card in TEST MODE** - - -# Restore page1 data -``` -lf t55xx write b 1 d E0150A48 1 -If t55xx write b 2 d 2D782308 1 -``` - -# Sniffing the comms -The T55x7 protocol uses a pwm based protocol for writing to tags. In order to make decoding easier try the new command as seen below instead. It will try to extract the data written. - -``` --- after threshold limit 20 is triggered, skip 10000 samples before collecting samples. -lf config s 10000 t 20 -lf t55xx sniff - --- if you have a save trace from before, try -data load -f xxxxxxx.pm3 -lf t55xx sniff 1 -``` - -It uses the existing `lf sniff` command to collect the data, so setting that first as per normal sniffing is recommended. Once you have a sniff, you can "re-sniff" from the stored sniffed data and try different settings, if you think the data is not clean. - +# Notes on Cloner guns + +This document is based mostly on information posted on http://www.proxmark.org/forum/viewtopic.php?pid=39903#p39903 + +- [Notes on Cloner guns](#notes-on-cloner-guns) +- [Blue and black cloners](#blue-and-black-cloners) +- [White cloner (pre 2015)](#white-cloner-pre-2015) +- [White cloner (after 2016)](#white-cloner-after-2016) +- [White cloner (after 2016 D Quality)](#white-cloner-after-2016-d-quality) +- [Restore page1 data](#restore-page1-data) +- [Sniffing the comms](#sniffing-the-comms) + + +# Blue and black cloners + +3 variants: +1. EM cloner +2. HID cloner +3. EM/HID cloner + +Quality varies my manufacturer (Quality A (Good) until D (Bad)) +They set a password on block 7 of the chip and set the password enable bit in block 0 +``` +Standard password is normally: 51243648 +``` +**Be sure to purchase the EM/HID version** + +# White cloner (pre 2015) + +Multifrequency +Buttons light up BLUE +Reads data correctly +Coil performance acceptable +``` +Standard password is normally (for T55xx): AA55BBBB +Standard password 13,56mHz: individual per white cloner +``` + + +# White cloner (after 2016) +Multifrequency +Buttons light up WHITE +Data scrambled (variable per individual cloner, possibly due to prevent legal issues) +Coil performance good +``` +Standard password is normally (for T55xx): AA55BBBB +Standard password 13,56mHz: individual per white cloner +``` + + +# White cloner (after 2016 D Quality) +Multifrequency (it says so but it doesn't) +Only works for EM/HID card (125kHz) +High frequency not working +``` +Standard password is normally (for T55xx): AA55BBBB +``` +**Note: Sets the HID card in TEST MODE** + + +# Restore page1 data +``` +lf t55xx write b 1 d E0150A48 1 +If t55xx write b 2 d 2D782308 1 +``` + +# Sniffing the comms +The T55x7 protocol uses a pwm based protocol for writing to tags. In order to make decoding easier try the new command as seen below instead. It will try to extract the data written. + +``` +-- after threshold limit 20 is triggered, skip 10000 samples before collecting samples. +lf config s 10000 t 20 +lf t55xx sniff + +-- if you have a save trace from before, try +data load -f xxxxxxx.pm3 +lf t55xx sniff 1 +``` + +It uses the existing `lf sniff` command to collect the data, so setting that first as per normal sniffing is recommended. Once you have a sniff, you can "re-sniff" from the stored sniffed data and try different settings, if you think the data is not clean. + As normal, the cloner may write data past the end of the 40K sample buffer. So using the `lf config s ` then re-run the sniff to see if there is more data. \ No newline at end of file diff --git a/doc/colors_notes.md b/doc/colors_notes.md index c06a584e1..74d0cbb92 100644 --- a/doc/colors_notes.md +++ b/doc/colors_notes.md @@ -1,50 +1,50 @@ - -# Notes on Color usage. - -## Table of Contents - * [style/color](#style_color) - * [Proxspace](#proxspace) - * [](#) - -The client should autodetect color support when starting. - -You can also use the command `pref show` to see and set your personal setting. - -Why use colors in the Proxmark client? When everything is white it is hard to extract the important information fast. You also need new-lines for extra space to be easier to read. -We have gradually been introducing this color scheme into the client since we got decent color support on all systems: OSX, Linux, WSL, Proxspace. - - -## style/color -^[Top](#top) -The following definition has be crystallized out from these experiments. Its not set in stone yet so take this document as a guideline for how to create unified system scheme. - -### Definition -^[Top](#top) -- blue - system related headers, banner -- white - normal -- cyan - headers -- red - warning, error, catastrophic failures -- yellow - informative (to make things stick out from white blob) -- green - successful, (to make things stick out from white blob) -- magenta - device side messages - - -### Styled header -^[Top](#top) -``` - PrintAndLogEx(NORMAL, ""); - PrintAndLogEx(INFO, "--- " _CYAN_("Tag Information") " ---------------------------"); - PrintAndLogEx(INFO, "-------------------------------------------------------------"); -``` -For more examples, see also all **-h** helptext now in the LUA scripts. -For the command help texts using _YELLOW_ for the example makes it very easy to see what is the command vs the description. - -### non styled header -^[Top](#top) -Most commands doesn't use a header yet. We added it to make it standout (ie: yellow, green) of the informative tidbits in the output of a command. - - -## Proxspace -^[Top](#top) -Proxspace has support for colors. - + +# Notes on Color usage. + +## Table of Contents + * [style/color](#style_color) + * [Proxspace](#proxspace) + * [](#) + +The client should autodetect color support when starting. + +You can also use the command `pref show` to see and set your personal setting. + +Why use colors in the Proxmark client? When everything is white it is hard to extract the important information fast. You also need new-lines for extra space to be easier to read. +We have gradually been introducing this color scheme into the client since we got decent color support on all systems: OSX, Linux, WSL, Proxspace. + + +## style/color +^[Top](#top) +The following definition has be crystallized out from these experiments. Its not set in stone yet so take this document as a guideline for how to create unified system scheme. + +### Definition +^[Top](#top) +- blue - system related headers, banner +- white - normal +- cyan - headers +- red - warning, error, catastrophic failures +- yellow - informative (to make things stick out from white blob) +- green - successful, (to make things stick out from white blob) +- magenta - device side messages + + +### Styled header +^[Top](#top) +``` + PrintAndLogEx(NORMAL, ""); + PrintAndLogEx(INFO, "--- " _CYAN_("Tag Information") " ---------------------------"); + PrintAndLogEx(INFO, "-------------------------------------------------------------"); +``` +For more examples, see also all **-h** helptext now in the LUA scripts. +For the command help texts using _YELLOW_ for the example makes it very easy to see what is the command vs the description. + +### non styled header +^[Top](#top) +Most commands doesn't use a header yet. We added it to make it standout (ie: yellow, green) of the informative tidbits in the output of a command. + + +## Proxspace +^[Top](#top) +Proxspace has support for colors. + diff --git a/doc/fpga_arm_notes.md b/doc/fpga_arm_notes.md index 15a09057a..37aa6a911 100644 --- a/doc/fpga_arm_notes.md +++ b/doc/fpga_arm_notes.md @@ -1,249 +1,249 @@ -# Notes on ARM & FPGA comms - - -https://github.com/RfidResearchGroup/proxmark3/blob/master/doc/original_proxmark3/proxmark3.pdf - -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. - - -The FPGA communicates with the ARM through either -1) SPI port (the ARM is the master) -2) SSC synchronous serial port (the ARM is the master). - - -opamps, (*note, this affects source code in ARM, calculating actual voltage from antenna. Manufacturers never report what they use to much frustration) -comparators -coil drivers - -LF analog path (MCP6294 opamp. This has a GBW of 10 MHz), all 'slow' signals. Used for low frequency signals. Follows the peak detector. Signal centered around generated voltage Vmid. - - -## FPGA -Since the SPARTAN II is a old outdated FPGA, thus is very limited resource there was a need to split LF and HF functionality into two separate FPGA images. Which are stored in ARM flash memory as bitstreams. - -We swap between these images by flashing fpga from ARM on the go. It takes about 1sec. Hence its usually a bad idea to program your device to continuously execute LF alt HF commands. - -The FPGA images is precompiled and located inside the /fpga folder. - - fpga_hf.bit - - fpga_lf.bit - -There is very rarely changes to the images so there is no need to setup a fpga tool chain to compile it yourself. -Since the FPGA is very old, the Xilinx WebPack ISE 10.1 is the last working tool chain. You can download this legacy development on Xilinx and register for a free product installation id. -Or use mine `11LTAJ5ZJK3PXTUBMF0C0J6C4` The package to download is about 7Gb and linux based. Though I recently managed to install it on WSL for Windows 10. - -In order to save space, these fpga images are LZ4 compressed and included in the fullimage.elf file when compiling the ARM SRC. `make armsrc` -This means we save some precious space on the ARM but its a bit more complex when flashing to fpga since it has to decompress on the fly. - - -### FPGA modes. - - Major modes - - Minor modes - -## ARM FPGA communications. - -The ARM talks with FPGA over the Synchronous Serial Port (SSC) rx an tx. - -ARM, send a 16bit configuration with fits the select major mode. - - - -## ARM GPIO setup - -``` - // First configure the GPIOs, and get ourselves a clock. - AT91C_BASE_PIOA->PIO_ASR = - GPIO_SSC_FRAME | - GPIO_SSC_DIN | - GPIO_SSC_DOUT | - GPIO_SSC_CLK; - AT91C_BASE_PIOA->PIO_PDR = GPIO_SSC_DOUT; - - AT91C_BASE_PMC->PMC_PCER = (1 << AT91C_ID_SSC); - - // Now set up the SSC proper, starting from a known state. - AT91C_BASE_SSC->SSC_CR = AT91C_SSC_SWRST; - - // RX clock comes from TX clock, RX starts on Transmit Start, - // data and frame signal is sampled on falling edge of RK - AT91C_BASE_SSC->SSC_RCMR = SSC_CLOCK_MODE_SELECT(1) | SSC_CLOCK_MODE_START(1); - - // 8, 16 or 32 bits per transfer, no loopback, MSB first, 1 transfer per sync - // pulse, no output sync - if ((FPGA_mode & FPGA_MAJOR_MODE_MASK) == FPGA_MAJOR_MODE_HF_READER && FpgaGetCurrent() == FPGA_BITSTREAM_HF) { - AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(16) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0); - } else { - AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(8) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0); - } - - // TX clock comes from TK pin, no clock output, outputs change on rising edge of TK, - // TF (frame sync) is sampled on falling edge of TK, start TX on rising edge of TF - AT91C_BASE_SSC->SSC_TCMR = SSC_CLOCK_MODE_SELECT(2) | SSC_CLOCK_MODE_START(5); - - // tx framing is the same as the rx framing - AT91C_BASE_SSC->SSC_TFMR = AT91C_BASE_SSC->SSC_RFMR; - -``` - -## FPGA Setup - -// Set up DMA to receive samples from the FPGA. We will use the PDC, with -// a single buffer as a circular buffer (so that we just chain back to - - - -# HARDWARE OVERVIEW - -## ADC (ANALOG TO DIGITAL CONVERTER) -The analogue signal that comes from the antenna circuit is fed into an 8-bit Analogue to Digital Converter -(ADC). This delivers 8 output bits in parallel which represent the current voltage retrieved from the field. - - -## FIELD PROGRAMMABLE GATE ARRAY, FPGA -The 8 output pins from the ADC are connected to 8 pins of the Field Programmable Gate Array (FPGA). An -FPGA has a great advantage over a normal microcontroller in the sense that it emulates hardware. A -hardware description can be compiled and flashed into an FPGA. - -Because basic arithmetic functions can be performed fast and in parallel by an FPGA it is faster than an -implementation on a normal microcontroller. Only a real hardware implementation would be faster but -this lacks the flexibility of an FPGA. - -The FPGA can therefore be seen as dynamic hardware. It is possible to make a hardware design and flash -it into the memory of the FPGA. This gives some major advantages: - - - - "Hardware" errors can be corrected; the FPGA can be flashed with a new hardware design. - - Although not as fast as a real hardware implementation, an FPGA is faster than its equivalent on microprocessor. That is, it is specialized for one job. - -The FPGA has two main tasks. The first task is to demodulate the signal received from the ADC and relay -this as a digital encoded signal to the ARM. Depending on the task this might be the demodulation of a -100% Amplitude Shift Keying (ASK) signal from the reader or the load modulation of a card. The encoding -schemes used to communicate the signal to the ARM are Modified Miller for the reader and Manchester -encoding for the card signal. - -The second task is to modulate an encoded signal that is received from the ARM into the field of the -antenna. This can be both the encoding of reader messages or card messages. For reader messages the -FPGA generates an electromagnetic field on power hi and drops the amplitude for short periods. - - -## MICROCONTROLLER -The microcontroller is responsible for the protocol management. It receives the digital encoded signals -from the FPGA and decodes them. The decoded signals can just be copied to a buffer in the EEPROM -memory. Additionally, an answer to the received message can be send by encoding a reply and -communicating this to the FPGA. - -The microcontroller (ARM) implements the transport layer. First it decodes the samples received from -the FPGA. These samples are stored in a Direct Memory Access (DMA) buffer. The samples are binary -sequences that represent whether the signal was high or low. The software on the ARM tries to decode -these samples. When the Proxmark is in sniffing mode this is done for both the Manchester and Modified -Miller at the same time. Whenever one of the decoding procedures returns a valid message, this message -is stored in another buffer (BigBuf) and both decoding procedures are set to an un-synced state. The -BigBuf is limited to the available memory on the ARM. The current firmware has 2 KB of memory -reserved for traces (Besides the trace, the buffer also stores some temporary data that is needed in the -processing). When the BigBuf buffer is full the function normally returns. A new function call from the -client is needed to download the BigBuf contents to the computer. The BigBuf is especially useful for -protocol investigation. Every single message is stored in this buffer. When a card is emulated or when the -Proxmark is used as a reader the BigBuf can be used to store status messages or protocol exceptions. - -``` -HF PATH - -- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT - | | | | - induct peak detect (8bit) -- modes: - via circuit HF - peak-detected - HF - RAW - HF - -``` - - -``` -LF PATH - - -- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT - | | | | - induct peak detect (8bit) -- modes: - via circuit LF - peak-detected - LF - RAW -``` -Problems: - 1. dynamic range of signal. Ie: High Carrier signal (reader) and low - - -## - -## To behave like a READER. -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). - -## To behave like a TAG -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. - -In either case, an analog signal is digitized by the ADC, and -from there goes in to the FPGA. 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. - -## To sniff traffic - - - -## FPGA purpose -Digital signal processing. -In short, apply low pass / hi pass filtering, peak detect, correlate signal meaning IQ pair collecting. - -IQ means measure at In-phase and 90 phase shift later Quadrature-phase, with IQ samples you can plot the signal on a vector plan. - - -``` -IQ1 = 1,1 : 1, -1 (rising) -IQ2 = -1,1 : 1, 1 (falling) - - - - -1,1 | 1,1 - | (q2) - (i2) | (i1) - | - ----------0------------> - | - | (q1) - -1,-1 | 1, -1 -``` +# Notes on ARM & FPGA comms + + +https://github.com/RfidResearchGroup/proxmark3/blob/master/doc/original_proxmark3/proxmark3.pdf + +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. + + +The FPGA communicates with the ARM through either +1) SPI port (the ARM is the master) +2) SSC synchronous serial port (the ARM is the master). + + +opamps, (*note, this affects source code in ARM, calculating actual voltage from antenna. Manufacturers never report what they use to much frustration) +comparators +coil drivers + +LF analog path (MCP6294 opamp. This has a GBW of 10 MHz), all 'slow' signals. Used for low frequency signals. Follows the peak detector. Signal centered around generated voltage Vmid. + + +## FPGA +Since the SPARTAN II is a old outdated FPGA, thus is very limited resource there was a need to split LF and HF functionality into two separate FPGA images. Which are stored in ARM flash memory as bitstreams. + +We swap between these images by flashing fpga from ARM on the go. It takes about 1sec. Hence its usually a bad idea to program your device to continuously execute LF alt HF commands. + +The FPGA images is precompiled and located inside the /fpga folder. + - fpga_hf.bit + - fpga_lf.bit + +There is very rarely changes to the images so there is no need to setup a fpga tool chain to compile it yourself. +Since the FPGA is very old, the Xilinx WebPack ISE 10.1 is the last working tool chain. You can download this legacy development on Xilinx and register for a free product installation id. +Or use mine `11LTAJ5ZJK3PXTUBMF0C0J6C4` The package to download is about 7Gb and linux based. Though I recently managed to install it on WSL for Windows 10. + +In order to save space, these fpga images are LZ4 compressed and included in the fullimage.elf file when compiling the ARM SRC. `make armsrc` +This means we save some precious space on the ARM but its a bit more complex when flashing to fpga since it has to decompress on the fly. + + +### FPGA modes. + - Major modes + - Minor modes + +## ARM FPGA communications. + +The ARM talks with FPGA over the Synchronous Serial Port (SSC) rx an tx. + +ARM, send a 16bit configuration with fits the select major mode. + + + +## ARM GPIO setup + +``` + // First configure the GPIOs, and get ourselves a clock. + AT91C_BASE_PIOA->PIO_ASR = + GPIO_SSC_FRAME | + GPIO_SSC_DIN | + GPIO_SSC_DOUT | + GPIO_SSC_CLK; + AT91C_BASE_PIOA->PIO_PDR = GPIO_SSC_DOUT; + + AT91C_BASE_PMC->PMC_PCER = (1 << AT91C_ID_SSC); + + // Now set up the SSC proper, starting from a known state. + AT91C_BASE_SSC->SSC_CR = AT91C_SSC_SWRST; + + // RX clock comes from TX clock, RX starts on Transmit Start, + // data and frame signal is sampled on falling edge of RK + AT91C_BASE_SSC->SSC_RCMR = SSC_CLOCK_MODE_SELECT(1) | SSC_CLOCK_MODE_START(1); + + // 8, 16 or 32 bits per transfer, no loopback, MSB first, 1 transfer per sync + // pulse, no output sync + if ((FPGA_mode & FPGA_MAJOR_MODE_MASK) == FPGA_MAJOR_MODE_HF_READER && FpgaGetCurrent() == FPGA_BITSTREAM_HF) { + AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(16) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0); + } else { + AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(8) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0); + } + + // TX clock comes from TK pin, no clock output, outputs change on rising edge of TK, + // TF (frame sync) is sampled on falling edge of TK, start TX on rising edge of TF + AT91C_BASE_SSC->SSC_TCMR = SSC_CLOCK_MODE_SELECT(2) | SSC_CLOCK_MODE_START(5); + + // tx framing is the same as the rx framing + AT91C_BASE_SSC->SSC_TFMR = AT91C_BASE_SSC->SSC_RFMR; + +``` + +## FPGA Setup + +// Set up DMA to receive samples from the FPGA. We will use the PDC, with +// a single buffer as a circular buffer (so that we just chain back to + + + +# HARDWARE OVERVIEW + +## ADC (ANALOG TO DIGITAL CONVERTER) +The analogue signal that comes from the antenna circuit is fed into an 8-bit Analogue to Digital Converter +(ADC). This delivers 8 output bits in parallel which represent the current voltage retrieved from the field. + + +## FIELD PROGRAMMABLE GATE ARRAY, FPGA +The 8 output pins from the ADC are connected to 8 pins of the Field Programmable Gate Array (FPGA). An +FPGA has a great advantage over a normal microcontroller in the sense that it emulates hardware. A +hardware description can be compiled and flashed into an FPGA. + +Because basic arithmetic functions can be performed fast and in parallel by an FPGA it is faster than an +implementation on a normal microcontroller. Only a real hardware implementation would be faster but +this lacks the flexibility of an FPGA. + +The FPGA can therefore be seen as dynamic hardware. It is possible to make a hardware design and flash +it into the memory of the FPGA. This gives some major advantages: + + + - "Hardware" errors can be corrected; the FPGA can be flashed with a new hardware design. + - Although not as fast as a real hardware implementation, an FPGA is faster than its equivalent on microprocessor. That is, it is specialized for one job. + +The FPGA has two main tasks. The first task is to demodulate the signal received from the ADC and relay +this as a digital encoded signal to the ARM. Depending on the task this might be the demodulation of a +100% Amplitude Shift Keying (ASK) signal from the reader or the load modulation of a card. The encoding +schemes used to communicate the signal to the ARM are Modified Miller for the reader and Manchester +encoding for the card signal. + +The second task is to modulate an encoded signal that is received from the ARM into the field of the +antenna. This can be both the encoding of reader messages or card messages. For reader messages the +FPGA generates an electromagnetic field on power hi and drops the amplitude for short periods. + + +## MICROCONTROLLER +The microcontroller is responsible for the protocol management. It receives the digital encoded signals +from the FPGA and decodes them. The decoded signals can just be copied to a buffer in the EEPROM +memory. Additionally, an answer to the received message can be send by encoding a reply and +communicating this to the FPGA. + +The microcontroller (ARM) implements the transport layer. First it decodes the samples received from +the FPGA. These samples are stored in a Direct Memory Access (DMA) buffer. The samples are binary +sequences that represent whether the signal was high or low. The software on the ARM tries to decode +these samples. When the Proxmark is in sniffing mode this is done for both the Manchester and Modified +Miller at the same time. Whenever one of the decoding procedures returns a valid message, this message +is stored in another buffer (BigBuf) and both decoding procedures are set to an un-synced state. The +BigBuf is limited to the available memory on the ARM. The current firmware has 2 KB of memory +reserved for traces (Besides the trace, the buffer also stores some temporary data that is needed in the +processing). When the BigBuf buffer is full the function normally returns. A new function call from the +client is needed to download the BigBuf contents to the computer. The BigBuf is especially useful for +protocol investigation. Every single message is stored in this buffer. When a card is emulated or when the +Proxmark is used as a reader the BigBuf can be used to store status messages or protocol exceptions. + +``` +HF PATH + -- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT + | | | | + induct peak detect (8bit) -- modes: + via circuit HF - peak-detected + HF - RAW + HF - +``` + + +``` +LF PATH + + -- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT + | | | | + induct peak detect (8bit) -- modes: + via circuit LF - peak-detected + LF - RAW +``` +Problems: + 1. dynamic range of signal. Ie: High Carrier signal (reader) and low + + +## + +## To behave like a READER. +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). + +## To behave like a TAG +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. + +In either case, an analog signal is digitized by the ADC, and +from there goes in to the FPGA. 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. + +## To sniff traffic + + + +## FPGA purpose +Digital signal processing. +In short, apply low pass / hi pass filtering, peak detect, correlate signal meaning IQ pair collecting. + +IQ means measure at In-phase and 90 phase shift later Quadrature-phase, with IQ samples you can plot the signal on a vector plan. + + +``` +IQ1 = 1,1 : 1, -1 (rising) +IQ2 = -1,1 : 1, 1 (falling) + + + + -1,1 | 1,1 + | (q2) + (i2) | (i1) + | + ----------0------------> + | + | (q1) + -1,-1 | 1, -1 +``` diff --git a/doc/mfu_binary_format_notes.md b/doc/mfu_binary_format_notes.md index dfde0da7a..85935160b 100644 --- a/doc/mfu_binary_format_notes.md +++ b/doc/mfu_binary_format_notes.md @@ -1,101 +1,101 @@ -# Notes on MFU binary formats - - - new mfu format - - old mfu format - - plain mfu format - - future mfu format - -## New mfu format -The new mfu binary format was created to compensate for different manufactures tag functions. -Like UL-Ev1 has three counter and tearing bytes, while NTAG only has one counter and tearing byte. -PACK was removed from header, since its just normally part of the tag memory, unreadable, but when -a proxmark3 dumps a tag and we have pwd/pack, we add those to their normal location in memory. -This makes memory not a exact memory dump from a tag, but a "what it should have looked like" if we could read all memory - -``` -// New Ultralight/NTAG dump file format -// Length must be aligned to 4 bytes (UL/NTAG page) -#define MFU_DUMP_PREFIX_LENGTH 56 - -typedef struct { - uint8_t version[8]; - uint8_t tbo[2]; - uint8_t tbo1[1]; - uint8_t pages; // max page number in dump - uint8_t signature[32]; - uint8_t counter_tearing[3][4]; // 3 bytes counter, 1 byte tearing flag - uint8_t data[1024]; -} PACKED mfu_dump_t; -``` - -## Old mfu format -The old binary format saved the extra data on tag in order for the Proxmark3 to able to simulate a real tag. - -``` -// Old Ultralight/NTAG dump file format -#define OLD_MFU_DUMP_PREFIX_LENGTH 48 - -typedef struct { - uint8_t version[8]; - uint8_t tbo[2]; - uint8_t tearing[3]; - uint8_t pack[2]; - uint8_t tbo1[1]; - uint8_t signature[32]; - uint8_t data[1024]; -} old_mfu_dump_t; -``` - -## Plain mfu format -The first binary format for MFU was just a memory dump from the tag block 0 to end. -No extra data was saved. -``` - uint8_t data[1024]; -``` - -## future mfu format -For developers of apps and other tools, like libnfc, we don't recommend using binary formats. -We decided to adopt a JSON based format, which is much more flexible to changes of new tag functionality. - -Example -``` -{ - "Created": "proxmark3", - "FileType": "mfu", - "Card": { - "UID": "04F654CAFC388", - "Version": "0004030101000B0", - "TBO_0": "000", - "TBO_1": "0", - "Signature": "BC9BFD4B550C16B2B5A5ABA10B644A027B4CB03DDB46F94D992DC0FB02E0C3F", - "Counter0": "00000", - "Tearing0": "BD", - "Counter1": "00000", - "Tearing1": "BD", - "Counter2": "00000", - "Tearing2": "BD" - }, - "blocks": { - "0": "04F6542", - "1": "CAFC388", - "2": "8E48000", - "3": "E110120", - "4": "0103A00", - "5": "340300F", - "6": "0000000", - "7": "0000000", - "8": "0000000", - "9": "0000000", - "10": "0000000", - "11": "0000000", - "12": "1122334", - "13": "0000000", - "14": "0000000", - "15": "0000000", - "16": "000000F", - "17": "0005000", - "18": "0000000", - "19": "0000000" - } -} -``` +# Notes on MFU binary formats + + - new mfu format + - old mfu format + - plain mfu format + - future mfu format + +## New mfu format +The new mfu binary format was created to compensate for different manufactures tag functions. +Like UL-Ev1 has three counter and tearing bytes, while NTAG only has one counter and tearing byte. +PACK was removed from header, since its just normally part of the tag memory, unreadable, but when +a proxmark3 dumps a tag and we have pwd/pack, we add those to their normal location in memory. +This makes memory not a exact memory dump from a tag, but a "what it should have looked like" if we could read all memory + +``` +// New Ultralight/NTAG dump file format +// Length must be aligned to 4 bytes (UL/NTAG page) +#define MFU_DUMP_PREFIX_LENGTH 56 + +typedef struct { + uint8_t version[8]; + uint8_t tbo[2]; + uint8_t tbo1[1]; + uint8_t pages; // max page number in dump + uint8_t signature[32]; + uint8_t counter_tearing[3][4]; // 3 bytes counter, 1 byte tearing flag + uint8_t data[1024]; +} PACKED mfu_dump_t; +``` + +## Old mfu format +The old binary format saved the extra data on tag in order for the Proxmark3 to able to simulate a real tag. + +``` +// Old Ultralight/NTAG dump file format +#define OLD_MFU_DUMP_PREFIX_LENGTH 48 + +typedef struct { + uint8_t version[8]; + uint8_t tbo[2]; + uint8_t tearing[3]; + uint8_t pack[2]; + uint8_t tbo1[1]; + uint8_t signature[32]; + uint8_t data[1024]; +} old_mfu_dump_t; +``` + +## Plain mfu format +The first binary format for MFU was just a memory dump from the tag block 0 to end. +No extra data was saved. +``` + uint8_t data[1024]; +``` + +## future mfu format +For developers of apps and other tools, like libnfc, we don't recommend using binary formats. +We decided to adopt a JSON based format, which is much more flexible to changes of new tag functionality. + +Example +``` +{ + "Created": "proxmark3", + "FileType": "mfu", + "Card": { + "UID": "04F654CAFC388", + "Version": "0004030101000B0", + "TBO_0": "000", + "TBO_1": "0", + "Signature": "BC9BFD4B550C16B2B5A5ABA10B644A027B4CB03DDB46F94D992DC0FB02E0C3F", + "Counter0": "00000", + "Tearing0": "BD", + "Counter1": "00000", + "Tearing1": "BD", + "Counter2": "00000", + "Tearing2": "BD" + }, + "blocks": { + "0": "04F6542", + "1": "CAFC388", + "2": "8E48000", + "3": "E110120", + "4": "0103A00", + "5": "340300F", + "6": "0000000", + "7": "0000000", + "8": "0000000", + "9": "0000000", + "10": "0000000", + "11": "0000000", + "12": "1122334", + "13": "0000000", + "14": "0000000", + "15": "0000000", + "16": "000000F", + "17": "0005000", + "18": "0000000", + "19": "0000000" + } +} +```