mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2025-08-20 05:13:46 -07:00
CRLF
This commit is contained in:
parent
59667e5d1b
commit
5dd8b3294a
4 changed files with 481 additions and 481 deletions
|
@ -1,82 +1,82 @@
|
||||||
# Notes on Cloner guns
|
# Notes on Cloner guns
|
||||||
|
|
||||||
This document is based mostly on information posted on http://www.proxmark.org/forum/viewtopic.php?pid=39903#p39903
|
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)
|
- [Notes on Cloner guns](#notes-on-cloner-guns)
|
||||||
- [Blue and black cloners](#blue-and-black-cloners)
|
- [Blue and black cloners](#blue-and-black-cloners)
|
||||||
- [White cloner (pre 2015)](#white-cloner-pre-2015)
|
- [White cloner (pre 2015)](#white-cloner-pre-2015)
|
||||||
- [White cloner (after 2016)](#white-cloner-after-2016)
|
- [White cloner (after 2016)](#white-cloner-after-2016)
|
||||||
- [White cloner (after 2016 D Quality)](#white-cloner-after-2016-d-quality)
|
- [White cloner (after 2016 D Quality)](#white-cloner-after-2016-d-quality)
|
||||||
- [Restore page1 data](#restore-page1-data)
|
- [Restore page1 data](#restore-page1-data)
|
||||||
- [Sniffing the comms](#sniffing-the-comms)
|
- [Sniffing the comms](#sniffing-the-comms)
|
||||||
|
|
||||||
|
|
||||||
# Blue and black cloners
|
# Blue and black cloners
|
||||||
|
|
||||||
3 variants:
|
3 variants:
|
||||||
1. EM cloner
|
1. EM cloner
|
||||||
2. HID cloner
|
2. HID cloner
|
||||||
3. EM/HID cloner
|
3. EM/HID cloner
|
||||||
|
|
||||||
Quality varies my manufacturer (Quality A (Good) until D (Bad))
|
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
|
They set a password on block 7 of the chip and set the password enable bit in block 0
|
||||||
```
|
```
|
||||||
Standard password is normally: 51243648
|
Standard password is normally: 51243648
|
||||||
```
|
```
|
||||||
**Be sure to purchase the EM/HID version**
|
**Be sure to purchase the EM/HID version**
|
||||||
|
|
||||||
# White cloner (pre 2015)
|
# White cloner (pre 2015)
|
||||||
|
|
||||||
Multifrequency
|
Multifrequency
|
||||||
Buttons light up BLUE
|
Buttons light up BLUE
|
||||||
Reads data correctly
|
Reads data correctly
|
||||||
Coil performance acceptable
|
Coil performance acceptable
|
||||||
```
|
```
|
||||||
Standard password is normally (for T55xx): AA55BBBB
|
Standard password is normally (for T55xx): AA55BBBB
|
||||||
Standard password 13,56mHz: individual per white cloner
|
Standard password 13,56mHz: individual per white cloner
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
# White cloner (after 2016)
|
# White cloner (after 2016)
|
||||||
Multifrequency
|
Multifrequency
|
||||||
Buttons light up WHITE
|
Buttons light up WHITE
|
||||||
Data scrambled (variable per individual cloner, possibly due to prevent legal issues)
|
Data scrambled (variable per individual cloner, possibly due to prevent legal issues)
|
||||||
Coil performance good
|
Coil performance good
|
||||||
```
|
```
|
||||||
Standard password is normally (for T55xx): AA55BBBB
|
Standard password is normally (for T55xx): AA55BBBB
|
||||||
Standard password 13,56mHz: individual per white cloner
|
Standard password 13,56mHz: individual per white cloner
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
# White cloner (after 2016 D Quality)
|
# White cloner (after 2016 D Quality)
|
||||||
Multifrequency (it says so but it doesn't)
|
Multifrequency (it says so but it doesn't)
|
||||||
Only works for EM/HID card (125kHz)
|
Only works for EM/HID card (125kHz)
|
||||||
High frequency not working
|
High frequency not working
|
||||||
```
|
```
|
||||||
Standard password is normally (for T55xx): AA55BBBB
|
Standard password is normally (for T55xx): AA55BBBB
|
||||||
```
|
```
|
||||||
**Note: Sets the HID card in TEST MODE**
|
**Note: Sets the HID card in TEST MODE**
|
||||||
|
|
||||||
|
|
||||||
# Restore page1 data
|
# Restore page1 data
|
||||||
```
|
```
|
||||||
lf t55xx write b 1 d E0150A48 1
|
lf t55xx write b 1 d E0150A48 1
|
||||||
If t55xx write b 2 d 2D782308 1
|
If t55xx write b 2 d 2D782308 1
|
||||||
```
|
```
|
||||||
|
|
||||||
# Sniffing the comms
|
# 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.
|
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.
|
-- after threshold limit 20 is triggered, skip 10000 samples before collecting samples.
|
||||||
lf config s 10000 t 20
|
lf config s 10000 t 20
|
||||||
lf t55xx sniff
|
lf t55xx sniff
|
||||||
|
|
||||||
-- if you have a save trace from before, try
|
-- if you have a save trace from before, try
|
||||||
data load -f xxxxxxx.pm3
|
data load -f xxxxxxx.pm3
|
||||||
lf t55xx sniff 1
|
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.
|
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.
|
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.
|
|
@ -1,50 +1,50 @@
|
||||||
<a id="Top"></a>
|
<a id="Top"></a>
|
||||||
# Notes on Color usage.
|
# Notes on Color usage.
|
||||||
|
|
||||||
## Table of Contents
|
## Table of Contents
|
||||||
* [style/color](#style_color)
|
* [style/color](#style_color)
|
||||||
* [Proxspace](#proxspace)
|
* [Proxspace](#proxspace)
|
||||||
* [](#)
|
* [](#)
|
||||||
|
|
||||||
The client should autodetect color support when starting.
|
The client should autodetect color support when starting.
|
||||||
|
|
||||||
You can also use the command `pref show` to see and set your personal setting.
|
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.
|
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.
|
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
|
## style/color
|
||||||
^[Top](#top)
|
^[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.
|
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
|
### Definition
|
||||||
^[Top](#top)
|
^[Top](#top)
|
||||||
- blue - system related headers, banner
|
- blue - system related headers, banner
|
||||||
- white - normal
|
- white - normal
|
||||||
- cyan - headers
|
- cyan - headers
|
||||||
- red - warning, error, catastrophic failures
|
- red - warning, error, catastrophic failures
|
||||||
- yellow - informative (to make things stick out from white blob)
|
- yellow - informative (to make things stick out from white blob)
|
||||||
- green - successful, (to make things stick out from white blob)
|
- green - successful, (to make things stick out from white blob)
|
||||||
- magenta - device side messages
|
- magenta - device side messages
|
||||||
|
|
||||||
|
|
||||||
### Styled header
|
### Styled header
|
||||||
^[Top](#top)
|
^[Top](#top)
|
||||||
```
|
```
|
||||||
PrintAndLogEx(NORMAL, "");
|
PrintAndLogEx(NORMAL, "");
|
||||||
PrintAndLogEx(INFO, "--- " _CYAN_("Tag Information") " ---------------------------");
|
PrintAndLogEx(INFO, "--- " _CYAN_("Tag Information") " ---------------------------");
|
||||||
PrintAndLogEx(INFO, "-------------------------------------------------------------");
|
PrintAndLogEx(INFO, "-------------------------------------------------------------");
|
||||||
```
|
```
|
||||||
For more examples, see also all **-h** helptext now in the LUA scripts.
|
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.
|
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
|
### non styled header
|
||||||
^[Top](#top)
|
^[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.
|
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
|
## Proxspace
|
||||||
^[Top](#top)
|
^[Top](#top)
|
||||||
Proxspace has support for colors.
|
Proxspace has support for colors.
|
||||||
|
|
||||||
|
|
|
@ -1,249 +1,249 @@
|
||||||
# Notes on ARM & FPGA comms
|
# Notes on ARM & FPGA comms
|
||||||
|
|
||||||
|
|
||||||
https://github.com/RfidResearchGroup/proxmark3/blob/master/doc/original_proxmark3/proxmark3.pdf
|
https://github.com/RfidResearchGroup/proxmark3/blob/master/doc/original_proxmark3/proxmark3.pdf
|
||||||
|
|
||||||
INTERFACE FROM THE ARM TO THE FPGA
|
INTERFACE FROM THE ARM TO THE FPGA
|
||||||
==================================
|
==================================
|
||||||
|
|
||||||
The FPGA and the ARM can communicate in two main ways: using the ARM's
|
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
|
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
|
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
|
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
|
be performed (e.g. read 13.56 MHz vs. read 125 kHz vs. read 134 kHz
|
||||||
vs...). The SPI is used exclusively for configuration.
|
vs...). The SPI is used exclusively for configuration.
|
||||||
|
|
||||||
The SSP is used for actual data sent over the air. The ARM's SSP can
|
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
|
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
|
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
|
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
|
be synchronous to anything in the ARM), which saves synchronizing logic
|
||||||
in the FPGA. The SSP is bi-directional and full-duplex.
|
in the FPGA. The SSP is bi-directional and full-duplex.
|
||||||
|
|
||||||
|
|
||||||
The FPGA communicates with the ARM through either
|
The FPGA communicates with the ARM through either
|
||||||
1) SPI port (the ARM is the master)
|
1) SPI port (the ARM is the master)
|
||||||
2) SSC synchronous serial 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)
|
opamps, (*note, this affects source code in ARM, calculating actual voltage from antenna. Manufacturers never report what they use to much frustration)
|
||||||
comparators
|
comparators
|
||||||
coil drivers
|
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.
|
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
|
## 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.
|
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.
|
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.
|
The FPGA images is precompiled and located inside the /fpga folder.
|
||||||
- fpga_hf.bit
|
- fpga_hf.bit
|
||||||
- fpga_lf.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.
|
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.
|
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.
|
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`
|
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.
|
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.
|
### FPGA modes.
|
||||||
- Major modes
|
- Major modes
|
||||||
- Minor modes
|
- Minor modes
|
||||||
|
|
||||||
## ARM FPGA communications.
|
## ARM FPGA communications.
|
||||||
|
|
||||||
The ARM talks with FPGA over the Synchronous Serial Port (SSC) rx an tx.
|
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, send a 16bit configuration with fits the select major mode.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## ARM GPIO setup
|
## ARM GPIO setup
|
||||||
|
|
||||||
```
|
```
|
||||||
// First configure the GPIOs, and get ourselves a clock.
|
// First configure the GPIOs, and get ourselves a clock.
|
||||||
AT91C_BASE_PIOA->PIO_ASR =
|
AT91C_BASE_PIOA->PIO_ASR =
|
||||||
GPIO_SSC_FRAME |
|
GPIO_SSC_FRAME |
|
||||||
GPIO_SSC_DIN |
|
GPIO_SSC_DIN |
|
||||||
GPIO_SSC_DOUT |
|
GPIO_SSC_DOUT |
|
||||||
GPIO_SSC_CLK;
|
GPIO_SSC_CLK;
|
||||||
AT91C_BASE_PIOA->PIO_PDR = GPIO_SSC_DOUT;
|
AT91C_BASE_PIOA->PIO_PDR = GPIO_SSC_DOUT;
|
||||||
|
|
||||||
AT91C_BASE_PMC->PMC_PCER = (1 << AT91C_ID_SSC);
|
AT91C_BASE_PMC->PMC_PCER = (1 << AT91C_ID_SSC);
|
||||||
|
|
||||||
// Now set up the SSC proper, starting from a known state.
|
// Now set up the SSC proper, starting from a known state.
|
||||||
AT91C_BASE_SSC->SSC_CR = AT91C_SSC_SWRST;
|
AT91C_BASE_SSC->SSC_CR = AT91C_SSC_SWRST;
|
||||||
|
|
||||||
// RX clock comes from TX clock, RX starts on Transmit Start,
|
// RX clock comes from TX clock, RX starts on Transmit Start,
|
||||||
// data and frame signal is sampled on falling edge of RK
|
// 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);
|
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
|
// 8, 16 or 32 bits per transfer, no loopback, MSB first, 1 transfer per sync
|
||||||
// pulse, no output sync
|
// pulse, no output sync
|
||||||
if ((FPGA_mode & FPGA_MAJOR_MODE_MASK) == FPGA_MAJOR_MODE_HF_READER && FpgaGetCurrent() == FPGA_BITSTREAM_HF) {
|
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);
|
AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(16) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0);
|
||||||
} else {
|
} else {
|
||||||
AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(8) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0);
|
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,
|
// 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
|
// 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);
|
AT91C_BASE_SSC->SSC_TCMR = SSC_CLOCK_MODE_SELECT(2) | SSC_CLOCK_MODE_START(5);
|
||||||
|
|
||||||
// tx framing is the same as the rx framing
|
// tx framing is the same as the rx framing
|
||||||
AT91C_BASE_SSC->SSC_TFMR = AT91C_BASE_SSC->SSC_RFMR;
|
AT91C_BASE_SSC->SSC_TFMR = AT91C_BASE_SSC->SSC_RFMR;
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
## FPGA Setup
|
## FPGA Setup
|
||||||
|
|
||||||
// Set up DMA to receive samples from the FPGA. We will use the PDC, with
|
// 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
|
// a single buffer as a circular buffer (so that we just chain back to
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
# HARDWARE OVERVIEW
|
# HARDWARE OVERVIEW
|
||||||
|
|
||||||
## ADC (ANALOG TO DIGITAL CONVERTER)
|
## ADC (ANALOG TO DIGITAL CONVERTER)
|
||||||
The analogue signal that comes from the antenna circuit is fed into an 8-bit Analogue 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.
|
(ADC). This delivers 8 output bits in parallel which represent the current voltage retrieved from the field.
|
||||||
|
|
||||||
|
|
||||||
## FIELD PROGRAMMABLE GATE ARRAY, FPGA
|
## 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
|
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
|
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.
|
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
|
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
|
implementation on a normal microcontroller. Only a real hardware implementation would be faster but
|
||||||
this lacks the flexibility of an FPGA.
|
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
|
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:
|
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.
|
- "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.
|
- 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
|
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
|
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
|
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
|
schemes used to communicate the signal to the ARM are Modified Miller for the reader and Manchester
|
||||||
encoding for the card signal.
|
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
|
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
|
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.
|
FPGA generates an electromagnetic field on power hi and drops the amplitude for short periods.
|
||||||
|
|
||||||
|
|
||||||
## MICROCONTROLLER
|
## MICROCONTROLLER
|
||||||
The microcontroller is responsible for the protocol management. It receives the digital encoded signals
|
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
|
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
|
memory. Additionally, an answer to the received message can be send by encoding a reply and
|
||||||
communicating this to the FPGA.
|
communicating this to the FPGA.
|
||||||
|
|
||||||
The microcontroller (ARM) implements the transport layer. First it decodes the samples received from
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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.
|
Proxmark is used as a reader the BigBuf can be used to store status messages or protocol exceptions.
|
||||||
|
|
||||||
```
|
```
|
||||||
HF PATH
|
HF PATH
|
||||||
-- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT
|
-- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT
|
||||||
| | | |
|
| | | |
|
||||||
induct peak detect (8bit) -- modes:
|
induct peak detect (8bit) -- modes:
|
||||||
via circuit HF - peak-detected
|
via circuit HF - peak-detected
|
||||||
HF - RAW
|
HF - RAW
|
||||||
HF -
|
HF -
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
```
|
```
|
||||||
LF PATH
|
LF PATH
|
||||||
|
|
||||||
-- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT
|
-- ANTENNA -> rectifying -> lowpass filter -> ADC -> FPGA -> ARM -> USB/CDC | FPC -> CLIENT
|
||||||
| | | |
|
| | | |
|
||||||
induct peak detect (8bit) -- modes:
|
induct peak detect (8bit) -- modes:
|
||||||
via circuit LF - peak-detected
|
via circuit LF - peak-detected
|
||||||
LF - RAW
|
LF - RAW
|
||||||
```
|
```
|
||||||
Problems:
|
Problems:
|
||||||
1. dynamic range of signal. Ie: High Carrier signal (reader) and low
|
1. dynamic range of signal. Ie: High Carrier signal (reader) and low
|
||||||
|
|
||||||
|
|
||||||
##
|
##
|
||||||
|
|
||||||
## To behave like a READER.
|
## To behave like a READER.
|
||||||
By driving all of the buffers LOW, it is possible to make the antenna
|
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
|
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
|
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).
|
are not actively transmitting a carrier (i.e., behaving as a reader).
|
||||||
|
|
||||||
## To behave like a TAG
|
## To behave like a TAG
|
||||||
On the receive side, there are two possibilities, which are selected by
|
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
|
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
|
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
|
voltages on-board. In the usual case (PEAK-DETECTED mode), the received
|
||||||
signal is peak-detected by an analog circuit, then filtered slightly,
|
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
|
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
|
high-frequency paths, although the details of the circuits for the
|
||||||
two cases are somewhat different. This receive path would typically
|
two cases are somewhat different. This receive path would typically
|
||||||
be selected when the device is behaving as a reader, or when it is
|
be selected when the device is behaving as a reader, or when it is
|
||||||
eavesdropping at close range.
|
eavesdropping at close range.
|
||||||
|
|
||||||
It is also possible to digitize the signal from the antenna directly (RAW
|
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
|
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
|
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.
|
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
|
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
|
from there goes in to the FPGA. The FPGA is big enough that it
|
||||||
can perform DSP operations itself. For some high-frequency standards,
|
can perform DSP operations itself. For some high-frequency standards,
|
||||||
the subcarriers are fast enough that it would be inconvenient to do all
|
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 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
|
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
|
low-frequency tags, it probably makes sense just to pass data straight
|
||||||
through to the ARM.
|
through to the ARM.
|
||||||
|
|
||||||
The FPGA communicates with the ARM through either its SPI port (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) or its generic synchronous serial port (again, the ARM
|
||||||
is the master). The ARM connects to the outside world over USB.
|
is the master). The ARM connects to the outside world over USB.
|
||||||
|
|
||||||
## To sniff traffic
|
## To sniff traffic
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## FPGA purpose
|
## FPGA purpose
|
||||||
Digital signal processing.
|
Digital signal processing.
|
||||||
In short, apply low pass / hi pass filtering, peak detect, correlate signal meaning IQ pair collecting.
|
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.
|
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)
|
IQ1 = 1,1 : 1, -1 (rising)
|
||||||
IQ2 = -1,1 : 1, 1 (falling)
|
IQ2 = -1,1 : 1, 1 (falling)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
-1,1 | 1,1
|
-1,1 | 1,1
|
||||||
| (q2)
|
| (q2)
|
||||||
(i2) | (i1)
|
(i2) | (i1)
|
||||||
|
|
|
|
||||||
----------0------------>
|
----------0------------>
|
||||||
|
|
|
|
||||||
| (q1)
|
| (q1)
|
||||||
-1,-1 | 1, -1
|
-1,-1 | 1, -1
|
||||||
```
|
```
|
||||||
|
|
|
@ -1,101 +1,101 @@
|
||||||
# Notes on MFU binary formats
|
# Notes on MFU binary formats
|
||||||
|
|
||||||
- new mfu format
|
- new mfu format
|
||||||
- old mfu format
|
- old mfu format
|
||||||
- plain mfu format
|
- plain mfu format
|
||||||
- future mfu format
|
- future mfu format
|
||||||
|
|
||||||
## New mfu format
|
## New mfu format
|
||||||
The new mfu binary format was created to compensate for different manufactures tag functions.
|
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.
|
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
|
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.
|
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
|
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
|
// New Ultralight/NTAG dump file format
|
||||||
// Length must be aligned to 4 bytes (UL/NTAG page)
|
// Length must be aligned to 4 bytes (UL/NTAG page)
|
||||||
#define MFU_DUMP_PREFIX_LENGTH 56
|
#define MFU_DUMP_PREFIX_LENGTH 56
|
||||||
|
|
||||||
typedef struct {
|
typedef struct {
|
||||||
uint8_t version[8];
|
uint8_t version[8];
|
||||||
uint8_t tbo[2];
|
uint8_t tbo[2];
|
||||||
uint8_t tbo1[1];
|
uint8_t tbo1[1];
|
||||||
uint8_t pages; // max page number in dump
|
uint8_t pages; // max page number in dump
|
||||||
uint8_t signature[32];
|
uint8_t signature[32];
|
||||||
uint8_t counter_tearing[3][4]; // 3 bytes counter, 1 byte tearing flag
|
uint8_t counter_tearing[3][4]; // 3 bytes counter, 1 byte tearing flag
|
||||||
uint8_t data[1024];
|
uint8_t data[1024];
|
||||||
} PACKED mfu_dump_t;
|
} PACKED mfu_dump_t;
|
||||||
```
|
```
|
||||||
|
|
||||||
## Old mfu format
|
## 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.
|
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
|
// Old Ultralight/NTAG dump file format
|
||||||
#define OLD_MFU_DUMP_PREFIX_LENGTH 48
|
#define OLD_MFU_DUMP_PREFIX_LENGTH 48
|
||||||
|
|
||||||
typedef struct {
|
typedef struct {
|
||||||
uint8_t version[8];
|
uint8_t version[8];
|
||||||
uint8_t tbo[2];
|
uint8_t tbo[2];
|
||||||
uint8_t tearing[3];
|
uint8_t tearing[3];
|
||||||
uint8_t pack[2];
|
uint8_t pack[2];
|
||||||
uint8_t tbo1[1];
|
uint8_t tbo1[1];
|
||||||
uint8_t signature[32];
|
uint8_t signature[32];
|
||||||
uint8_t data[1024];
|
uint8_t data[1024];
|
||||||
} old_mfu_dump_t;
|
} old_mfu_dump_t;
|
||||||
```
|
```
|
||||||
|
|
||||||
## Plain mfu format
|
## Plain mfu format
|
||||||
The first binary format for MFU was just a memory dump from the tag block 0 to end.
|
The first binary format for MFU was just a memory dump from the tag block 0 to end.
|
||||||
No extra data was saved.
|
No extra data was saved.
|
||||||
```
|
```
|
||||||
uint8_t data[1024];
|
uint8_t data[1024];
|
||||||
```
|
```
|
||||||
|
|
||||||
## future mfu format
|
## future mfu format
|
||||||
For developers of apps and other tools, like libnfc, we don't recommend using binary formats.
|
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.
|
We decided to adopt a JSON based format, which is much more flexible to changes of new tag functionality.
|
||||||
|
|
||||||
Example
|
Example
|
||||||
```
|
```
|
||||||
{
|
{
|
||||||
"Created": "proxmark3",
|
"Created": "proxmark3",
|
||||||
"FileType": "mfu",
|
"FileType": "mfu",
|
||||||
"Card": {
|
"Card": {
|
||||||
"UID": "04F654CAFC388",
|
"UID": "04F654CAFC388",
|
||||||
"Version": "0004030101000B0",
|
"Version": "0004030101000B0",
|
||||||
"TBO_0": "000",
|
"TBO_0": "000",
|
||||||
"TBO_1": "0",
|
"TBO_1": "0",
|
||||||
"Signature": "BC9BFD4B550C16B2B5A5ABA10B644A027B4CB03DDB46F94D992DC0FB02E0C3F",
|
"Signature": "BC9BFD4B550C16B2B5A5ABA10B644A027B4CB03DDB46F94D992DC0FB02E0C3F",
|
||||||
"Counter0": "00000",
|
"Counter0": "00000",
|
||||||
"Tearing0": "BD",
|
"Tearing0": "BD",
|
||||||
"Counter1": "00000",
|
"Counter1": "00000",
|
||||||
"Tearing1": "BD",
|
"Tearing1": "BD",
|
||||||
"Counter2": "00000",
|
"Counter2": "00000",
|
||||||
"Tearing2": "BD"
|
"Tearing2": "BD"
|
||||||
},
|
},
|
||||||
"blocks": {
|
"blocks": {
|
||||||
"0": "04F6542",
|
"0": "04F6542",
|
||||||
"1": "CAFC388",
|
"1": "CAFC388",
|
||||||
"2": "8E48000",
|
"2": "8E48000",
|
||||||
"3": "E110120",
|
"3": "E110120",
|
||||||
"4": "0103A00",
|
"4": "0103A00",
|
||||||
"5": "340300F",
|
"5": "340300F",
|
||||||
"6": "0000000",
|
"6": "0000000",
|
||||||
"7": "0000000",
|
"7": "0000000",
|
||||||
"8": "0000000",
|
"8": "0000000",
|
||||||
"9": "0000000",
|
"9": "0000000",
|
||||||
"10": "0000000",
|
"10": "0000000",
|
||||||
"11": "0000000",
|
"11": "0000000",
|
||||||
"12": "1122334",
|
"12": "1122334",
|
||||||
"13": "0000000",
|
"13": "0000000",
|
||||||
"14": "0000000",
|
"14": "0000000",
|
||||||
"15": "0000000",
|
"15": "0000000",
|
||||||
"16": "000000F",
|
"16": "000000F",
|
||||||
"17": "0005000",
|
"17": "0005000",
|
||||||
"18": "0000000",
|
"18": "0000000",
|
||||||
"19": "0000000"
|
"19": "0000000"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue