Chameleon Ultra — Read, Sniff, and Clone Workflow

Stub — section skeleton authored 2026-06-27; prose to follow.

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

Orients the reader to the three fundamental interaction modes: (1) direct read — the Chameleon Ultra actively interrogates a card using its MFRC522; (2) sniff — the Chameleon passively observes a legitimate reader–card exchange; (3) clone (via slot load) — loads a captured dump into a slot for subsequent emulation. Explains why all three modes exist and which to reach for first depending on access conditions.

6.1.1 When to read vs sniff

Decision guidance: read directly when you have physical access to the card for ~5 seconds; sniff when you can position the Chameleon between the reader and the card during a legitimate transaction (or when the card owner cannot be separated from the card).

6.1.2 Clone vs emulate

Clarifies the Chameleon Ultra’s posture: it does not write to blank card stock (“clone” in the iCopy-X sense); it loads the dump into an emulation slot. Points to iCopy-X Vol 7 and Vol 9 for the physical-blank workflow when a tangible credential is required.

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

Step-by-step HF read workflow: present target card to the Chameleon Ultra’s HF coil face, initiate read via ChameleonUltraGUI, observe UID + ATQA + SAK, run key recovery if the card is MIFARE Classic, capture full memory dump once all sector keys are known, and confirm slot load.

6.2.1 Physical card placement

Explains coil face orientation, optimal placement distance, and position sensitivity for HF reads.

6.2.2 Initiating a read in ChameleonUltraGUI

Step-by-step: open app, navigate to read screen, tap Read, observe detected card type. [VERIFY: current GUI flow against latest ChameleonUltraGUI release]

6.2.3 UID-only vs full-dump reads

Explains the difference between capturing only the UID (sufficient for UID-gated readers) and capturing a full sector dump (required for MIFARE Classic crypto-authenticated access control).

6.2.4 Automated key recovery during read

Describes how ChameleonUltraGUI integrates the Crypto1 attack suite (default key probe → DarkSide → Nested) into the read workflow as a single user-initiated sequence. [VERIFY: current automated attack sequence in GUI]

6.2.5 Confirming a complete dump

Explains how to verify that all sectors are readable (no “unknown key” residuals) before loading the dump into a slot.

6.3 LF card read workflow

Step-by-step LF read workflow: present target LF card to the LF coil, initiate read via ChameleonUltraGUI, observe protocol type + credential value, load into LF slot.

6.3.1 Physical card placement for LF

Notes LF coil position and orientation on the Chameleon Ultra; explains that LF read range is shorter than many users expect from the nRF52840-based LF path.

6.3.2 Protocol auto-detection

Explains that ChameleonUltraGUI attempts to auto-detect the LF protocol; notes cases where manual protocol selection is needed. [VERIFY: auto-detection coverage in current firmware]

6.3.3 Loading an LF credential into a slot

Step-by-step: configure the LF slot with the detected protocol and value. [VERIFY: current GUI flow]

6.4 Sniffing — passive observation of a reader–card exchange

Describes sniff mode: the Chameleon Ultra places itself between a legitimate reader and a card during a normal authentication event, capturing the nonces exchanged without disrupting the transaction. Explains physical positioning, sniff mode activation, and what data is captured.

6.4.1 Physical positioning for sniff

Explains the sniff geometry: Chameleon Ultra must be close enough to the card or reader to pick up the RF exchange; optimal position varies by reader power level and Chameleon antenna coupling. [VERIFY: practical sniff-distance guidance from community field reports]

6.4.2 Activating sniff mode

Step-by-step via ChameleonUltraGUI: enter sniff mode, wait for exchange, observe capture result. [VERIFY: current GUI flow]

6.4.3 What a sniff capture contains

Describes the nonce pairs captured during a MIFARE Classic authentication exchange and why they are sufficient input for MFKEY32 v2 key recovery.

6.5 MFKey32 v2 key recovery from sniffed nonces

Step-by-step MFKEY32 v2 workflow: sniff a reader–card exchange, extract nonce pairs from the capture, run MFKEY32 v2 in ChameleonUltraGUI to derive sector keys, then run Nested to propagate to a full key map. [VERIFY against current firmware docs — confirm MFKey32 v2 is run on-device vs requiring a host-side tool]

6.5.1 Nonce pair extraction

Explains how the raw sniff capture is parsed to extract the (nT, nR, aR) tuples required by MFKEY32 v2.

6.5.2 Running MFKEY32 v2

Step-by-step key recovery from the extracted nonces, either on-device or via host-side tool. [VERIFY: on-device vs host-side processing for the Chameleon Ultra implementation]

6.5.3 From partial keys to full map — Nested propagation

Explains that MFKEY32 v2 typically recovers keys for the sniffed sectors; Nested attack then propagates to remaining sectors. Ties back to Vol 4 §5.

6.6 Exporting a dump — file formats, storage on host

Describes how to export a captured card dump from the Chameleon Ultra: dump file formats (MIFARE Classic .mfd, generic binary, any ChameleonUltraGUI-specific format), export via BLE to the GUI app, and storage on the host for archival or cross-tool use.

6.6.1 Dump file formats

Lists the file formats the Chameleon Ultra and ChameleonUltraGUI use for card dumps; notes compatibility with Proxmark3 RDV4’s dump format (.bin / .mfd) for cross-tool workflows. [VERIFY: format compatibility with pm3 dump files]

6.6.2 Exporting via BLE/GUI

Step-by-step: export dump from ChameleonUltraGUI to phone storage or desktop. [VERIFY: current export flow]

6.6.3 Cross-tool interoperability

Notes how dump files can be imported into Proxmark3 client or iCopy-X; points to Vol 8 for the full cross-tool integration workflow.

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

Completes the read→emulate round-trip: importing a dump (captured live or imported from a file) into a named HF or LF slot, confirming the slot is active, and presenting the emulated card to a reader for validation.

6.7.1 Importing a dump into a slot

Step-by-step via ChameleonUltraGUI: select target slot, choose card type, import dump or paste UID + key map. [VERIFY: current GUI flow]

6.7.2 Validating emulation success

Explains how to confirm the emulated card is accepted by the target reader: test on a known-good reader first, check for ATQA/SAK recognition, verify that crypto-authenticated reads succeed.

6.7.3 The full round-trip summary

One-paragraph summary of the complete workflow — read or sniff → key recovery → dump → slot load → emulate — as a field-ready reference.

6.8 Common failure modes and troubleshooting

Catalogs the most common failure scenarios in the read→emulate workflow with root causes and fixes.

6.8.1 Card not detected during read

Covers: wrong coil face, card too far, card on non-ISO-14443A protocol (try LF slot), firmware-version protocol gap. [VERIFY: current firmware protocol gap list]

6.8.2 Key recovery fails (DarkSide/Nested)

Covers: reader-hardened PRNG (try HardNested), card sectors locked (try MFKEY32 via sniff), card is not MIFARE Classic (check ATQA/SAK).

6.8.3 Reader rejects emulated card

Covers: SAK/ATQA mismatch, UID length mismatch (4B vs 7B), reader requires rolling UID (anti-clone measure), reader performs a challenge-response the dump doesn’t support.

6.8.4 Sniff capture is empty or incomplete

Covers: positioning too far from reader or card, sniff mode not active before the transaction, card completed auth before Chameleon was positioned.