Skip to content

NFC RFID

Jump to bottom
JimGat edited this page Jul 30, 2026 · 4 revisions

NFC & RFID Hub

CYM has a permanent NFC / RFID Hub tile on the main menu — no RF-HAT required to enter it. The hub provides access to two NFC/RFID platforms:

Tile Hardware Status
Chameleon Ultra BLE (any nearby device) Available — v2.11.44+
PN532 NFC NM-RF-HAT DIP 3, or standalone breakout on CN1 Available

Chameleon Ultra

Concept: @bkbroiler | Protocol reference: ChameleonUltraGUI by GameTec-live

CYM connects over BLE to pair with a Chameleon Ultra or Chameleon Lite and exposes its full card read/clone/dump/slot-management capability through the CYM touch UI — no phone or laptop required.

Connecting

  1. Open NFC / RFID Hub → Chameleon Ultra from the main menu.
  2. CYM scans for BLE devices advertising the Nordic UART Service (NUS).
  3. Detected Chameleons appear in the scan list with RSSI signal bars. Tap one to connect.
  4. Pairing: If your Chameleon has "BLE pairing" enabled in Device Settings, CYM will negotiate authentication automatically and inject the fixed passkey 123456 (the Chameleon Ultra firmware default). Devices with pairing disabled connect immediately without a PIN.
  5. Connection persists while you navigate between HF Read, LF Read, and Slot Manager — no need to reconnect between screens.

Read LF (125 kHz)

Tap the Read LF tile. Hold an LF card near the Chameleon antenna.

Supported formats:

  • EM4100 / EM410X — 5-byte UID displayed in hex; saved as em_<hex>.rfid
  • HID Prox H10301 — facility code (FC) and card number (CN) parsed from the 16-byte struct and displayed; saved as hid_<FC>_<CN>.rfid

Files are saved to /sdcard/lab/rfid/lf/ in Flipper Zero .rfid format.

Tap Save to open the filename keyboard. The default name is pre-filled with the card identifier. Confirm to write to SD.

Read HF (13.56 MHz)

Tap the Read HF tile. Hold an HF card near the Chameleon antenna.

CYM sends an ISO 14443-A scan command and parses the response:

  • UID (up to 10 bytes)
  • ATQA (2 bytes)
  • SAK (1 byte) — used to identify card type

Card type detection from SAK:

SAK Detected as
0x08, 0x28 MIFARE Classic 1K
0x18, 0x38 MIFARE Classic 4K
0x09 MIFARE Mini
0x00 NTAG / Ultralight
bit 5 set (0x20) ISO 14443-4 (DESFire, etc.)

On card detection, the UID and type are displayed. Three buttons appear:

  • Save — saves a UID-only Flipper .nfc file to /sdcard/lab/rfid/hf/
  • Dump Card — runs a full sector/page read (see below)
  • Scan Again — restarts the HF scan

Dump Card — Full Sector/Page Read

The Dump Card button runs a full data extraction from the detected card using the Chameleon as a reader proxy.

MIFARE Classic 1K

  1. CYM runs a key dictionary attack against each of the 16 sectors:
    • 8 built-in factory/default keys are tried first (fast, no SD access)
    • Additional keys are loaded from /sdcard/lab/rfid/keys/mf_keys.dic if the file exists
    • Both KeyA and KeyB are tried per sector
  2. On a key match, CYM reads all 4 blocks in the sector using MF1_READ_ONE_BLOCK
  3. Status updates in real time: Attacking sector N/16...
  4. When complete: Dumped N/16 sectors - tap Save
  5. Save writes a Flipper-format .nfc with Block N: XX XX ... lines for all 64 blocks

Sectors that no tested key can crack are written as zero-filled blocks in the output file. The dump still saves — partial dumps are useful for cross-referencing with other tools.

NTAG / Ultralight

  1. CYM sends raw ISO 14443-A READ (0x30) commands page by page via HF14A_RAW
  2. Page count is auto-detected from the Capability Container (CC) at page 3:
    • 0x12 (18) → NTAG213 (45 pages)
    • 0x3E (62) → NTAG215 (135 pages)
    • 0x6D (109) → NTAG216 (231 pages)
  3. Status: Reading page N/M...
  4. When complete: Read N pages - tap Save
  5. Save writes a Flipper-format .nfc with Page N: XX XX XX XX lines

Slot Manager

