Chameleon Ultra — HF Emulation and Crypto1 Attacks

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

4.1 The 8 HF slot model

Explains the 8-slot architecture for HF: each slot is independently configured with a card type and a loaded dump; slots are named and switched via BLE app or USB CLI; the button cycles slots in order when BLE is not connected. Points to Vol 7 for the full slot-management workflow.

4.1.1 Slot independence

Notes that each HF slot holds its own card type, UID, and memory dump independently — switching slots is instantaneous from the reader’s perspective.

4.1.2 Persistent slot storage

Explains that slot configurations and dumps persist across power cycles in the nRF52840’s flash.

4.2 ISO 14443A emulation — how the nRF52840 + MFRC522 present as a card

Describes the emulation mechanism at the RF level: how the firmware configures the MFRC522 to present a card identity, respond to REQA/SELECT, replay the correct ATQA and SAK bytes for the configured card type, and handle the anticollision loop.

4.2.1 ATQA and SAK — the card-type fingerprint

Explains how the Chameleon sets ATQA and SAK bytes to match the emulated card family; notes that a misconfigured SAK will cause reader rejection even if the UID and data are correct.

4.2.2 Emulation timing and reader compatibility

Discusses known reader-compatibility considerations — readers with strict timing requirements or proprietary extensions that may not accept emulated cards. [VERIFY: known incompatible reader families from firmware issue tracker]

4.3 MIFARE Classic 1K and 4K — slot configuration, UID types, sector layout

Covers the two most common card types in the Chameleon’s HF scope: MIFARE Classic 1K (16 sectors, 64 blocks) and 4K (40 sectors, 160 blocks); explains 4-byte vs 7-byte UID selection; notes the 2K variant. Cross-references the sector/block layout primer in Vol 3 §5.1.

4.3.1 1K vs 4K — slot size and dump format

Explains the memory layout difference and how dump file sizes differ (1K = 1024 bytes, 4K = 4096 bytes).

4.3.2 UID type selection — 4B vs 7B

Explains when a 4-byte vs 7-byte UID is required and how to configure the slot for each.

4.3.3 MIFARE Classic 2K

Brief note on 2K support; confirms it is in scope. [VERIFY: 2K emulation confirmation in current firmware changelog]

4.4 DarkSide attack — when there are no known keys

Describes the DarkSide (Cortez) attack: exploits MIFARE Classic PRNG error-handling to recover the first key with zero prior knowledge; explains the precondition (target must be using a vulnerable reader that leaks the error bit), typical time-to-first-key, and what to do when DarkSide fails (move to MFKEY32 sniffing instead).

4.4.1 How DarkSide works

Conceptual explanation of the PRNG XOR leak and how repeated authentication failures expose key bits.

4.4.2 Running DarkSide on the Chameleon Ultra

Step-by-step via ChameleonUltraGUI: position, initiate attack, wait for key recovery result. [VERIFY: current GUI workflow against latest ChameleonUltraGUI release]

4.4.3 When DarkSide fails

Notes conditions where DarkSide is unreliable (fixed-nonce readers, hardened cards); transitions to Nested or MFKEY32 alternatives.

4.5 Nested attack — from one known key to the full sector map

Describes the Nested (Nonce) attack: given one known key for any sector, recovers all remaining sector keys by exploiting the PRNG correlation between successive authentications; explains typical time-to-full-map.

4.5.1 Precondition — one known key

Explains that Nested requires at least one known key as a starting point; cross-references the default-key list (many deployed MIFARE Classic cards use factory default keys for some sectors) and DarkSide as the zero-knowledge precursor.

4.5.2 Running Nested on the Chameleon Ultra

Step-by-step via ChameleonUltraGUI. [VERIFY: current GUI workflow]

4.6 StaticNested attack

Describes StaticNested: a variant of Nested that applies when a card’s PRNG produces a fixed nonce (same seed every power cycle); more efficient than the general Nested attack for this card class.

4.6.1 When to use StaticNested vs Nested

Explains the static-PRNG card class (some older MIFARE Classic implementations) and how to detect it (repeated authentication attempts return the same nonce).

4.6.2 Running StaticNested on the Chameleon Ultra

Step-by-step. [VERIFY: current GUI workflow and firmware support]

4.7 HardNested attack — hardened PRNG cards

Describes HardNested: targets MIFARE Classic cards where the PRNG has been hardened against the standard Nested attack (the nonce sequence is no longer predictable from the first known key alone); explains the increased computation requirement and notes that the nRF52840 is slower than a tethered Proxmark3 for this attack.

