mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2025-08-21 13:53:55 -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
|
||||
|
||||
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.
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue