Bluetooth Hacking?
OpenPICC Development

From OpenPCD

Jump to: navigation, search


OpenPICC RFID sniffer and RFID emulator

This device is obsolete - please use OpenPICC SnifferOnly 13.56MHz instead for sniffing

OpenPICC 1 board

OpenPICC is a sister project of OpenPCD concerned with the creation of an open source and open hardware PICC (Proximity Integrated Circuit Card) emulator. In theory the OpenPICC hardware should be able to emulate most 13.56MHz based passive RFID cards. In practice there are some problems with the first hardware releases that introduce timing jitter which is particularly damaging when trying to send data from the PICC.

There are two main firmware branches for the OpenPICC:

  • The older firmware is based on the same framework as the current OpenPCD firmware, but only supports sniffing, and then only through a host-based tool. For a short howto on using that firmware see OpenPICC RFID Emulator and Sniffer Project
    • Pro: Supports firmware upgrades through DFU
    • Con: Deprecated, no longer actively maintained
  • The newer firmware is based on the same framework as the OpenBeacon USB firmware. It is currently being actively developed and should offer full ISO 14443-A operation some time soon. See below for details.
    • Pro: Simple serial terminal through USB CDC ACM (like OpenBeacon USB); uses FreeRTOS, thus easier to develop for; should be self-contained (e.g. no host application necessary) when development is finished
    • Con: No DFU support, must be flashed and updated with SAM-BA

New OpenPICC firmware

sniffonly branch

Since proper transmit timing is probably impossible with the current hardware release (schematics v0.4) new modifications are currently being drafted and a prototype is tested. In order to enable meaningful use for the old board with the current hardware a sniffonly branch exists that will at least enable PCD-to-PICC sniffing for ISO 14443A by using the timer/counter circuits of the processor to measure the number of carrier cycles between two modulation pauses. Because this measurement is done in software it only has an accuracy of about 7 carrier cycles, but that should be good enough.

Building and downloading

All OpenPICC boards shipped after February 22nd should come with the new firmware preloaded. You can check this by connecting to the serial USB console of the device and then pressing h for help. If you have the sniffer firmware then it should say "OpenPICC-Sniffer USB terminal" in the output. It will also tell you the version of the firmware. All versions starting with 422 should be all right (but 425 adds extra PWM eye candy for the LEDs which you might want to try).

Correction: All sniffonly branch versions prior to version 432 have a bug that will truncate sent buffers at about 235 timing measurements. This will lead to truncated frames after about 35 to 40 received bytes. If you need to sniff PCD frames longer than 30 bytes then please use at least version 432.

If you do have the sniffer firmware in a sufficiently new version installed you don't need to flash new firmware and can skip this step. Otherwise:

Prerequisites: gnu arm toolchain (tested version 4.0.2), sam7 tool installed in /usr/local/bin/sam7, see Firmware#Flashing a complete flash image (using SAM-BA)

svn co http://svn.openpcd.org/branches/sniffonly/openpicc/
cd openpicc
make
./at91flash_automatic openpicc.bin [after flashing you may exit at91flash_automatic with Ctrl-C]

(if at91flash_automatic doesn't work for you, e.g. due to lsusb weirdness, you may try ./at91flash openpicc.bin but might have to edit the at91flash script to point to the correct UART)

Using

In version 422 the red LED shows PLL lock and the green LED will blink *very* faintly when modulation edges are detected. In version 425 the red LED changes brightness proportionally to the received field strength while the green LED will show PLL lock (steady on) and modulation edges (blinking). In version 425 the LEDs will also fade on and off once at boot to indicate correct operation of the board.

The firmware offers a serial USB console that you can connect to and interact with. Use (at your discretion) either

cu -l /dev/ttyACM0 -s 115200

or

screen /dev/ttyACM0 115200

to connect to it. (cu can be aborted with the sequence [Enter]~.[Enter]; in screen you can kill the window with Ctrl-a K (and yes, that's a capital K))

Most (all in this branch) commands are single characters that need only be pressed. Important commands are h for help, c to show some of the current configuration, f to start/stop a field meter (see below), + and - to adjust the comparator threshold (see below) and 9 to reboot the OpenPICC.

You can use the field meter (command f) to tune C1 for the best reception when the board is in a reader field. You can use the commands + and - to change the comparator threshold if you find that the default setting is not good for your environment. You might need an oscilloscope for that though. (The + and - commands change the voltage on Pin 3 of U7 which is compared with the carrier envelope on Pin 2 of U7 to generate the digital data signal SSC_DATA on Pin 7 of U7.) Changes of the threshold are not permanent and will be lost on the next boot. For a permanent change you'll have to edit DA_BASELINE in application/openpicc.h.

In order to start sniffing you'll have to use the r command on the serial USB console. Warning: This command will start printing binary values to the console that are not designed for human consumption (and might seriously upset your terminal). Instead you are supposed to use a host side application for decoding (see below). The reception mode is also stopped by pressing r again. Known caveat: During reception mode the normal output is suspended and buffered. If you press any other key than r (e.g. f for example) the buffer is likely to fill and block all further command executions (including pressing r again).

Binary protocol

The binary protocol that is used in reception mode is very simple and 4 byte based. After sending r the firmware might output some other ASCII information and will then start the protocol with the four bytes '----' and then starts outputting timing measurements. All measurements are transmitted as unsigned integers, 4 bytes, LSByte first. For debugging purposes that OpenPICC also transmits buffer delimiters that are either '____' (four bytes) or '////' (four bytes). These are mainly for debugging purposes and not significant in the PCD-to-PICC protocol. The internal buffers used by the firmware have 1024 entries (two buffers, for double-buffering) and '____' will be used for the buffer delimiter in the normal case. Should the firmware detect that a possible buffer overrun has happened it will use '////' for the buffer delimiter to notify the host application. The host application can also use the buffer delimiter to resynchronize to the four byte boundaries should a byte in the protocol be dropped. (The timer used hat 16 bits, so any value that has one of the upper 16 bits set is likely a communications error.) Note: Under Linux the default setting for serial connections is to use XON/OFF which will drop some specific bytes on the connection and is therefore not suited for binary protocols. The host application is supposed to change that setting.

Sending command r again will turn reception mode off at the next possible opportunity. The firmware will send the four bytes '----' to indicate that it is leaving reception mode.