reorganize doc
This commit is contained in:
Philippe Teuwen
@@ -0,0 +1,60 @@
|
||||
# Setup and build for ArchLinux
|
||||
|
||||
## Notes
|
||||
|
||||
Kali and ArchLinux users usually must kill their modem manager in order for the proxmark3 to enumerate properly.
|
||||
`sudo apt remove modemmanager`
|
||||
|
||||
## Manual Installation
|
||||
Run
|
||||
```sh
|
||||
sudo pacman -Sy base-devel p7zip libusb readline ncurses arm-none-eabi-newlib --needed
|
||||
```
|
||||
```sh
|
||||
yaourt -S termcap
|
||||
```
|
||||
|
||||
```sh
|
||||
sudo apt remove modemmanager
|
||||
```
|
||||
or
|
||||
```sh
|
||||
systemctl stop ModemManager
|
||||
systemctl disable ModemManager
|
||||
```
|
||||
|
||||
Clone fork
|
||||
```sh
|
||||
git clone https://github.com/RfidResearchGroup/proxmark3.git
|
||||
```
|
||||
|
||||
Get the latest commits
|
||||
```sh
|
||||
git pull
|
||||
```
|
||||
|
||||
Install the blacklist rules and add user to dialout group (if you on a Linux/ubuntu/debian).
|
||||
If you do this one, you need to logout and login in again to make sure your rights got changed.
|
||||
```sh
|
||||
make udev
|
||||
```
|
||||
|
||||
Clean and complete compilation
|
||||
```sh
|
||||
make clean && make all
|
||||
```
|
||||
|
||||
Flash the BOOTROM & FULLIMAGE
|
||||
```sh
|
||||
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
|
||||
```
|
||||
|
||||
Change into the client folder
|
||||
```sh
|
||||
cd client
|
||||
```
|
||||
|
||||
Run the client
|
||||
```sh
|
||||
./proxmark3 /dev/ttyACM0
|
||||
```
|
||||
@@ -0,0 +1,24 @@
|
||||
|
||||
## Coverity Scan Config & Run
|
||||
Download the Coverity Scan Self-buld and install it.
|
||||
You will need to configure ARM-NON-EABI- Compiler for it to use:
|
||||
|
||||
Configure
|
||||
|
||||
```sh
|
||||
cov-configure --comptype gcc --compiler /opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc
|
||||
```
|
||||
|
||||
Run it (I'm running on Ubuntu)
|
||||
|
||||
```sh
|
||||
cov-build --dir cov-int make all
|
||||
```
|
||||
|
||||
Make a tarball
|
||||
|
||||
```sh
|
||||
tar czvf proxmark3.tgz cov-int
|
||||
```
|
||||
|
||||
Upload it to scan.coverity.com
|
||||
@@ -0,0 +1,98 @@
|
||||
# Kali Installation
|
||||
Kali users usually must kill their modem manager in order for the proxmark3 to enumerate properly.
|
||||
```sh
|
||||
sudo apt remove modemmanager
|
||||
```
|
||||
|
||||
# Video Installation guide
|
||||
[](https://youtu.be/t5eBPS6lV3E "Kali Linux Installation Tutorial")
|
||||
|
||||
|
||||
---
|
||||
## Manual Install
|
||||
First what we want to do is get an update for the system. If you need to upgrade do this **before** the install
|
||||
An upgrade was carried out prior to following these instructions.
|
||||
|
||||
### Update
|
||||
```sh
|
||||
sudo apt-get update
|
||||
```
|
||||
### Requirements.
|
||||
|
||||
```sh
|
||||
sudo apt-get install p7zip git build-essential libreadline5 libreadline-dev \
|
||||
libusb-0.1-4 libusb-dev libqt4-dev perl pkg-config wget libncurses5-dev gcc-arm-none-eabi
|
||||
```
|
||||
If you do get any issues during the requirements installation, I have found it to help using the synaptic package manager.
|
||||
|
||||
### Clone Fork
|
||||
```sh
|
||||
git clone https://github.com/RfidResearchGroup/proxmark3.git
|
||||
```
|
||||
|
||||
### Change directory into the directory created
|
||||
```sh
|
||||
cd proxmark3
|
||||
```
|
||||
|
||||
### Get the latest commits
|
||||
```sh
|
||||
git pull
|
||||
```
|
||||
|
||||
### Remove Modem Manager
|
||||
```sh
|
||||
sudo apt remove modemmanager
|
||||
```
|
||||
### Reboot Kali
|
||||
```sh
|
||||
reboot
|
||||
```
|
||||
|
||||
### Change directory back to proxmark3
|
||||
```sh
|
||||
cd proxmark3
|
||||
```
|
||||
|
||||
### Clean and Compile
|
||||
Clean and complete compile
|
||||
|
||||
```sh
|
||||
make clean && make all
|
||||
```
|
||||
### Check Connection
|
||||
Once this is complete run the following comands to make sure the proxmark is being picked up by your computer.
|
||||
|
||||
```sh
|
||||
sudo dmesg | grep -i usb
|
||||
```
|
||||
It should show up as a CDC device:
|
||||
```sh
|
||||
[10416.555108] usb 2-1.2: Product: PM3
|
||||
[10416.555111] usb 2-1.2: Manufacturer: proxmark.org
|
||||
[10416.555871] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
|
||||
```
|
||||
|
||||
### Flash the BOOTROM & FULLIMAGE
|
||||
```sh
|
||||
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
|
||||
```
|
||||
> **Note** If you have any issues connecting or during the flash, follow the steps listed [here](https://github.com/RfidResearchGroup/proxmark3/issues/35) and use the command sudo apt remove modemmanager
|
||||
|
||||
|
||||
### Change into the client folder
|
||||
|
||||
```sh
|
||||
cd client
|
||||
```
|
||||
|
||||
### Run the client
|
||||
```sh
|
||||
./proxmark3 /dev/ttyACM0
|
||||
```
|
||||
|
||||
### Run a test command
|
||||
```sh
|
||||
hw tune
|
||||
```
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
## Homebrew (Mac OS X)
|
||||
These instructions comes from @Chrisfu, where I got the proxmark3.rb scriptfile from.
|
||||
Further questions about Mac & Homebrew, contact @Chrisfu (https://github.com/chrisfu/)
|
||||
|
||||
1. Install homebrew if you haven't yet already done so: http://brew.sh/
|
||||
|
||||
2. Tap this repo: `brew tap RfidResearchGroup/proxmark3`
|
||||
|
||||
3. Install Proxmark3: `brew install proxmark3` for stable release or `brew install --HEAD proxmark3` for latest non-stable from GitHub.
|
||||
|
||||
Upgrading HomeBrew tap formula
|
||||
-----------------------------
|
||||
*This method is useful for those looking to run bleeding-edge versions of iceman's client. Keep this in mind when attempting to update your HomeBrew tap formula as this procedure could easily cause a build to break if an update is unstable on macOS.*
|
||||
|
||||
Tested on macOS High Sierra 10.13.2
|
||||
|
||||
*Note: This assumes you have already installed iceman's fork from HomeBrew as mentioned above*
|
||||
|
||||
1. Force HomeBrew to pull the latest source from github
|
||||
`brew upgrade --fetch-HEAD RfidResearchGroup/proxmark3`
|
||||
|
||||
2. Flash the bootloader & fullimage.elf
|
||||
* With your Proxmark3 unplugged from your machine, press and hold the button on your Proxmark 3 as you plug it into a USB port. Continue to hold the button until after this step is complete and the `proxmark3-flasher` command outputs "Have a nice day!"*
|
||||
`$ sudo proxmark3-flasher /dev/tty.usbmodem881 -b /usr/local/Cellar/proxmark3/HEAD-6a710ef/share/firmware/bootrom.elf /usr/local/Cellar/proxmark3/HEAD-6a710ef/share/firmware/fullimage.elf`
|
||||
|
||||
|
||||
`$ sudo proxmark3-flasher /dev/tty.usbmodem881 `
|
||||
|
||||
4. Enjoy the update
|
||||
@@ -0,0 +1,98 @@
|
||||
|
||||
# Parrot OS Installation
|
||||
|
||||
## Notes
|
||||
|
||||
Some further notes can be found at @5w0rdfish repo [Proxmark Installation for Parrot OS](https://github.com/5w0rdfish/Proxmark3-RDV4-ParrotOS)
|
||||
|
||||
# Video Installation guide
|
||||
[](https://youtu.be/Wl9AsrU4igo "ParrotOS Installation Tutorial")
|
||||
|
||||
|
||||
---
|
||||
## Manual Install
|
||||
First what we want to do is get an update for the system. If you need to upgrade do this **before** the install
|
||||
|
||||
### Update
|
||||
```sh
|
||||
sudo apt-get update
|
||||
```
|
||||
### Requirements.
|
||||
|
||||
```sh
|
||||
sudo apt-get install p7zip git build-essential libreadline5 libreadline-dev \
|
||||
libusb-0.1-4 libusb-dev libqt4-dev perl pkg-config wget libncurses5-dev gcc-arm-none-eabi
|
||||
```
|
||||
If you do get any issues during the requirements installation, I have found it to help using the synaptic package manager.
|
||||
|
||||
### Clone Fork
|
||||
```sh
|
||||
git clone https://github.com/RfidResearchGroup/proxmark3.git
|
||||
```
|
||||
|
||||
### Change directory into the directory created
|
||||
```sh
|
||||
cd proxmark3
|
||||
```
|
||||
|
||||
### Get the latest commits
|
||||
```sh
|
||||
git pull
|
||||
```
|
||||
|
||||
### Make Udev
|
||||
Iceman has made the udev script which takes care of the blacklist rules. This should take care of the remove modem manager.
|
||||
The make udev command also create's an alias for the pm3 under /dev which you will use to connect to the proxmark.
|
||||
|
||||
```sh
|
||||
sudo make udev
|
||||
```
|
||||
|
||||
> **Note** If you have any issues connecting or during the flash, follow the steps listed [here](https://github.com/RfidResearchGroup/proxmark3/issues/35) and use the command sudo apt remove modemmanager
|
||||
|
||||
Log out and log back in again. And now we are all set to take the next step.
|
||||
|
||||
### Clean and Compile
|
||||
Clean and complete compilation *within the proxmark3 folder*
|
||||
|
||||
```sh
|
||||
make clean && make all
|
||||
```
|
||||
### Check Connection
|
||||
Once this is complete run the following comands to make sure the proxmark is being picked up by your computer.
|
||||
|
||||
```sh
|
||||
sudo dmesg | grep -i usb
|
||||
```
|
||||
It should show up as a CDC device:
|
||||
```sh
|
||||
[10416.555108] usb 2-1.2: Product: PM3
|
||||
[10416.555111] usb 2-1.2: Manufacturer: proxmark.org
|
||||
[10416.555871] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
|
||||
```
|
||||
|
||||
### Flash the BOOTROM & FULLIMAGE
|
||||
```sh
|
||||
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
|
||||
```
|
||||
### Change into the client folder
|
||||
|
||||
```sh
|
||||
cd client
|
||||
```
|
||||
### Run the client
|
||||
``` sh
|
||||
./proxmark3 /dev/pm #press tab on the keyboard for it to detect the proxmark
|
||||
```
|
||||
or
|
||||
|
||||
### Run the client
|
||||
```sh
|
||||
./proxmark3 /dev/ttyACM0
|
||||
```
|
||||
|
||||
### Run a test command
|
||||
```sh
|
||||
hw tune
|
||||
```
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
# Setup and build for UBUNTU
|
||||
## Notes
|
||||
GC made updates to allow this to build easily on Ubuntu 14.04.2 LTS, 15.10 or 16.04
|
||||
See the [Proxmark3 Ubuntu wiki page](https://github.com/Proxmark/proxmark3/wiki/Ubuntu%20Linux)
|
||||
|
||||
A nice and cool install script made by @daveio is found here:
|
||||
https://github.com/daveio/attacksurface/blob/master/proxmark3/pm3-setup.sh
|
||||
|
||||
Iceman has also added this script to the fork.
|
||||
https://github.com/RfidResearchGroup/proxmark3/blob/master/install.sh
|
||||
|
||||
# Video Installation guide
|
||||
[](https://youtu.be/DThmkH8CdMo "Ubuntu Installation Tutorial")
|
||||
|
||||
---
|
||||
## Manual Installation
|
||||
### Update
|
||||
|
||||
```sh
|
||||
sudo apt-get update
|
||||
```
|
||||
### Requirements
|
||||
|
||||
```sh
|
||||
sudo apt-get install p7zip git build-essential libreadline5 libreadline-dev libusb-0.1-4 libusb-dev libqt4-dev perl pkg-config wget libncurses5-dev gcc-arm-none-eabi
|
||||
```
|
||||
|
||||
### Clone Fork
|
||||
|
||||
```sh
|
||||
git clone https://github.com/RfidResearchGroup/proxmark3.git
|
||||
```
|
||||
### Change Directory
|
||||
|
||||
```sh
|
||||
cd proxmark3
|
||||
```
|
||||
|
||||
### Get the latest commits
|
||||
|
||||
```sh
|
||||
git pull
|
||||
```
|
||||
|
||||
### Install the blacklist rules and add user to dialout group.
|
||||
|
||||
```sh
|
||||
sudo make udev
|
||||
```
|
||||
|
||||
### Restart
|
||||
Restart Ubuntu
|
||||
|
||||
### Enter proxmark folder
|
||||
```sh
|
||||
cd proxmark3
|
||||
```
|
||||
### Clean and Compile
|
||||
```sh
|
||||
make clean && make all
|
||||
```
|
||||
### Check Connection
|
||||
Once this is complete run the following comands to make sure the proxmark is being picked up by your computer.
|
||||
|
||||
```sh
|
||||
sudo dmesg | grep -i usb
|
||||
```
|
||||
|
||||
### Flash the BOOTROM & FULLIMAGE
|
||||
```sh
|
||||
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
|
||||
```
|
||||
|
||||
### Issues
|
||||
If you have issues with the install please try the following below or head on over to the proxmark forum.
|
||||
#### Remove Modem Manager
|
||||
|
||||
```sh
|
||||
sudo apt remove modemmanager
|
||||
```
|
||||
and then restart ubuntu.
|
||||
|
||||
### Change into the client folder
|
||||
```sh
|
||||
cd client
|
||||
```
|
||||
|
||||
### Run the client
|
||||
``` sh
|
||||
./proxmark3 /dev/pm #press tab on the keyboard for it to detect the proxmark
|
||||
```
|
||||
or
|
||||
|
||||
### Run the client
|
||||
```sh
|
||||
./proxmark3 /dev/ttyACM0
|
||||
```
|
||||
|
||||
### Run a test command
|
||||
```sh
|
||||
hw tune
|
||||
```
|
||||
@@ -0,0 +1,83 @@
|
||||
# Building on Windows
|
||||
You will need to use the Gator96100 Proxspace package to assist in your windows installation.
|
||||
This can be downloaded from https://github.com/Gator96100/ProxSpace/
|
||||
|
||||
## Notes
|
||||
If you receive gcc errors using v3.1 during build, download and use v2.2. This may help resolve the issue.
|
||||
|
||||
- https://github.com/Gator96100/ProxSpace/releases/tag/v3.1 (release v3.1 with gcc v7.3.0 )
|
||||
- https://github.com/Gator96100/ProxSpace/releases/tag/v2.2 (release v2.2 with gcc v5.3.0 arm-none-eabi-gcc v7.1.0)
|
||||
|
||||
---
|
||||
# Video Installation guide
|
||||
[](https://youtu.be/zzF0NCMJnYU "Windows Installation Tutorial")
|
||||
|
||||
## Manual Installation
|
||||
|
||||
### Driver Installation
|
||||
|
||||
Install required drivers for your windows installation. You will may need admin privileges to do this.
|
||||
(This is covered in the video) Step by step guides are online such as [RiscCorps](https://store.ryscc.com/blogs/news/how-to-install-a-proxmark3-driver-on-windows-10)
|
||||
|
||||
### Install Github
|
||||
|
||||
Install Github for Windows https://desktop.github.com/
|
||||
|
||||
### Download / clone Proxspace repo
|
||||
|
||||
Download the required proxspace repo. https://github.com/Gator96100/ProxSpace/
|
||||
|
||||
Extract 'ProxSpace' to a location on drive without spaces.
|
||||
For example D:\OneDrive\Documents\GitHub is ok whereas C:\My Documents\My Projects\proxspace is not.
|
||||
|
||||
### Clone RFID RESEARCH GROUP files
|
||||
|
||||
Clone fork
|
||||
```sh
|
||||
git clone https://github.com/RfidResearchGroup/proxmark3.git
|
||||
```
|
||||
### Copy files to Proxspace
|
||||
|
||||
Copy all the contents from the proxmark3 folder into the proxspace pm3 folder
|
||||
|
||||
### Run the .bat
|
||||
|
||||
Run runme.bat or runme64.bat depending on your Windows architecture.
|
||||
|
||||
Please note you will need to use / as you are using BASH.
|
||||
|
||||
### Make
|
||||
|
||||
CLEAN COMPILE inside the pm3 window.
|
||||
```sh
|
||||
make clean && make all
|
||||
```
|
||||
### Flash the image
|
||||
|
||||
Flash the BOOTROM & FULLIMAGE
|
||||
```sh
|
||||
client/flasher.exe comX -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
|
||||
```
|
||||
|
||||
### Run the client
|
||||
|
||||
Assuming you have Proxmark3 Windows drivers installed you can run the Proxmark software where "X" is the com port number assigned to proxmark3 under Windows.
|
||||
|
||||
Change into the client folder
|
||||
```sh
|
||||
cd client
|
||||
```
|
||||
|
||||
Run the client
|
||||
```sh
|
||||
./proxmark3.exe comX
|
||||
```
|
||||
|
||||
### Test
|
||||
|
||||
Check your firmware revision on the Proxmark III with
|
||||
```sh
|
||||
hw ver
|
||||
```
|
||||
For basic help type help. Or for help on a set of sub commands type the command followed by help. For example hf mf help.
|
||||
Make sure you head over to the use of [proxmark area](https://github.com/5w0rdfish/proxmark3/tree/master/Use_of_Proxmark) to help you get on your way!
|
||||
57
doc/md/Use_of_Proxmark/1_Validation.md
Normal file
57
doc/md/Use_of_Proxmark/1_Validation.md
Normal file
@@ -0,0 +1,57 @@
|
||||
## 1. Validating proxmark client functionality
|
||||
|
||||
If all went well you should get some information about the firmware and memory usage as well as the prompt, something like this.
|
||||
We should be able to answer ..can I connect to my proxmark device? does it respond?
|
||||
|
||||
>[=] UART Setting serial baudrate 460800
|
||||
>
|
||||
>Proxmark3 RFID instrument
|
||||
>
|
||||
> [ CLIENT ]
|
||||
>
|
||||
> client: iceman build for RDV40 with flashmem; smartcard;
|
||||
>
|
||||
> [ ARM ]
|
||||
>
|
||||
> bootrom: iceman/master/4517531c-dirty-unclean 2018-12-13 15:42:24
|
||||
>
|
||||
> os: iceman/master/5a34550a-dirty-unclean 2019-01-07 23:04:07
|
||||
>
|
||||
> [ FPGA ]
|
||||
>
|
||||
> LF image built for 2s30vq100 on 2018/ 9/ 8 at 13:57:51
|
||||
>
|
||||
> HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23
|
||||
>
|
||||
> [ Hardware ]
|
||||
>
|
||||
>--= uC: AT91SAM7S512 Rev B
|
||||
>
|
||||
>--= Embedded Processor: ARM7TDMI
|
||||
>
|
||||
>--= Nonvolatile Program Memory Size: 512K bytes, Used: 247065 bytes (47%) Free: 277223 bytes (53%)
|
||||
>
|
||||
>--= Second Nonvolatile Program Memory Size: None
|
||||
>
|
||||
>--= Internal SRAM Size: 64K bytes
|
||||
>
|
||||
>--= Architecture Identifier: AT91SAM7Sxx Series
|
||||
>
|
||||
>--= Nonvolatile Program Memory Type: Embedded Flash Memory
|
||||
>
|
||||
> pm3 -->
|
||||
|
||||
### Run the following commands
|
||||
pm3 --> hw status
|
||||
pm3 --> hw version
|
||||
pm3 --> hw tune
|
||||
|
||||
You are now ready to use your newly upgraded proxmark3 device. Many commands uses the **h** parameter to show a help text. The client uses a arcaic command structure which will be hard to grasp at first. Here are some commands to start off with.
|
||||
|
||||
pm3 --> hf
|
||||
pm3 --> hf 14a info
|
||||
pm3 --> lf
|
||||
pm3 --> lf search
|
||||
|
||||
### Quit client
|
||||
pm3 --> quit
|
||||
38
doc/md/Use_of_Proxmark/2_Configuration-and-Verification.md
Normal file
38
doc/md/Use_of_Proxmark/2_Configuration-and-Verification.md
Normal file
@@ -0,0 +1,38 @@
|
||||
### First things on your RDV40
|
||||
You will need to run these commands to make sure your rdv4 is prepared
|
||||
|
||||
pm3 --> mem load f default_keys m
|
||||
pm3 --> mem load f default_pwd t
|
||||
pm3 --> mem load f default_iclass_keys i
|
||||
pm3 --> lf t55xx deviceconfig a 29 b 17 c 15 d 47 e 15 p
|
||||
|
||||
### Verify sim module firmware version
|
||||
To make sure you got the latest sim module firmware.
|
||||
_Lastest version is v3.11_
|
||||
|
||||
pm3 --> hw status
|
||||
|
||||
Find version in the long output, look for these two lines
|
||||
|
||||
#db# Smart card module (ISO 7816)
|
||||
#db# version.................v2.06
|
||||
|
||||
This version is obselete. The following command upgrades your device sim module firmware.
|
||||
Don't not turn of your device during the execution of this command.
|
||||
|
||||
pm3 --> sc upgrade f ../tools/simmodule/SIM011.BIN
|
||||
|
||||
You get the following output, this is a successful execution.
|
||||
|
||||
[!] WARNING - Smartcard socket firmware upgrade.
|
||||
[!] A dangerous command, do wrong and you will brick the smart card socket
|
||||
[+] Smartcard socket firmware uploading to PM3
|
||||
..
|
||||
[+] Smartcard socket firmware updating, don't turn off your PM3!
|
||||
#db# FW 0000
|
||||
#db# FW 0080
|
||||
#db# FW 0100
|
||||
#db# FW 0180
|
||||
#db# FW 0200
|
||||
#db# FW 0280
|
||||
[+] Smartcard socket firmware upgraded successful
|
||||
21
doc/md/Use_of_Proxmark/3_Commands-and-Features.md
Normal file
21
doc/md/Use_of_Proxmark/3_Commands-and-Features.md
Normal file
@@ -0,0 +1,21 @@
|
||||
|
||||
# Commands and Features
|
||||
|
||||
## New Features in RDV4
|
||||
|
||||
Further details coming soon
|
||||
|
||||
### Run the following commands
|
||||
pm3 --> hw status
|
||||
pm3 --> hw version
|
||||
pm3 --> hw tune
|
||||
|
||||
You are now ready to use your newly upgraded proxmark3 device. Many commands uses the **h** parameter to show a help text. The client uses a arcaic command structure which will be hard to grasp at first. Here are some commands to start off with.
|
||||
|
||||
pm3 --> hf
|
||||
pm3 --> hf 14a info
|
||||
pm3 --> lf
|
||||
pm3 --> lf search
|
||||
|
||||
### Quit client
|
||||
pm3 --> quit
|
||||
@@ -1,276 +1,276 @@
|
||||
|
||||
This is outdated.
|
||||
|
||||
---
|
||||
|
||||
INTRODUCTION TO THE proxmark3
|
||||
=============================
|
||||
|
||||
The proxmark3 device is designed to manipulate RFID tags in a number of
|
||||
different ways. For example, a proxmark3 can:
|
||||
|
||||
* read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,
|
||||
including the ISO-standard tags; standards that require
|
||||
bidirectional communication between the reader and the tag are
|
||||
not a problem
|
||||
|
||||
* emulate a low- or high-frequency tag, in a way very similar to the
|
||||
way that a real tag behaves (e.g., it derives its timing from the
|
||||
incident carrier)
|
||||
|
||||
* eavesdrop on the signals exchanged between another reader and tag
|
||||
|
||||
* measure the resonant frequency of an antenna, to a certain extent
|
||||
(this is a convenience when building a test setup for the previous
|
||||
three functions)
|
||||
|
||||
The proxmark3 may be thought of as a direct-sampling software radio.
|
||||
There is some complication, though, because of the usual dynamic range
|
||||
issue in dealing with signals in RFID systems (large signal due to
|
||||
the reader, small signal due to the tag). Some analog processing is
|
||||
therefore used to fix this before the signal is digitized. (Although,
|
||||
it is possible to digitize the signal from the antenna directly, with
|
||||
appropriate population options. It is just not usually a good idea.)
|
||||
|
||||
SYSTEM ARCHITECTURE
|
||||
===================
|
||||
|
||||
The ANTENNA sends and receives signals over the air. It is external to
|
||||
the board; it connects through SV2. Separate pins on the connector are
|
||||
used for the low- and high-frequency antennas, and the analog receive
|
||||
paths are separate. The antennas are inductive loops, which are resonated
|
||||
by on-board capacitors.
|
||||
|
||||
On the transmit side, the antennas are excited by large numbers of
|
||||
paralleled bus driver buffers. By tri-stating some of the buffers, it
|
||||
is possible to vary the transmit strength. This may be used to generate
|
||||
a modulated carrier. The buffers are driven by signals from the FPGA,
|
||||
as are the output enables. The antennas are excited as series circuits,
|
||||
which permits a large input power for a relatively small input voltage.
|
||||
|
||||
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).
|
||||
|
||||
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. These modes would be
|
||||
very appropriate, for example, for the heavily-discussed attacks in which
|
||||
a tag's ID is learned from the data broadcast by a reader performing an
|
||||
anticollision loop, because there is no dynamic range problem there. It
|
||||
would also be possible to program the proxmark3 to receive broadcast AM
|
||||
radio, with certain changes in component values.
|
||||
|
||||
In either case, an analog signal is digitized by the ADC (IC8), and
|
||||
from there goes in to the FPGA (IC1). 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.
|
||||
|
||||
DETAILS: POWER DISTRIBUTION
|
||||
===========================
|
||||
|
||||
I make a half-hearted attempt to meet the USB power specs; this adds a
|
||||
bit of complexity. I have not made measurements to determine how close
|
||||
I come to succeeding, but I think that the suspend current might turn
|
||||
out to be a pain.
|
||||
|
||||
The +3V3 rail is always powered, whenever we are plugged in to USB. This
|
||||
is generated by an LDO, which burns a quiescent current of 150 uA
|
||||
(typical) already. The only thing powered from the +3V3 rail is the ARM,
|
||||
which can presumably do smart power control when we are in suspend.
|
||||
|
||||
The ARM generates two signals to switch power to the rest of the board:
|
||||
FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to
|
||||
about five volts (the filtered-but-unregulated USB voltage). This powers
|
||||
most of the analog circuitry, including the ADC and all of the opamps
|
||||
and comparators in the receive path, and the coil drivers as well. Vdd
|
||||
also feeds the +3V3-FPGA and +2v5 regulators, which power only the
|
||||
FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered
|
||||
only when NVDD_ON is asserted low, and FPGA_ON is asserted high.
|
||||
|
||||
DETAILS: FPGA
|
||||
=============
|
||||
|
||||
The FPGA is a Spartan-II. This is a little bit old, but it is widely
|
||||
available, inexpensive, and five-volt tolerant. For development, the FPGA
|
||||
is configured over JTAG (SV5). In operation, the FPGA is configured in
|
||||
slave serial mode by the ARM, from a bitstream stored in the ARM's flash.
|
||||
|
||||
Power to the FPGA is managed by regulators IC13 and IC12, both of which
|
||||
have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)
|
||||
supplies. I am a little bit worried about the power-on surge, since we
|
||||
run off USB. At the very minimum, the FPGA should not get power until
|
||||
we have enumerated and requested the full 500 mA available from USB. The
|
||||
large electrolytic capacitors C37 and C38 will presumably help with this.
|
||||
|
||||
The logic is written in Verilog, of course for webpack. I have structured
|
||||
the FPGA in terms of `major modes:' the FPGA's `major mode' determines
|
||||
which of several modules is connected to the FPGA's I/O pins. A separate
|
||||
module is used for each of the FPGA's function; for example, there is
|
||||
now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to
|
||||
an ISO 15693 tag, and receive from an ISO 15693 tag.
|
||||
|
||||
DETAILS: ANALOG RECEIVE PATH
|
||||
============================
|
||||
|
||||
For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,
|
||||
which is more than enough for the low-frequency stuff, and enough for
|
||||
all of the subcarrier frequencies that I know of at high frequency. In
|
||||
practice, the `slow' signals are all the signals following the peak
|
||||
detector. These signals are usually centred around the generated
|
||||
voltage Vmid.
|
||||
|
||||
For `fast' signals, I use an AD8052. This is a very fast voltage-feedback
|
||||
amplifier (~100 MHz GBW). I use it immediately after the antenna for
|
||||
both the low- and high-frequency cases, as a sort of an ugly LNA. It is
|
||||
not optimal, but it certainly made the design easy.
|
||||
|
||||
An ordinary CD4066 is used to multiplex the four possible signals
|
||||
(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential
|
||||
problem at startup, when the ARM is in reset; there are pull-ups on the
|
||||
lines that control the mux, so all of the switches turn on. This shorts
|
||||
the four opamp outputs together through the on-resistance of the switch.
|
||||
All four outputs float to the same DC voltage with no signal, however,
|
||||
and the on-resistance of the switches is fairly large, so I don't think
|
||||
that will be a problem in practice.
|
||||
|
||||
Comparators are used to generate clock signals when the device is
|
||||
emulating a tag. These clock signals are generated from the signal on the
|
||||
antenna, and therefore from the signal transmitted by the reader. This
|
||||
allows us to clock ourselves off the reader, just like a real tag would.
|
||||
These signals go in to the FPGA. There is a potential problem when the
|
||||
FPGA is powered down; these outputs might go high and try to power the
|
||||
FPGA through the protection diodes. My present solution to this is a
|
||||
couple of resistors, which is not very elegeant.
|
||||
|
||||
The high-frequency peak-detected receive path contains population options
|
||||
for many features that I do not currently use. A lot of these are just
|
||||
me guessing that if I provide options for different series and shunt
|
||||
passives, perhaps it will come in handy in some way. The Zener diodes D10
|
||||
and D11 are optional, but may protect the front end from an overvoltage
|
||||
(which will fry the peak detector diodes) when the `simulated tag'
|
||||
is read by a powerful reader.
|
||||
|
||||
DETAILS: ANALOG TRANSMIT PATH
|
||||
=============================
|
||||
|
||||
The coil drivers are just ACT244 bus buffers. I parallel eight of them
|
||||
for each antenna (eight for the high-frequency antenna, eight for the
|
||||
low-frequency antenna). This should easily provide a hundred milliamps
|
||||
coil drive or so, which is more than enough for anything that I imagine
|
||||
doing with the device. The drivers hit the coil with a square wave
|
||||
voltage, however, which means that it is only the bandpass filter effect
|
||||
of a resonant antenna that suppresses the odd harmonics. In practice it
|
||||
would probably take heroic efforts (high antenna Q) to meet the FCC/CE
|
||||
harmonic specs; and in practice no one cares.
|
||||
|
||||
The tx strength, given good antenna tuning, is determined by the series
|
||||
resistors. Choose the ratios to stay within the rated current of the
|
||||
buffers, and to achieve the desired power ratios by enabling or disabling
|
||||
nOEs for the desired modulation index. It is useful to populate one of the
|
||||
resistors as a high value (~10k) for the simulated tag modes; this allows
|
||||
us to look at the incident carrier without loading the reader very much.
|
||||
|
||||
DETAILS: ARM
|
||||
============
|
||||
|
||||
Atmel makes a number of pin-compatible ARMs, with slightly different
|
||||
peripherals, and different amounts of flash and RAM. It is necessary
|
||||
to choose a device with enough flash not just for the ARM's program,
|
||||
but also for the FPGA image (which is loaded by the ARM).
|
||||
|
||||
The ARM is responsible for programming the FPGA. It also supplies a
|
||||
clock to the FPGA (although the FPGA clock can also run off the 13.56
|
||||
MHz clock not used for anything else, which is obviously asynchronous
|
||||
to anything in the ARM).
|
||||
|
||||
It is necessary to use JTAG to bring the ARM for the first time; at
|
||||
that point you can load a bootrom, and subsequently load new software
|
||||
over USB. It might be possible to use the ARM's pre-loaded bootloader
|
||||
(see datasheet) instead of JTAG, but I wanted the JTAG anyways for
|
||||
debugging, so I did not bother. I used a Wiggler clone, with Macraigor's
|
||||
OCD Commander. More expensive tools would work as well.
|
||||
|
||||
USB SOFTWARE
|
||||
============
|
||||
|
||||
At present I enumerate as an HID device. This saves me writing a driver,
|
||||
but it forces me to do interrupt transfers for everything. This limits
|
||||
speed and is not very elegant. A real USB driver would be nice, maybe
|
||||
even one that could do stuff like going isochronous to stream samples
|
||||
from the A/D for processing on the PC.
|
||||
|
||||
PRETENDING TO BE A TAG
|
||||
======================
|
||||
|
||||
It is not possible, with the given topology, to open-circuit the antenna
|
||||
entirely and still look at the signal received on it. The simulated tag
|
||||
modes must therefore switch between slight loading and heavy loading,
|
||||
not open- and short-circuts across the antenna, evening though they do
|
||||
not depend upon the incident carrier for power (just timing information).
|
||||
|
||||
RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS
|
||||
===========================================
|
||||
|
||||
There is a path straight from the antenna to the A/D, bypassing the peak
|
||||
detector assembly. This goes through a gain stage (just a fast voltage
|
||||
feedback opamp), and from there straight in to the mux.
|
||||
|
||||
It is necessary to energize the relay to connect these paths. If the
|
||||
coil is driven (as if to excite and read a tag) while these paths are
|
||||
connected, then damage will probably result. Most likely the opamp
|
||||
will fry.
|
||||
|
||||
READING A TAG
|
||||
=============
|
||||
|
||||
The tag is excited by a carrier transmitted by the reader. This is
|
||||
generated by IC9 and IC10, using some combination of buffers. The transmit
|
||||
power is determined by selecting the right combination of PWR_OEx pins;
|
||||
drive more of them low for more power. This can be used to modulate the
|
||||
transmitted signal, and thus send information to the tag.
|
||||
|
||||
The received signal from the antenna is first peak-detected, and then
|
||||
high-pass filtered to reject the unmodulated carrier. The signal is
|
||||
amplified a bit, and goes in to the A/D mux from there. The A/D is
|
||||
controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything
|
||||
synchronous to the 13.56 MHz carrier.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
This is outdated.
|
||||
|
||||
---
|
||||
|
||||
INTRODUCTION TO THE proxmark3
|
||||
=============================
|
||||
|
||||
The proxmark3 device is designed to manipulate RFID tags in a number of
|
||||
different ways. For example, a proxmark3 can:
|
||||
|
||||
* read a low-frequency (~100 kHz) or high-frequency (13.56 MHz) tag,
|
||||
including the ISO-standard tags; standards that require
|
||||
bidirectional communication between the reader and the tag are
|
||||
not a problem
|
||||
|
||||
* emulate a low- or high-frequency tag, in a way very similar to the
|
||||
way that a real tag behaves (e.g., it derives its timing from the
|
||||
incident carrier)
|
||||
|
||||
* eavesdrop on the signals exchanged between another reader and tag
|
||||
|
||||
* measure the resonant frequency of an antenna, to a certain extent
|
||||
(this is a convenience when building a test setup for the previous
|
||||
three functions)
|
||||
|
||||
The proxmark3 may be thought of as a direct-sampling software radio.
|
||||
There is some complication, though, because of the usual dynamic range
|
||||
issue in dealing with signals in RFID systems (large signal due to
|
||||
the reader, small signal due to the tag). Some analog processing is
|
||||
therefore used to fix this before the signal is digitized. (Although,
|
||||
it is possible to digitize the signal from the antenna directly, with
|
||||
appropriate population options. It is just not usually a good idea.)
|
||||
|
||||
SYSTEM ARCHITECTURE
|
||||
===================
|
||||
|
||||
The ANTENNA sends and receives signals over the air. It is external to
|
||||
the board; it connects through SV2. Separate pins on the connector are
|
||||
used for the low- and high-frequency antennas, and the analog receive
|
||||
paths are separate. The antennas are inductive loops, which are resonated
|
||||
by on-board capacitors.
|
||||
|
||||
On the transmit side, the antennas are excited by large numbers of
|
||||
paralleled bus driver buffers. By tri-stating some of the buffers, it
|
||||
is possible to vary the transmit strength. This may be used to generate
|
||||
a modulated carrier. The buffers are driven by signals from the FPGA,
|
||||
as are the output enables. The antennas are excited as series circuits,
|
||||
which permits a large input power for a relatively small input voltage.
|
||||
|
||||
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).
|
||||
|
||||
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. These modes would be
|
||||
very appropriate, for example, for the heavily-discussed attacks in which
|
||||
a tag's ID is learned from the data broadcast by a reader performing an
|
||||
anticollision loop, because there is no dynamic range problem there. It
|
||||
would also be possible to program the proxmark3 to receive broadcast AM
|
||||
radio, with certain changes in component values.
|
||||
|
||||
In either case, an analog signal is digitized by the ADC (IC8), and
|
||||
from there goes in to the FPGA (IC1). 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.
|
||||
|
||||
DETAILS: POWER DISTRIBUTION
|
||||
===========================
|
||||
|
||||
I make a half-hearted attempt to meet the USB power specs; this adds a
|
||||
bit of complexity. I have not made measurements to determine how close
|
||||
I come to succeeding, but I think that the suspend current might turn
|
||||
out to be a pain.
|
||||
|
||||
The +3V3 rail is always powered, whenever we are plugged in to USB. This
|
||||
is generated by an LDO, which burns a quiescent current of 150 uA
|
||||
(typical) already. The only thing powered from the +3V3 rail is the ARM,
|
||||
which can presumably do smart power control when we are in suspend.
|
||||
|
||||
The ARM generates two signals to switch power to the rest of the board:
|
||||
FPGA_ON, and NVDD_ON. When NVDD_ON goes low, the Vdd rail comes up to
|
||||
about five volts (the filtered-but-unregulated USB voltage). This powers
|
||||
most of the analog circuitry, including the ADC and all of the opamps
|
||||
and comparators in the receive path, and the coil drivers as well. Vdd
|
||||
also feeds the +3V3-FPGA and +2v5 regulators, which power only the
|
||||
FPGA. These regulators are enabled by FPGA_ON, so the FPGA is powered
|
||||
only when NVDD_ON is asserted low, and FPGA_ON is asserted high.
|
||||
|
||||
DETAILS: FPGA
|
||||
=============
|
||||
|
||||
The FPGA is a Spartan-II. This is a little bit old, but it is widely
|
||||
available, inexpensive, and five-volt tolerant. For development, the FPGA
|
||||
is configured over JTAG (SV5). In operation, the FPGA is configured in
|
||||
slave serial mode by the ARM, from a bitstream stored in the ARM's flash.
|
||||
|
||||
Power to the FPGA is managed by regulators IC13 and IC12, both of which
|
||||
have shutdown. These generate the FPGA's VCCO (+3v3) and VCCINT (+2v5)
|
||||
supplies. I am a little bit worried about the power-on surge, since we
|
||||
run off USB. At the very minimum, the FPGA should not get power until
|
||||
we have enumerated and requested the full 500 mA available from USB. The
|
||||
large electrolytic capacitors C37 and C38 will presumably help with this.
|
||||
|
||||
The logic is written in Verilog, of course for webpack. I have structured
|
||||
the FPGA in terms of `major modes:' the FPGA's `major mode' determines
|
||||
which of several modules is connected to the FPGA's I/O pins. A separate
|
||||
module is used for each of the FPGA's function; for example, there is
|
||||
now a module to read a 125 kHz tag, simulate a 125 kHz tag, transmit to
|
||||
an ISO 15693 tag, and receive from an ISO 15693 tag.
|
||||
|
||||
DETAILS: ANALOG RECEIVE PATH
|
||||
============================
|
||||
|
||||
For `slow' signals, I use an MCP6294 opamp. This has a GBW of 10 MHz,
|
||||
which is more than enough for the low-frequency stuff, and enough for
|
||||
all of the subcarrier frequencies that I know of at high frequency. In
|
||||
practice, the `slow' signals are all the signals following the peak
|
||||
detector. These signals are usually centred around the generated
|
||||
voltage Vmid.
|
||||
|
||||
For `fast' signals, I use an AD8052. This is a very fast voltage-feedback
|
||||
amplifier (~100 MHz GBW). I use it immediately after the antenna for
|
||||
both the low- and high-frequency cases, as a sort of an ugly LNA. It is
|
||||
not optimal, but it certainly made the design easy.
|
||||
|
||||
An ordinary CD4066 is used to multiplex the four possible signals
|
||||
(low/high frequency paths, RAW/PEAK-DETECTED). There is a potential
|
||||
problem at startup, when the ARM is in reset; there are pull-ups on the
|
||||
lines that control the mux, so all of the switches turn on. This shorts
|
||||
the four opamp outputs together through the on-resistance of the switch.
|
||||
All four outputs float to the same DC voltage with no signal, however,
|
||||
and the on-resistance of the switches is fairly large, so I don't think
|
||||
that will be a problem in practice.
|
||||
|
||||
Comparators are used to generate clock signals when the device is
|
||||
emulating a tag. These clock signals are generated from the signal on the
|
||||
antenna, and therefore from the signal transmitted by the reader. This
|
||||
allows us to clock ourselves off the reader, just like a real tag would.
|
||||
These signals go in to the FPGA. There is a potential problem when the
|
||||
FPGA is powered down; these outputs might go high and try to power the
|
||||
FPGA through the protection diodes. My present solution to this is a
|
||||
couple of resistors, which is not very elegeant.
|
||||
|
||||
The high-frequency peak-detected receive path contains population options
|
||||
for many features that I do not currently use. A lot of these are just
|
||||
me guessing that if I provide options for different series and shunt
|
||||
passives, perhaps it will come in handy in some way. The Zener diodes D10
|
||||
and D11 are optional, but may protect the front end from an overvoltage
|
||||
(which will fry the peak detector diodes) when the `simulated tag'
|
||||
is read by a powerful reader.
|
||||
|
||||
DETAILS: ANALOG TRANSMIT PATH
|
||||
=============================
|
||||
|
||||
The coil drivers are just ACT244 bus buffers. I parallel eight of them
|
||||
for each antenna (eight for the high-frequency antenna, eight for the
|
||||
low-frequency antenna). This should easily provide a hundred milliamps
|
||||
coil drive or so, which is more than enough for anything that I imagine
|
||||
doing with the device. The drivers hit the coil with a square wave
|
||||
voltage, however, which means that it is only the bandpass filter effect
|
||||
of a resonant antenna that suppresses the odd harmonics. In practice it
|
||||
would probably take heroic efforts (high antenna Q) to meet the FCC/CE
|
||||
harmonic specs; and in practice no one cares.
|
||||
|
||||
The tx strength, given good antenna tuning, is determined by the series
|
||||
resistors. Choose the ratios to stay within the rated current of the
|
||||
buffers, and to achieve the desired power ratios by enabling or disabling
|
||||
nOEs for the desired modulation index. It is useful to populate one of the
|
||||
resistors as a high value (~10k) for the simulated tag modes; this allows
|
||||
us to look at the incident carrier without loading the reader very much.
|
||||
|
||||
DETAILS: ARM
|
||||
============
|
||||
|
||||
Atmel makes a number of pin-compatible ARMs, with slightly different
|
||||
peripherals, and different amounts of flash and RAM. It is necessary
|
||||
to choose a device with enough flash not just for the ARM's program,
|
||||
but also for the FPGA image (which is loaded by the ARM).
|
||||
|
||||
The ARM is responsible for programming the FPGA. It also supplies a
|
||||
clock to the FPGA (although the FPGA clock can also run off the 13.56
|
||||
MHz clock not used for anything else, which is obviously asynchronous
|
||||
to anything in the ARM).
|
||||
|
||||
It is necessary to use JTAG to bring the ARM for the first time; at
|
||||
that point you can load a bootrom, and subsequently load new software
|
||||
over USB. It might be possible to use the ARM's pre-loaded bootloader
|
||||
(see datasheet) instead of JTAG, but I wanted the JTAG anyways for
|
||||
debugging, so I did not bother. I used a Wiggler clone, with Macraigor's
|
||||
OCD Commander. More expensive tools would work as well.
|
||||
|
||||
USB SOFTWARE
|
||||
============
|
||||
|
||||
At present I enumerate as an HID device. This saves me writing a driver,
|
||||
but it forces me to do interrupt transfers for everything. This limits
|
||||
speed and is not very elegant. A real USB driver would be nice, maybe
|
||||
even one that could do stuff like going isochronous to stream samples
|
||||
from the A/D for processing on the PC.
|
||||
|
||||
PRETENDING TO BE A TAG
|
||||
======================
|
||||
|
||||
It is not possible, with the given topology, to open-circuit the antenna
|
||||
entirely and still look at the signal received on it. The simulated tag
|
||||
modes must therefore switch between slight loading and heavy loading,
|
||||
not open- and short-circuts across the antenna, evening though they do
|
||||
not depend upon the incident carrier for power (just timing information).
|
||||
|
||||
RECEIVING SIGNAL STRAIGHT FROM THE ANTENNAS
|
||||
===========================================
|
||||
|
||||
There is a path straight from the antenna to the A/D, bypassing the peak
|
||||
detector assembly. This goes through a gain stage (just a fast voltage
|
||||
feedback opamp), and from there straight in to the mux.
|
||||
|
||||
It is necessary to energize the relay to connect these paths. If the
|
||||
coil is driven (as if to excite and read a tag) while these paths are
|
||||
connected, then damage will probably result. Most likely the opamp
|
||||
will fry.
|
||||
|
||||
READING A TAG
|
||||
=============
|
||||
|
||||
The tag is excited by a carrier transmitted by the reader. This is
|
||||
generated by IC9 and IC10, using some combination of buffers. The transmit
|
||||
power is determined by selecting the right combination of PWR_OEx pins;
|
||||
drive more of them low for more power. This can be used to modulate the
|
||||
transmitted signal, and thus send information to the tag.
|
||||
|
||||
The received signal from the antenna is first peak-detected, and then
|
||||
high-pass filtered to reject the unmodulated carrier. The signal is
|
||||
amplified a bit, and goes in to the A/D mux from there. The A/D is
|
||||
controlled by the FPGA. For 13.56 MHz tags, it is easiest to do everything
|
||||
synchronous to the 13.56 MHz carrier.
|
||||
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user