Chameleon Ultra — Read, Sniff, and Clone Workflow

6.1 The three capture modes — read, detect, and clone

The Chameleon Ultra’s field workflow centers on three distinct interaction modes, each appropriate to a different access condition. Understanding the boundary between them is prerequisite to choosing the correct operational posture.

6.1.1 Direct HF read

In reader mode, the MFRC522 drives the 13.56 MHz carrier field and actively interrogates whatever ISO 14443A card is placed on the HF coil face. The nRF52840 orchestrates the full anticollision, select, and authenticate sequence via the MFRC522 over SPI; the result is a UID, ATQA, and SAK on a clean card, or a full sector-key-authenticated memory dump on a MIFARE Classic card once the key recovery suite has recovered all sector keys. Direct read is the fastest path when the operator has physical access to the target card for five or more seconds and no one is watching. The MFRC522 is what makes this possible on the Ultra; the Lite has no equivalent path (Vol 2 §3.2).

For LF (125 kHz) targets, the MFRC522 plays no role — the nRF52840’s own PWM-and-comparator LF analog path handles the interrogation. The operational workflow is otherwise similar: place the card on the LF coil face, initiate a read, observe the credential data, load into a slot.

6.1.2 Detection mode (the Chameleon Ultra’s “sniff equivalent”)

The Chameleon Ultra is not a passive MITM sniffer in the same sense as the Proxmark3’s hf mf sniff mode. The nRF52840’s NFC-A hardware is a tag interface, not a passive RF monitor; it cannot silently observe two external devices — a reader and a live card — communicating without inserting itself into the exchange.

The Chameleon Ultra’s functional equivalent to sniffing is detection mode: the device emulates a target card (loaded into an active slot with the correct UID and anticollision data), and when a legitimate reader tries to authenticate to it, the firmware logs the cryptographic nonce pairs that the Crypto1 authentication protocol exchanges. Because the reader believes it is talking to the real card, it sends its nonce nT and then its encrypted response (nR, aR) — the exact data MFKey32 v2 needs to recover the sector key offline. Multiple authentication attempts (typically two or more per sector key) are accumulated in the device’s detection log. The operator then retrieves that log and runs the MFKey32 v2 algorithm — either in ChameleonUltraGUI or via the CLI — to recover the sector keys.

This workflow is architecturally different from Proxmark3’s passive MITM sniff (which requires physical interposition between reader and card), but it achieves the same intelligence product — the reader’s sector keys — from a more accessible operational position: presenting the device to the reader like an ordinary credential.