4.7.1 The hardened PRNG problem

Explains what makes a MIFARE Classic card “hardened” against standard Nested and why a different attack approach is needed.

4.7.2 Running HardNested on the Chameleon Ultra

Step-by-step. Notes expected time-to-completion vs Proxmark3 RDV4 for the same target. [VERIFY: benchmark data from community reports]

4.7.3 When to hand off to Proxmark3

Explains the decision point: if HardNested on the Chameleon Ultra is too slow for field conditions, the same attack via the Proxmark3 Iceman client is the right escalation.

4.8 MFKEY32 v2 — key recovery from sniffed reader–card exchanges

Describes MFKEY32 v2: recovers MIFARE Classic keys from captured nonces observed during a legitimate reader–card exchange (sniffing), without ever directly probing the card; the sniff-then-crack workflow is the operational alternative when the reader is inaccessible for direct attack.

4.8.1 The sniff-first workflow

Explains sniffing as passive observation: Chameleon Ultra listens while the legitimate card authenticates to its reader, captures the nonce pairs, then runs MFKEY32 v2 to derive the keys offline.

4.8.2 Running MFKEY32 v2 on the Chameleon Ultra

Step-by-step via ChameleonUltraGUI: enter sniff mode, capture exchange, initiate key recovery. [VERIFY: current GUI workflow]

4.8.3 MFKEY32 v2 vs the original MFKEY32

Brief note on the v2 improvement (reduced nonce requirement). [VERIFY: technical delta between v1 and v2]

4.9 UID bruteforcing

Describes UID brute-force capability if supported: iterating UIDs to find which UID a reader will accept, useful when a site credential management system grants access by UID range rather than cryptographic validation. [VERIFY: firmware capability scope — confirm UID bruteforce is a distinct mode in the current ChameleonUltra firmware or whether this is handled by the slot-cycling workflow]

4.9.1 Use case and preconditions

Explains the (rare) access-control posture where UID alone grants access, making bruteforce viable.

4.9.2 Operational limits

Notes practical limits: search space (32-bit or 56-bit UID space), reader retry lockout behavior, and time-to-completion estimates. [VERIFY]

4.10 MIFARE Ultralight and NTAG 210–218

Covers the Ultralight/NTAG card families: 48-byte (Ultralight) to 924-byte (NTAG 218) memories, no Crypto1 (OTP and password protection only on later variants), common use cases (transit tokens, NFC data payloads, event tickets). Emulation scope for each NTAG variant.

4.10.1 Ultralight — emulation basics

Explains Ultralight’s minimal protocol (UID + 48 bytes, no rolling keys) and the Chameleon’s emulation approach.

4.10.2 NTAG variants in scope

Lists NTAG 210–218 with their memory sizes; notes password-protection emulation support per variant. [VERIFY: NTAG 21x emulation completeness in current firmware]

4.11 MIFARE DESFire EV1/EV2 — emulation scope

Describes the Chameleon Ultra’s DESFire EV1/EV2 emulation capability and its limits: DESFire uses AES/3DES rather than Crypto1, so the Crypto1 attack suite does not apply; emulation is possible for pre-loaded dumps but active key recovery is out of scope. [VERIFY: exact emulation scope — whether DESFire emulation is limited to UID + application directory replay or includes full crypto-authenticated read/write]

4.11.1 What DESFire emulation covers

Explains the difference between UID-layer emulation (sufficient for UID-only readers) and full application-layer emulation (required for crypto-authenticated access control). [VERIFY]

4.11.2 DESFire and the Proxmark3 handoff

Notes when a DESFire target requires the Proxmark3 RDV4’s more complete DESFire implementation.

4.12 MIFARE Plus — emulation scope

Describes MIFARE Plus emulation: Plus is a backward-compatible successor to MIFARE Classic that can run in Classic compatibility mode (Crypto1) or AES-secured SL2/SL3 modes; emulation scope depends on the card’s active security level. [VERIFY: MIFARE Plus emulation modes supported in current firmware — SL1/SL2/SL3 coverage]

4.12.1 Security Level 1 — Classic compatibility mode

Explains that SL1 MIFARE Plus cards behave identically to MIFARE Classic 1K/4K from the Crypto1 attack perspective; the full Crypto1 suite applies.

4.12.2 Security Levels 2 and 3

Notes that SL2/SL3 use AES; attack capability is out of scope for the Chameleon; cross-links to Proxmark3 for research-grade Plus analysis. [VERIFY]