Tap the Slot Manager tile to view all 8 Chameleon slots.

Each row shows:

  • Slot number (1-8)
  • LF tag type (e.g., EM4100, HID H10301, or Empty)
  • HF tag type (e.g., NTAG213, MFC 1K, or Empty)

Actions:

  • Tap a slot → sets it as the active emulation slot
  • Long-press a slot → opens the SD file browser to load a card from SD into that slot (see below)
  • Clear button in the header → clears the active slot

Clone to Slot

After a successful LF card read, tap Clone to Slot to write the read card directly to a Chameleon emulation slot.

  1. A slot picker (1-8) appears
  2. Tap the target slot
  3. CYM executes a 4-step BLE command chain: set active slot → set tag type → write card data → save to Chameleon flash
  4. Status updates through each step; on success the slot list refreshes automatically

Supported formats:

  • EM410X — 5-byte UID written via EM410X_SET_EMU_ID
  • HID Prox H10301 — FC+CN written via HIDPROX_SET_EMU_ID

For HF cards (NTAG/Ultralight), use Dump Card → Save first, then Load from SD.

Load from SD

Long-press any slot row in the Slot Manager to open the SD file browser.

  • LF files (.rfid, shown in green) — EM410X and HID Prox formats parsed automatically
  • HF files (.nfc, shown in blue) — NTAG/Ultralight page data loaded and written to slot via MF0_NTAG_WRITE_EMU_PAGE_DATA
  • MIFARE Classic .nfc files are detected but slot-write is not yet supported (load to slot requires a command number that has not yet been confirmed from firmware source)

After a successful load, the slot list auto-refreshes to show the new content.

Key Dictionary for MIFARE Dump

The mf_keys.dic file at /sdcard/lab/rfid/keys/mf_keys.dic extends the built-in key list used by both Dump Card (Chameleon Ultra) and PN532 Key Test.

Format: one key per line, 12 hex characters, no spaces. Lines starting with # are ignored:

# One key per line, 12 hex characters (no spaces)
# Lines starting with # are ignored
FFFFFFFFFFFF
A0A1A2A3A4A5
D3F7D3F7D3F7
000000000000

CYM seeds this file with 8 factory/default keys on first SD provision. For broader coverage, download one of the community dictionaries maintained by established RFID research projects:

Dictionary Source Download
Proxmark3 MIFARE Classic defaults RfidResearchGroup/proxmark3 mfc_default_keys.dic
Proxmark3 MIFARE Ultralight C RfidResearchGroup/proxmark3 mfulc_default_keys.dic
Proxmark3 MIFARE Plus RfidResearchGroup/proxmark3 mfp_default_keys.dic
Flipper Zero Unleashed MFC dict DarkFlippers/unleashed-firmware mf_classic_dict.nfc
Proxmark3 T5577 passwords RfidResearchGroup/proxmark3 t55xx_default_pwds.dic

These sources are also referenced by ChameleonUltraGUI for its own dictionary download menu.

Format compatibility notes:

  • All Proxmark3 .dic files are plain text, one 12-hex-char key per line — directly compatible with mf_keys.dic.
  • The Flipper Unleashed mf_classic_dict.nfc uses .nfc extension but is actually a plain text key list in the same format (no JSON or Flipper card data). Rename it to mf_keys.dic and place it in /sdcard/lab/rfid/keys/.
  • The T5577 dictionary (t55xx_default_pwds.dic) contains 4-byte LF chip passwords, not 6-byte MIFARE keys. CYM does not currently implement T5577 password cracking — this file is listed for reference if that feature is added.

To use a downloaded dictionary: save it as /sdcard/lab/rfid/keys/mf_keys.dic on the SD card (SD Provision creates the keys/ directory automatically). Both Dump Card and PN532 Key Test load it fresh at the start of each run.

Up to 512 dictionary keys are loaded per run (larger files are capped). Built-in keys are always tried first regardless of the dictionary file.

Why dictionaries work: Most deployed MIFARE Classic access cards in the field still have factory-default sector keys on one or more sectors. The built-in keys crack a significant portion of real-world cards. An extended dictionary adds vendor-specific defaults and known leaked key sets, increasing coverage further before a full nonce-capture attack (mfkey32) would be needed.

SD Card Layout