A command hf 14a sniff does exist in the Chameleon Ultra CLI and captures trace data from reader interactions while the CU is acting as a tag, but as of firmware v2.1.0-series it has a documented bug where encrypted block responses are captured incorrectly after authentication (GitHub issue #444, 2024). For key recovery, the detection mode workflow via hf mf econfig --enable-log and hf mf elog is the correct and reliable path.

6.1.3 Clone via slot load (not physical-blank writing)

The Chameleon Ultra’s “clone” operation is slot loading, not physical-blank writing. The device does not write to blank card stock in the field the way the iCopy-X does; it loads a captured dump (UID, ATQA, SAK, and full memory content) into one of its eight HF or eight LF emulation slots, then emulates that credential to a reader. This is the operationally appropriate posture for access-control audits where the goal is testing whether the emulated credential defeats the reader — not leaving a physical clone behind. When a tangible cloned credential on a blank is required, see Vol 7 (slot management and writing to writable blank stock) or the iCopy-X workflow in ../iCopy-X/ Vol 8.

6.2 HF card read workflow — MFRC522, ChameleonUltraGUI, slot load

The HF read workflow uses the MFRC522 to interrogate a target card directly. The MFRC522 must be facing the card; the correct orientation is the HF-coil face of the Ultra (the main PCB side, not the antenna PCB reverse), placed against the face of the target card.

6.2.1 Physical card placement

Hold the Ultra with the HF coil face toward the target card. Optimal coupling distance is 0–3 cm; the MFRC522’s read range for a typical ISO 14443A credential is approximately 3–4 cm in community measurements, but reliable reads are more consistent within 1 cm for thinner credentials and unfamiliar reader geometries. Coupling is sensitive to angle: keep the coil surfaces as parallel as possible. Cards inside a wallet or against a metal surface degrade coupling; remove the card from its holder when possible. The white RF LED on the edge of the device illuminates when the MFRC522 detects an active HF field — if it doesn’t light during a read attempt, the device is not coupling.

6.2.2 Initiating a read in ChameleonUltraGUI

The device must be in reader mode before an HF scan command will interrogate an external card rather than entering the emulation path. ChameleonUltraGUI handles this mode switch transparently when you navigate to the read screen.

GUI workflow (ChameleonUltraGUI):

1. Connect to the Ultra over BLE (Android, iOS, or desktop) or USB-C serial.
2. From the home screen, navigate to the HF/LF Reader section (labeled as the reader module in the navigation, distinct from the Slot Manager).
3. Place the target card against the HF coil face and tap Read HF. The GUI sends the device into reader mode (hw mode -r equivalent) and issues an HF 14A scan.
4. On a successful read, the GUI populates the UID, ATQA, and SAK fields. The card type is identified from the ATQA/SAK combination — for example, ATQA 00 04, SAK 08 identifies a MIFARE Classic 1K; ATQA 00 04, SAK 09 identifies a MIFARE Mini. This identification drives which attack options the GUI presents next.
5. For UID-only targets (§2.3), the read is now complete. For MIFARE Classic, the GUI will offer key recovery options (§2.4).

CLI equivalent:

hw mode -r
hf 14a scan

hf 14a scan returns the UID, ATQA, and SAK of the first responding tag within coupling range (GitHub issue #164; deepwiki.com/RfidResearchGroup/ChameleonUltra). The companion command hf 14a info performs a more detailed analysis pass — it attempts to identify the card type and returns ATS data for cards that support the Answer to Select — and is the appropriate follow-up when hf 14a scan returns an unfamiliar ATQA/SAK combination. Neither command requires a key; they operate only at the ISO 14443A anticollision and select layer.

6.2.3 UID-only vs full-dump reads

A UID-only read captures the four-byte (or seven-byte for cascade-level-2 UIDs) card identifier, the ATQA, and the SAK. This is sufficient for access-control systems that gate on UID alone — the most common configuration in commodity HID access control and many deployed MIFARE Classic installations that have never been re-programmed from factory. A UID-only read takes under a second and does not require any knowledge of sector keys.

A full memory dump captures all 16 sectors of a MIFARE Classic 1K (or 40 sectors of a 4K) including access-condition bytes and the data payload in each block. This is required when the reader performs Crypto1-authenticated reads — i.e., it verifies not just the UID but also that the emulated card can authenticate to the correct sector key and return the correct encrypted data. Most production access-control systems in enterprise and government deployments use crypto-authenticated reads; a UID-only clone will fail them.

Determining which type is needed requires either prior knowledge of the target system or a test: load a UID-only slot and present it. If the reader grants access, UID gating is all that was deployed. If the reader rejects it or hangs, full-dump authentication is required.

6.2.4 Automated key recovery during a read

When the scanned card is identified as MIFARE Classic, ChameleonUltraGUI presents the key recovery options inline with the read result. The GUI integrates the Crypto1 attack suite into the read workflow; the operator does not need to drop to the CLI unless the GUI’s automated sequence fails.

The attack sequence the firmware and GUI implement, in order of application:

1. Known-key probe: Before running any attack, the GUI checks a list of default and commonly deployed sector keys (the MIFARE factory default key FFFFFFFFFFFF, A0A1A2A3A4A5, D3F7D3F7D3F7, and similar) against each sector using hf mf rdbl. If a sector responds to a known key, that key is cached and the sector is marked as recovered. This step costs no attack time and succeeds on misconfigured or factory-default cards outright.

2. DarkSide attack (hf mf darkside): Exploits a PRNG weakness in the original un-hardened Crypto1 silicon to recover at least one sector key without any prior key knowledge. DarkSide is attempted against sector 0 key A; on a vulnerable card it typically recovers the key in seconds. On DarkSide-resistant cards — MIFARE Classic EV1 (hardened PRNG, escalated to HardNested) and Fudan FM11RF08S (static-encrypted-nonce backdoor, escalated to hf mf senested) — the firmware reports failure and the GUI advances to Nested.

3. Nested attack (hf mf nested --blk <known-block> [-a|-b] -k <known-key> --tblk <target-block> [--ta|--tb]): Uses one known sector key as a bootstrap to recover keys for remaining sectors by exploiting the Crypto1 PRNG’s nonce predictability during encrypted authentication handshakes. Once DarkSide (or the known-key probe) has recovered a single sector key, Nested can recover the remaining 15 sector key pairs (A and B) for a 1K card. This is the workhorse of the MIFARE Classic attack suite. The firmware also auto-routes to StaticNested (MF1_STATIC_NESTED_ACQUIRE, added v2.0.0) when the target card’s PRNG seed is fixed at every power cycle — the same nonce appears regardless of authentication timing (RRG CHANGELOG: “Added MF1_STATIC_NESTED_ACQUIRE and its support in hf mf nested”). The firmware detects this condition and switches to the faster 2NT-based recovery path transparently; no separate CLI command is required.

4. FM11RF08S static-encrypted-nonce backdoor (hf mf senested): Targets the Fudan FM11RF08S specifically — a static encrypted nonce construction that defeats DarkSide, Nested, StaticNested, and HardNested alike. The hf mf senested command (added in firmware v2.1.0, 2025-09-02, PR #263; Quarkslab 2024 disclosure, eprint.iacr.org/2024/1275) exploits a universal backdoor key (A396EFA4E24F) embedded in the FM11RF08S silicon. This is a separate firmware code path from the Nested family — not a variant of StaticNested — and is invoked when both DarkSide and Nested fail on FM11RF08S-class cards.

5. HardNested (hf mf hardnested): Targets cards with a hardened PRNG (non-vulnerable to DarkSide, non-vulnerable to Nested) — the primary example being MIFARE Classic EV1. HardNested was fully implemented in the Chameleon Ultra CLI as of firmware v2.1.0 (released 2025-09-02, PR #254 “complete hardnested attack implementation”). The live command syntax is hf mf hardnested --blk <n> -k <key> --tblk <n> .... For time-critical field sessions, the Proxmark3 RDV4’s HardNested implementation may complete the attack faster; recovered keys can be imported back into the CU via the CLI or GUI. This is a speed and convenience tradeoff, not a capability gap.

Once all sector keys are recovered, the GUI displays the complete key map and automatically initiates a full dump read using hf mf rdbl for each block authenticated with its recovered key.

6.2.5 Confirming a complete dump

A complete dump has no “unknown key” residuals. ChameleonUltraGUI displays sector status after the recovery sequence: each sector shows its recovered Key A, Key B, and the read status of all its data blocks. Any sector showing an error or unknown key indicates incomplete recovery — the card has not been fully captured and loading the partial dump into a slot will result in authentication failures for the missing sectors.

Common causes of an incomplete dump: one or more sectors use a non-factory key that the known-key probe didn’t match, the DarkSide attack failed on a hardened-PRNG card (see §8.2), or the card is not a standard MIFARE Classic (check ATQA/SAK — DESFire, NTAG, and Ultralight have similar anticollision behavior but different sector structures and authentication schemes, none of which the MIFARE Classic Crypto1 suite applies to).

6.3 LF card read workflow

LF reads use the nRF52840’s PWM-driven LF analog path, not the MFRC522. The LF antenna is on the secondary PCB (the reverse face of the device). Present the reverse face of the Ultra to the target LF card.

6.3.1 Physical card placement for LF

The LF coil occupies the reverse PCB of the Ultra. When reading a target LF fob or card, orient the reverse face toward the target. LF read range on the Ultra is approximately 2 cm or less for typical HID Prox credentials, based on community measurements on the Dangerous Things forum — shorter than the Proxmark3 RDV4’s 5–10 cm range with its matched LF antenna board. For EM4100 fobs the range is similar. Present the LF target as close to flush with the reverse face as possible; a standoff of even 5 mm significantly drops the coupling efficiency.

The MFRC522’s HF circuitry is not involved in LF reads, so HF and LF read attempts on different card faces can be run independently without cross-interference. However, do not attempt to read a LF card on the HF coil face or vice versa — there is no physical LF carrier on the MFRC522’s antenna drive circuit.

6.3.2 Protocol auto-detection

ChameleonUltraGUI’s reader module attempts to auto-detect the LF protocol when a read is initiated. The firmware tests the signal against the LF protocol families in its stack — EM4100/EM4102 first (the most commonly deployed 125 kHz format), then T5577, then HID Prox, Indala, and the other families listed in Vol 2 §4.2. The CLI equivalent initiates a scan for the most common LF family explicitly:

lf em410x scan

For non-EM4100 cards, the corresponding protocol-specific scan command must be used (e.g., for HID Prox, the relevant lf hid command from the LF command tree). As of current firmware releases, the GUI’s auto-detection reliably identifies EM4100/EM4102 fobs; HID Prox and Indala detection has been added to the firmware (per the RRG CHANGELOG: “Added LF HIDProx read, T5577 write, emulate function”) but the auto-detection coverage across all supported families in the GUI is not comprehensively documented as of 2026-06. If the GUI fails to auto-detect a known LF protocol, select the protocol manually from the GUI’s LF type selector before initiating the scan.

6.3.3 Loading an LF credential into a slot

After a successful LF read, the GUI presents the detected ID and protocol type. To load it into an LF slot:

1. Navigate to Slot Manager in ChameleonUltraGUI.
2. Select the target slot. A slot can hold both an HF card and an LF card simultaneously; selecting a slot for LF configuration does not displace an existing HF configuration in the same slot.
3. Set the slot’s LF card type to match the detected protocol (e.g., EM410x, HID Prox).
4. Configure the slot with the captured LF credential data (the ID value and any protocol-specific parameters). For EM4100, only the 40-bit ID value is needed.

The CLI equivalent for an EM410x credential:

hw slot type -s <slot> -t EM410X
hw slot init -s <slot> -t EM410X
lf em 410x econfig -s <slot> --id <hex-id>
hw slot enable -s <slot> --lf

Substitute the exact hex ID value obtained from lf em410x scan. For other LF families, substitute the appropriate type identifier and configuration command. The exact command names for non-EM family protocols are confirmed in the RRG CLI reference (github.com/RfidResearchGroup/ChameleonUltra/wiki/cli) and expand the pattern above; consult that reference rather than inferring flag names for unfamiliar protocol families.

6.4 Detection mode — logging reader nonces for MFKey32 key recovery

Detection mode is the Chameleon Ultra’s primary tool for recovering MIFARE Classic sector keys from a deployed reader without ever having isolated access to the card itself. The workflow exploits the Crypto1 mutual authentication handshake: during authentication, a reader sends two nonce-derived values — the encrypted reader response nonce nR and the reader authentication value aR — that are computationally sufficient for MFKey32 v2 to recover the sector key offline, given also the card’s nonce nT from the same exchange. The Chameleon Ultra collects these tuples in its detection log during authentication attempts made by the reader against the CU’s emulated card, then exports them for key recovery.

6.4.1 Setting up the target slot for detection mode

Before detection mode is useful, the target slot must be configured with at least the correct UID and anticollision data (ATQA, SAK) so that the target reader will engage the CU in a full Crypto1 authentication exchange — not reject it at the anticollision stage. If the reader grants access based on UID alone, it will not send authentication nonces; detection mode can only capture crypto-authentication events.

The preferred setup sequence:

1. Obtain the target card’s UID, ATQA, and SAK via a direct read (hf 14a scan) if the card is accessible for even a few seconds.
2. Load the anticollision data into the target slot:

hw slot type -s <slot> -t MIFARE_1024
hw slot init -s <slot> -t MIFARE_1024
hf mf econfig -s <slot> --uid <hex-uid> --atqa <hex-atqa> --sak <hex-sak>

3. Optionally, if a partial dump is available (e.g., blocks for sectors where the key is already known), pre-load it with hf mf eload. Sectors with correct data will authenticate successfully; sectors with incorrect or default data will fail authentication but still log nonces. The more sectors authenticate correctly, the more keys can be confirmed or accelerated. Without any dump data, all sectors will use default key material and all authentications will fail, but nonces will still be logged.

4. Enable the detection log:

hf mf econfig --enable-log

5. Switch to emulator mode:

hw mode -e

In ChameleonUltraGUI, step 4 corresponds to enabling Detection Mode (also called “Collect nonces (Mfkey32)”) in the slot settings or the reader interaction settings. The GUI handles the mode switch transparently.

6.4.2 Collecting nonces — presenting to the reader

Present the Chameleon Ultra to the target reader as if it were the legitimate credential. The reader will initiate an anticollision sequence, select the emulated card, and attempt Crypto1 authentication. The authentication attempt will fail (because the CU does not know the correct sector keys), but the reader’s nonce values for each attempted sector key are logged before the authentication failure is returned.

For reliable MFKey32 recovery, at least two authentication events per target sector key must be logged — the MFKey32 v2 algorithm requires two (nT, nR, aR) tuples for the same sector key to recover it with high probability. Present the CU to the reader twice (two separate read events) for each sector you want to recover.

The number of nonces accumulated is displayed in ChameleonUltraGUI as the detection log fills. The GUI button that was labeled “Enable Detection Mode” transitions to “Recover Keys from X nonces” once sufficient nonces have been collected, where X is the current nonce count. Two nonce pairs per sector is a minimum; more pairs increase recovery confidence.

There is no LED indication that detection mode is active or that nonces are being logged (per the RRG ChameleonUltraGUI wiki: “there is no color changes on the LED if the detection mode on or off” — the green or blue slot LED reflects field frequency, not detection-mode state). The only confirmation is the nonce counter visible in the GUI.

6.4.3 What the detection log contains

Each entry in the detection log captures a complete (nT, nR, aR) tuple from one Crypto1 authentication attempt: the tag nonce nT sent by the emulated CU, the encrypted reader nonce nR, and the reader authentication value aR sent by the reader. These three 32-bit values are the exact inputs to MFKey32 v2. The log also records the sector number and key type (A or B) associated with each authentication event — this is derived from which block number the reader requested, which determines which sector’s key is being authenticated. The full detection log can be retrieved with:

hf mf elog

This command returns the accumulated nonce tuples in human-readable form. hf mf elog without flags displays the log; the --decrypt flag (§5.2) initiates the key recovery computation.

6.5 MFKey32 v2 key recovery from detection-mode nonces

The MFKey32 v2 algorithm recovers a MIFARE Classic sector key from a pair of (nT, nR, aR) tuples collected from two authentication attempts to that sector. It was introduced as an improvement over the original MFKey32 (which required only one tuple but had a higher false-positive rate) by leveraging the second nonce pair to eliminate false candidates. The algorithm is published in the academic literature on Crypto1 weaknesses; the ChameleonUltra CLI implements it via the hf mf elog --decrypt pipeline.

6.5.1 Nonce pair extraction and processing

The detection log retrieval command hf mf elog parses the raw capture and presents the (nT, nR, aR) tuples organized by sector and key type. Each row corresponds to one authentication event. The --decrypt flag runs MFKey32 v2 over these tuples:

hf mf elog --decrypt

Internally, the CLI skips nonce pairs that have already been used in a successful key recovery (per the RRG CHANGELOG: “Skip already used items in hf mf elog --decrypt”), so re-running the command after a partial recovery is safe and will only process the remaining unresolved sectors. The MFKey32 v2 computation runs on the host (via the CLI’s Python client or in ChameleonUltraGUI’s compute layer) rather than on the nRF52840. The nRF52840 collects the nonces and stores them in RAM (the on-device log); the actual Crypto1 LFSR reversal is too computationally intensive for the Cortex-M4F within the operational latency constraints of a field session, and the decoupled host-side computation allows the RRG team to apply algorithmic improvements without a firmware reflash. This is consistent with the RRG technical whitepaper’s description of “decoupling the business logic of the CLI and the decryption algorithm logic.”

ChameleonUltraGUI implements the same flow in its GUI: the “Recover Keys from X nonces” button initiates host-side MFKey32 v2 computation and displays recovered keys per sector as they complete. The computation is parallelized across available CPU cores (per the RRG CHANGELOG: “Parallelize mfkey32v2 processes called from CLI”), so a typical key recovery for a 16-sector 1K card takes seconds to minutes on a modern phone or laptop.

6.5.2 Running MFKey32 v2

GUI workflow:

1. After collecting at least two nonce pairs per target sector (§4.2), tap Recover Keys from X nonces in ChameleonUltraGUI.
2. The GUI runs MFKey32 v2 host-side and populates a recovered-key table showing sector number, key type (A or B), and the recovered 48-bit hex key.
3. Keys marked as recovered are automatically cached in the GUI’s key dictionary for subsequent use in direct reads.

CLI workflow:

hf mf elog            # confirm nonce count and sectors covered
hf mf elog --decrypt  # run MFKey32 v2, print recovered keys per sector

After --decrypt completes, the CLI prints recovered sector keys. These keys can then be used immediately with hf mf rdbl to verify and read specific blocks, or fed into the Nested attack (hf mf nested) to propagate any already-known keys to sectors that the detection-log session may not have covered.

6.5.3 From partial keys to full map — Nested propagation

MFKey32 v2 recovers keys only for sectors the reader authenticated against during the detection-mode sessions. If the reader’s firmware authenticates only a subset of sectors (common in single-door access control where only sectors 0 and 1 carry the credential), the remaining sectors’ keys are not recovered by MFKey32 alone. The Nested attack (hf mf nested) bridges this gap: given one known sector key, it can recover keys for all remaining sectors by exploiting the Crypto1 PRNG’s inter-sector nonce relationships. The workflow:

hf mf nested --blk 0 -a -k <recovered-key-A-sector-0> --tblk 4 --ta

This example uses the recovered Key A for sector 0, block 0 to attack sector 1, block 4 (the first block of sector 1). Repeat for each unknown sector. Once all sector keys are recovered, hf mf rdbl reads each block to build a complete memory dump. The combination of detection-mode (MFKey32 v2) plus Nested is sufficient to fully recover a standard MIFARE Classic 1K in a single field session for any card whose reader is accessible for two authentication events. For a more detailed treatment of the Crypto1 attack suite see Vol 4.

6.6 Exporting a dump — file formats, storage on host

Once all sector keys are known and all blocks have been read, the assembled dump can be exported from the Chameleon Ultra via BLE or USB-C to the host running ChameleonUltraGUI or the CLI client.

6.6.1 Dump file formats

The ChameleonUltraGUI and CLI support three file formats for MIFARE Classic dumps:

Table 1 — The ChameleonUltraGUI and CLI support three file formats for MIFARE Classic dumps

Format	Extension	Description	Cross-tool compatibility
CUGUI JSON	.json	ChameleonUltraGUI native format; contains metadata (card type, UID, slot nick), key map, and block data encoded as JSON. Imported immediately by ChameleonUltraGUI without additional prompting.	CU GUI only
Raw binary	.bin	Flat binary file: all 1024 bytes (MIFARE Classic 1K) or 4096 bytes (4K) of card data in block order, no header. Same format as Proxmark3 RDV4 .bin dumps produced by hf mf dump.	Proxmark3, iCopy-X, MCT (partial)
MCT format	.mct	MIFARE Classic Tool format, originally from the Android MCT app; sector-separated hex blocks with +Sector:N headers. Supported by MTools BLE App; accepted by ChameleonUltraGUI via the import dialog.	Android MCT app, MTools

For cross-tool workflows with the Proxmark3 RDV4, the .bin format is the interchange layer: a Proxmark3 dump produced with hf mf dump can be imported directly into ChameleonUltraGUI or loaded via the CLI (hf mf eload -s <slot> -f dump.bin -t bin), and conversely a CU dump exported as .bin can be loaded into Proxmark3’s hf mf eload for comparison or replay. The Flipper Zero’s .nfc file format (which wraps block data with a header) is supported for MIFARE Ultralight via hf mfu nfcimport (per the RRG CHANGELOG) but the MIFARE Classic equivalent import path is not confirmed as of 2026-06; use .bin for MIFARE Classic cross-tool transfers.

6.6.2 Exporting via ChameleonUltraGUI / CLI

GUI export:

1. In ChameleonUltraGUI, navigate to Saved Cards (the card library, distinct from the active slot manager).
2. Locate the captured card entry (it was auto-saved to the library at the end of the read/recovery workflow, or can be saved manually via the slot context menu).
3. Tap the export action (quick-action button next to the card entry). Choose JSON for CU-native storage or .bin for cross-tool use.
4. The export writes to the phone’s document store (Android: Documents/ChameleonUltraGUI/; iOS: Files app under the ChameleonUltraGUI folder) or to the desktop file picker on desktop installs.

CLI export:

hf mf esave -s <slot> -f <filename>.bin -t bin

This saves the current slot’s emulation memory to a binary file. The -t flag accepts bin or hex; bin produces the raw binary format compatible with Proxmark3. Omitting -s saves the currently active slot.

6.6.3 Cross-tool interoperability

A .bin dump exported from the Chameleon Ultra can be:

• Loaded into the Proxmark3 RDV4 CLI via hf mf eload -f dump.bin for replay or comparison.
• Imported into the iCopy-X (which accepts raw binary dumps via its import interface) for writing to a physical T5577 or MIFARE Magic card.
• Archived on the host and re-loaded into the CU in a later session.

The reverse path — Proxmark3 dump loaded into CU — works identically: hf mf eload -s <slot> -f pm3_dump.bin -t bin. For the full cross-tool integration workflow that spans PM3 key recovery → CU emulation → iCopy-X physical clone, see Vol 8.

6.7 Loading a dump into a slot — the full round-trip

Slot loading is the final step of both the direct-read path and the detection-mode path. The result is a slot whose emulation memory contains the full card dump — UID, ATQA, SAK, and all sector data — ready to present to a reader.

6.7.1 Importing a dump into a slot

GUI workflow:

1. In ChameleonUltraGUI, open Slot Manager and select the target slot.
2. For HF: set the slot’s HF card type (e.g., MIFARE Classic 1K — the GUI shows the card type dropdown). This initializes the slot’s data structure for the correct card geometry.
3. Tap Import or Upload Dump. Select the previously exported or captured dump file (JSON, .bin, or .mct).
4. The GUI writes the dump data to the slot’s emulation memory. A progress indicator confirms the write.
5. Enable the slot for HF: ensure the HF enable toggle for the slot is active (green indicator per the GUI’s slot state icons).

CLI workflow:

hw slot type -s <slot> -t MIFARE_1024
hw slot init -s <slot> -t MIFARE_1024
hf mf eload -s <slot> -f dump.bin -t bin
hw slot enable -s <slot> --hf
hw slot change -s <slot>

The hw slot type command sets the slot’s card type. hw slot init initializes the slot’s data to defaults for that type. hf mf eload writes the dump data. hw slot enable activates the slot for HF emulation. hw slot change makes the slot the active one for presentation. The slot persists across power cycles; hw slot store is not required for persistence in current firmware (slots are written to flash on change), but verifying with hw slot list after loading confirms the configuration.

6.7.2 Validating emulation success

Test the emulated card against a known-good reader before the operational target. The validation sequence:

1. Field detection: Present the active slot to an HF reader; the white RF LED on the CU edge should illuminate, confirming the reader’s 13.56 MHz field is detected and the NFC-A hardware is responding.
2. Anticollision recognition: Verify the reader responds to the emulated card’s UID/ATQA/SAK combination. If the reader’s display shows “card not recognized” or a protocol error, check the slot’s configured ATQA and SAK against the values from the original hf 14a scan. A SAK mismatch (common when the card type selector in the GUI is set to the wrong MIFARE variant) causes readers that verify the card type to reject the emulated card at selection.
3. Crypto1 authentication: For readers that perform a full Crypto1 handshake, the reader will attempt to authenticate to the sector key in the loaded dump. Success is confirmed when the reader grants access (or reports the same outcome as with the original card). Failure at this stage means the sector key in the dump is incorrect — re-run key recovery or verify the dump was exported without partial-key residuals (§2.5).

A reader that rejects a correctly loaded MIFARE Classic dump despite correct UID/ATQA/SAK and complete sector keys indicates an anti-emulation measure: rolling UID (a non-static UID that changes on each presentation, defeating replay emulation), a challenge-response the dump doesn’t support, or an NFC-level application layer the CU doesn’t emulate (e.g., DESFire EV2 SAM-authenticated). These scenarios are covered in §8.3.

6.7.3 The full round-trip summary

The complete workflow from field encounter to emulation is:

1. HF read: Place target card on HF coil face. Run hf 14a scan (or GUI HF read) to obtain UID/ATQA/SAK. For MIFARE Classic, run the key recovery sequence (known-key probe → DarkSide → Nested → StaticNested as needed) to recover all sector keys.
2. Dump: Read all blocks using recovered keys via hf mf rdbl per block, or the GUI’s automated dump-after-recovery flow.
3. Export: Save as .bin (cross-tool) or CUGUI JSON (CU-native) via hf mf esave or GUI export.
4. Alternative path — detection mode: If the card is not separately available, configure a slot with the correct UID/ATQA/SAK, enable detection mode (hf mf econfig --enable-log), present the CU to the target reader twice per sector, retrieve nonces (hf mf elog), run MFKey32 v2 (hf mf elog --decrypt), then propagate to remaining sectors via Nested.
5. Slot load: Configure target slot with correct card type, load dump (hf mf eload), enable slot (hw slot enable --hf).
6. Validate: Present emulated slot to known-good reader; verify anticollision recognition and crypto authentication success.
7. Emulate: Present to operational target.

For LF credentials, the path is simpler (no key recovery step): read the LF ID, configure the LF slot with the correct protocol and ID, present.

6.8 Common failure modes and troubleshooting

6.8.1 Card not detected during read

The most common cause is incorrect face orientation: the MFRC522 HF coil is on the main-PCB face, not the antenna-PCB reverse. If hf 14a scan returns no response, flip the device and retry. Other causes:

• Insufficient coupling distance: Move the card within 1 cm of the coil surface. Cards inside a wallet or protective sleeve reduce range significantly.
• Non-ISO-14443A card: If the card does not respond to hf 14a scan and hf 14a info, it may be a 13.56 MHz card that does not use ISO 14443A (e.g., ISO 15693 vicinity cards, FeliCa, or NFC-B). The MFRC522 supports ISO 14443A and to a limited extent ISO 14443B; ISO 15693 and FeliCa are not in the current firmware’s supported protocol list as of 2026-06.
• LF card on HF face: Presenting a 125 kHz card to the MFRC522 will always time out. Check whether the ATQA/SAK scan times out immediately (field detected but no card response — likely wrong frequency) vs. the RF LED not lighting at all (no coupling).
• Firmware gap: The exact set of non-MIFARE ISO 14443A variants (Ultralight, DESFire, NTAG, etc.) in the current firmware’s read support is confirmed in the RRG CHANGELOG and issue tracker; consult those for a specific card type before concluding the hardware is at fault.

6.8.2 Key recovery fails

• DarkSide fails: Card has a hardened or random PRNG — common on MIFARE Classic EV1 newer revisions and MIFARE Plus. Switch to Nested if any sector key is already known (or discoverable via the known-key probe), or to the detection-mode / MFKey32 path if a reader is accessible.
• Nested fails on all sectors: May indicate the known-key bootstrap itself is incorrect, or the card uses a static-nonce variant. For generic static-plaintext-nonce cards (same nT every power cycle), the firmware auto-routes to StaticNested (MF1_STATIC_NESTED_ACQUIRE, v2.0.0) within the standard hf mf nested flow — no separate command is needed. For Fudan FM11RF08S cards (static encrypted nonce — DarkSide, Nested, and StaticNested all fail), use hf mf senested (firmware v2.1.0, PR #263), which exploits the FM11RF08S backdoor key rather than the Nested family of attacks.
• HardNested result: If hf mf nested reports “NT vulnerable: HardNested,” the card’s PRNG requires the HardNested algorithm. HardNested is implemented in the Chameleon Ultra CLI as of firmware v2.1.0 (released 2025-09-02, PR #254); run hf mf hardnested --blk <n> -k <key> --tblk <n> .... For time-critical sessions, a Proxmark3 RDV4 may complete the attack faster; recovered keys can be imported into the CU via the CLI or GUI.
• MFKey32 recovery incomplete: Too few nonce pairs (fewer than two per sector key) — present the CU to the target reader additional times with detection mode active. Or the reader only authenticates a subset of sectors — use Nested to propagate from the recovered subset.

6.8.3 Reader rejects emulated card

• SAK or ATQA mismatch: Confirm the slot’s emulation configuration matches the original card’s ATQA and SAK byte-for-byte. A SAK of 18 (MIFARE Classic 4K) versus 08 (1K) will cause readers with card-type validation to reject the emulated card at selection. Recheck with hf 14a info on the original card and update the slot’s econfig accordingly.
• UID length mismatch: Some readers validate that the UID is four bytes (single-size) vs. seven bytes (double-size). The slot must be configured with the correct UID length — hf mf econfig -s <slot> --uid <4-or-7-byte-hex>. Loading a 7-byte UID into a MIFARE Classic 1K slot configured for a 4-byte UID will produce an incorrect anticollision response.
• Rolling UID / anti-clone measure: Some high-security installations use readers programmed to reject credentials whose UID remains constant across multiple presentations (a UID that never changes is a tell of emulation). These systems may require a rolling-UID or challenge-response capability beyond the CU’s current firmware scope. This is an active area of firmware development; check the RRG repository for the latest status.
• Application-layer challenge-response: MIFARE DESFire EV2/EV3 with AES-128 SAM authentication, HID iCLASS SE/SEOS, and similar high-security HF formats are not emulated by the current Chameleon Ultra firmware. MIFARE Classic emulation succeeds for Crypto1-authenticated systems; for higher-security formats the iCopy-X iCS Decoder (iCLASS) or Proxmark3 RDV4 (DESFire) workflows apply (see ../iCopy-X/ Vol 6 and Vol 8).
• Timing-sensitive reader: Some older readers have strict timing windows for card responses. The nRF52840 NFC-A emulation meets ISO 14443A timing requirements, but edge-case readers (particularly older building-access systems with non-standard timing windows) occasionally reject the CU. Firmware updates periodically address known compatibility issues; check the RRG issue tracker for your reader’s symptom pattern.

6.8.4 Detection-mode nonce capture is empty or insufficient

• Detection mode not enabled before presentation: Confirm hf mf econfig --enable-log was issued and the device is in emulator mode (hw mode -e) before presenting to the reader. There is no on-device LED indicator for detection mode state; confirm via hf mf elog showing a non-zero nonce count after the reader presentation.
• UID/ATQA/SAK mismatch: If the emulated slot’s UID does not match the credential the reader expects, the reader may reject the card at anticollision (before attempting authentication), producing zero nonces. Verify the slot is configured with the target card’s exact UID.
• Reader grants access without authentication: The reader is UID-gated only; it returns access granted without performing Crypto1 authentication, so no authentication nonces are logged. The MFKey32 path does not apply to UID-gated systems — a UID-only slot is sufficient.
• Insufficient presentations: Two authentication events per sector key are needed for MFKey32 v2 to recover the key. Present the CU to the reader the required number of times; hf mf elog shows the accumulated nonce count after each presentation.