The Tick

The Tick is the next evolution in covert access control system implants. Designed for a seamless integration behind card readers, The Tick silently intercepts, logs, and replays access credentials with greater efficiency and stealth than ever before. Compatible with a wide range of RFID systems, provides invaluable (to red teamers) insights into facility (in)security, while enabling advanced credential injection. Whether for security auditing, red teaming, or mobile access control testing, The Tick delivers a compact, powerful, and flexible solution in an ever-connected world.

Comparison to other projects

| | BLEKey | ESP-RFID-Tool | ESPKey | The Tick | | -- | -- | -- | -- | -- | | supported protocols | Wiegand | Wiegand | Wiegand | Wiegand + Magstripe Clock&Data + a bit of OSDP | | wireless interfaces | BLE | WiFi | WiFi | BLE + WiFi | | configurable D0/D1 lines | ❌ | ❌ | ❌ | ✅ | | max power supply voltage | battery powered | 🔥 | 18V DC | 25V DC | | max data line voltage | 5V | 5V | 5V | 16V | | SoC | nRF51822 | ESP8266 | ESP8266 | ESP32C3 | | firmware | properly structured code | time-efficient code soup | time-efficient code soup | slightly-organized code soup | | arachnophobia-safe | ✅ | ✅ | ✅ | ❓ (partially, hidden mugga-mode) |

Hardware revisions

The device is in ongoing development - its design, made using KiCad EDA, is getting gradualy optimized and adjusted to incoming feedback and challenges experienced by both the maintainers and users.

Due to a differences in pin mapping, a correct versions must be declared in platformio.ini. There're currently 2 major hardware revisions "in the wild":

Revision 0.2

This is the current revision of the device. The rectangular purpler boards with RS485 transceiver in SOIC-8, that are easy to assemble by hand without a solder paste stencil or hot air, using common parts. The connectors footprint has been adapted for larger KYOCERA AVX 9176-000, adequate for common wire gauges. It features additional circuit for automaticly switching power sources, making the device operation more foolproof.

This batch of PCBs was generously provided by PCBWay. Thank you Liam for reaching out with sponsorship, kind words about the project and providing nicer tone of the soldermask! From uploading a design to delivering ready-made panelized PCBs into my hands 8000 km away was about 5 days, with a weekend included. You can contact me to receive one free of charge, or order them directly through PCBWay Community sharing platform.

release files

Revision 0.1

Initial and currently most common hardware release. The square purple boards with (hard for hand soldering) RS485 transceiver in QFN16. It does not yet feature a dedicated I2C connector and may have KYOCERA AVX 9175-000 series connectors installed, that are too small for regular PACS wiring. I'd advise a small feature backport - populating a JP2 solder jumper on the bottom side of the PCB with a Schottky diode will allow powering the reader from USB.

This is the revision @jzdunczyk used in her Behind Closed Doors - Bypassing RFID Readers34 talk on Black Hat Asia 2025.

release files

Revision 0.0

An ESP32C3, random level converter, RS485 transceiver and a bunch of wires is a good start and fully sufficient platform for testing the software features.

Software

Firmware of this device started as a simple port of ESPKey for ESP32C3, that gradually grew into extensible and multi-protocol software project, with own improved hardware.

Features

Currently, the firmware can be built with following features:

Communication interfaces

| build flag | description | |--------------------|-------------------------------------------------------------------------------| | USE_BLE | BLEKey-style Bluetooth Low Energy support | | USE_WIFI | ESPKey-style WiFi (hotspot or client) support | | USE_HTTP | HTTP user interface |

Firmware upgrade

| build flag | description | |--------------------|-------------------------------------------------------------------------------| | ~~USE_OTA~~ | ~~Arduino-style over-the-air upgrade~~ | | USE_OTA_HTTP | HTTP endpoint for upgrading firmware |

There's an USB connector on-board, that even features embedded JTAG interface, but why not...

External reporting

| build flag | description | |--------------------|---------------------------------------------------------------------------------| | USE_MDNS_RESPONDER | broadcasts MDNS, so hostname instead of IP address can be used for a connection | | USE_SYSLOG | reports interactions to syslog server | | USE_LCD | reports interactions to a handy I2C OLED display |

Wire protocols

| build flag | description | |-------------------------------|---------------------------------------------------------------------| | USE_WIEGAND | provides support for Wiegand interface sniffing and transmitting | | USE_CLOCKANDDATA | provides support for clock&data interface sniffing and transmitting | | USE_OSDP + USE_OSDP_PD | provides support for OSDP Peripheral Device mode | | ~~USE_OSDP + USE_OSDP_CP~~ | ~~provides support for OSDP Control Panel mode~~ |

In Wiegand mode,

the device can receive (sniff) and transmit messages of any length.
Assignment of D0 and D1 lines can be corrected in the configuration file after the device installation, if needed.
The device was sucessfuly tested with 5V and 12V PACS systems, that uses different card number lengths.

In Clock&Data mode,

he device can receive and transmit messages of any reasonable length.
Assignment of DATA and CLOCK lines can be corrected in configuration file after the device installation, if needed.
The device was sucessfuly tested with 12V Clock&Data system, running in Magstripe and UNITEK-emulation modes.
Support for Paxton decoding is based on samples provided by en4rab.

In OSDP Peripheral Device mode,

the device enumerates and serves as a simple OSDP PD. Card numbers can be transmitted using HTTP and BLE interfaces for testing purposes.

Build instructions

Open the project in PlatformIO and press "Upload", then "Upload Filesystem Image". The code is Arduino-flavoured, but took too long to compile using Arduino IDE.

HTTP interface

If built with USE_HTTP flag, the device provides a quite-eye candy, simple HTTP interface, based on almost-REST API and built using jQuery and Bootstrap.

Currently, it offers following features:

• review and modification of application configuration files,
• review of sniffed reader interactions,
• replay of acquired credentials,
• sending arbitrary card numbers (raw or encoded in common formats)

BLE interface

If built with USE_BLE flag, the device exposes a custom Bluetooth Low Energy interface:

Currently, it offers following features:

• reading the last sniffed card,
• notifying about new interactions,
• sending arbitrary card number.

Currently, by default, device requires bonding with pre-configured passkey and use of secure connections.

Feature-wise it is simillar to BLEKey by Mark Baseggio and Eric Evenchick, but running on a decade-younger hardware.

By default, functions are exposed in service f498124f-2137-4615-9859-30eb4cecffb5 as characteristic beb5483e-36e1-4688-b7f5-ea07361baaaa. These UUIDs can be modified in the device configuration.

There is planned a Flipper Zero client, that will be publicly released shortly after BLE Central role will be incorporated in its firmware (probably never).

OTA upgrade

By properly configuring the build flags, the firmware can feature OTA-upgrade. BLE may need to be sacrificed to fit two copies of firmware in device flash.

It is possible to use Arduino-style OTA (but I never did) or upload firmware images over HTTP endpoint, depending on the build configuration.

Configuration reset

1. You need to get the timing Just Right™,
2. Start watching new emergency number spot from IT Crowd,
3. When ambulance appears on the screen, connect The Tick to power source (e.g. USB) or press RST button,
4. When each of digits "881 999" appears