/sdcard/lab/rfid/
├── lf/               # LF cards (Flipper .rfid — EM410X, HID Prox)
│   └── <name>.rfid
├── hf/               # HF cards (Flipper .nfc — NTAG, MIFARE, Ultralight)
│   └── <name>.nfc
└── keys/             # MIFARE key dictionaries
    └── mf_keys.dic   # Seeded with 8 common defaults; replace with extended dict

PN532 NFC/RFID

Hardware

Two configurations are supported — no RF-HAT required for the standalone path:

NM-RF-HAT (DIP 3 ON)

Standard path. A DIP-switch reminder popup appears before entering the feature screen. The PN532 I2C lines connect via the FPC2 header to GPIO 8 (SCL) and GPIO 9 (SDA).

Range note: The NM-RF-HAT PCB antenna has shorter read range than a dedicated PN532 breakout board. Cards may need to nearly touch the antenna for reliable reads. This is a hardware layout limitation, not a firmware issue.

Standalone PN532 Breakout on CN1

Wire a PN532 breakout board directly to the CN1 header on the NM-CYD-C5:

PN532 pin CN1 / ESP32-C5
SCL GPIO 8
SDA GPIO 9
VCC 3.3 V
GND GND

Set the PN532 to I2C mode using its onboard DIP switch or solder bridges (varies by breakout). When the NM-RF-HAT is not enabled in Settings → Hardware Options, tapping the PN532 tile shows these wiring instructions as a reminder popup. Enable the RF-HAT setting to see the DIP 3 reminder instead.

Hardware specs: PN532 (I2C mode, fixed by PCB resistors). Supports ISO14443A, ISO14443B, ISO18092. Firmware IC=0x32, FW=1.6.

Scan & Read — Card Enumeration

Continuously polls the NFC field for cards. On detection:

  • Identifies card type (NTAG213/215/216, MIFARE Ultralight, MIFARE Classic)
  • Reads the UID
  • For NTAG/Ultralight: reads all pages and decodes any NDEF TLV records (URI, text)
  • Displays raw page data in hex
  • Logs to /sdcard/lab/rfid/cards/

Research use cases

Access control card enumeration
The most common contactless access control cards in use today are MIFARE Classic (13.56 MHz, ISO14443A). CYM reads and logs the UID of every card it sees. UIDs are typically static and used as the sole identifier by access control panels — the critical finding is whether the system validates anything beyond UID presence.

NFC tag content auditing
NTAG213/215/216 tags are ubiquitous: NFC product authentication stickers, marketing tags, asset labels, conference badges. The Scan & Read screen decodes the NDEF payload — revealing the URI or text written to the tag. Common findings: staging URLs still active on production tags, internal URLs exposed on marketing materials, writable tags that should be locked.

Card inventory during physical assessment
Scan every access card and badge presented during a social engineering exercise. Log the UID and card type for each. Compare against the expected card type (many organizations unknowingly use MIFARE Classic when their policy specifies DESFire EV1).

NDEF data extraction
Smart posters and tap-to-pay loyalty cards often store URIs pointing to backend systems. Read the NDEF payload to identify backend URLs, deep links, and app store targets — these sometimes point to staging environments or reveal the app bundle ID.

Field scenario

Physical pen test, day one. The receptionist's desk has a stack of visitor badges in a tray — MIFARE Classic, ISO14443A. You ask to see one "to check if it works with your equipment" during a conversation about the security system. CYM reads the UID in under a second while you're holding it. Badge goes back in the tray. You've got the UID logged. The entire interaction looked like a hardware compatibility check. Nobody saw a scan.

Clone / Write — Credential Duplication

Reads a source NTAG/Ultralight card completely (all pages), then writes the identical page-by-page content to a blank target card of the same type.

Research use cases

Access control vulnerability demonstration
MIFARE Classic (and many Ultralight/NTAG deployments) are vulnerable to UID cloning because the access control panel uses only the UID for authentication. Clone a card UID onto a blank writable tag (e.g., a $0.10 NTAG213) and present it to the reader. If the door opens, you've demonstrated the vulnerability to the client in 60 seconds — no crypto attack required.

Backup and restore for authorized testing
Before writing test data to a production NFC tag, clone it. You have a bit-exact backup to restore from if the test corrupts the tag.

Credential mobility testing
Test whether your organization's NFC credentials are unique to the physical card (anti-clone measures, rolling codes, challenge-response) or are simply a static UID that any blank tag can impersonate.

Field scenario

