github/RRG-Proxmark3
1
0
Fork 0
mirror of https://github.com/RfidResearchGroup/proxmark3.git synced 2025-08-21 13:53:55 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions

CRLF

Browse source
This commit is contained in:
Philippe Teuwen 2020-11-29 01:35:12 +01:00
commit 5dd8b3294a
4 changed files with 481 additions and 481 deletions
Download patch file Download diff file Expand all files Collapse all files

162
doc/cloner_notes.md
View file

@ -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 <x bytes>` then re-run the sniff to see if there is more data.

100
doc/colors_notes.md
View file

@ -1,50 +1,50 @@
<a id="Top"></a>
# 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.
<a id="Top"></a>
# 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.

498
doc/fpga_arm_notes.md
View file

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

202
doc/mfu_binary_format_notes.md
View file

@ -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"
}
}
```