Thirty minutes after reading the visitor badge UID. You're in your car in the parking lot. You write the captured UID to a blank NTAG213 — a $0.10 sticker tag from a pack of 50. Walk back to the building. Tap your sticker tag to the server room access reader. The door opens. The access control system never looked at anything beyond the UID. MIFARE Classic, deployed correctly, uses sector-level crypto authentication. This deployment didn't. The clone took thirty minutes and cost ten cents.

Card Emulation

Puts the PN532 into NFC-A target mode (TgInitAsTarget), making CYM appear to a reader as an NFC card. Emulates any card from the RFID storage library on the SD card.

What it responds to

  • READ (0x30) — returns page data from the stored card image
  • GET_VERSION (0x60) — returns a static NTAG213 response
  • Unknown commands -- NAK

Limitation: MIFARE Classic authentication (CRYPTO1) is not emulated — the PN532 target mode has no CRYPTO1 engine. Readers that require crypto auth after UID selection will fail. Emulation is most effective against readers that only check UID presence.

Research use cases

Reader validation testing
Present CYM emulating a cloned card UID to the access reader. This determines whether the reader performs only UID check (vulnerable) or requires crypto challenge-response (resistant). You get the answer in one tap.

Physical access control penetration test
During an authorized physical pen test, emulate a cloned credential and attempt to access restricted areas. The test proves or disproves the hypothesis that a cloned card grants access — and captures it in the assessment report.

Reader firmware behavior analysis
Some readers send unusual APDU sequences after UID selection. Running emulation mode while monitoring the PN532 I2C logs (available in ESP-IDF serial output) reveals exactly what commands the reader sends — useful for reverse-engineering proprietary reader protocols.

Field scenario

Same server room reader, but this time you want to know whether CYM itself can get through without the cloned sticker — just by emulating the captured UID directly from the device. You switch to Card Emulation, select the saved badge profile, and tap CYM to the reader. Door opens. You've now demonstrated the vulnerability three ways: scan, clone to blank tag, and live emulation. The client gets all three methods documented, each with a different threat actor profile — opportunistic attacker with a blank tag vs. a researcher with a purpose-built device.

Key Test — Authentication Attempt

Attempts MIFARE Classic authentication against a detected card using a list of known-default and common keys (Key A and Key B for each sector).

Key source (v2.11.46+): PN532 Key Test tries the 16 built-in keys compiled into the firmware (mifare_classic.c), then automatically loads and tries any additional keys from /sdcard/lab/rfid/keys/mf_keys.dic (up to 512 extra keys, same dictionary file used by Chameleon Ultra Dump Card). The dictionary file is optional — Key Test works without it. See Key Dictionary for MIFARE Dump for download links and format notes.

Built-in keys tested (16 total, always tried first): FFFFFFFFFFFF, A0A1A2A3A4A5, B0B1B2B3B4B5, 000000000000, D3F7D3F7D3F7, 4D3A99C351DD, 1A982C7E459A, 714C5C886E97, 587EE5F9350F, A0478CC39091, 533CB6C723F6, 8FD0A4F256E9, 6C78928E1317, AABBCCDDEEFF, 000000000001, 010203040506

Research use cases

Default key detection
Many deployed MIFARE Classic access cards — even in enterprise environments — still have factory-default keys (FF FF FF FF FF FF, A0 A1 A2 A3 A4 A5, etc.) on one or more sectors. Key Test checks all common defaults and highlights which sectors authenticate with default keys, exposing the data in those sectors to anyone with a reader.

Sector mapping for cloning research
Before a full MIFARE Classic clone (which requires knowing the keys for every sector), Key Test identifies which sectors you can access with known keys. Sectors with readable data under default keys may contain cardholder data, facility codes, or access group identifiers.

Credential system audit
Card issuers who claim to use custom keys can be verified — if Key Test cracks any sector with a well-known key, the issuer's key management practices are deficient.

Field scenario

The access control vendor insists their MIFARE Classic deployment uses custom sector keys per facility. Key Test runs through the common default list in under a minute. Sector 0 opens with FF FF FF FF FF FF. Sector 3 opens with A0 A1 A2 A3 A4 A5. The facility code and card number are sitting in sector 1 in plaintext. The vendor's "custom key" claim was true for two of the sixteen sectors. The other fourteen used factory defaults. That's in the report as a vendor misrepresentation finding, not just a configuration gap.

Clone this wiki locally