Chameleon Ultra — HF Emulation and Crypto1 Attacks

4.1 The 8 HF slot model

The Chameleon Ultra holds eight independently configured HF slots, each carrying its own card type, UID, memory dump, and recovered sector keys. From the perspective of the reader the device presents to, switching between slots is instantaneous — the nRF52840’s NFC-A hardware block is reconfigured at the moment of the slot change, and the next reader field interaction sees the new identity without any residual state from the previous slot. There is no boot time between slots, no reset delay, and no visible RF-layer artifact.

Slot switching is managed from ChameleonUltraGUI over BLE or from the USB-C CLI. When neither connection is active, Button A and Button B cycle the active slot backward and forward respectively — a necessary fallback for scenarios where operating a phone is inconvenient or inappropriate. The active slot is indicated by the illuminated RGB LED at the corresponding position in the eight-LED strip; the LED color reflects whether the slot is HF-loaded, LF-loaded, both, or empty (see Vol 2 §6.2 for the LED state map). The cycle is circular: pressing past slot 8 wraps to slot 1.

4.1.1 Slot independence

Each of the eight HF slots is a completely independent configuration block. Within a slot, the configuration includes the emulated card family (MIFARE Classic 1K, MIFARE Classic 4K, MIFARE Ultralight, NTAG, DESFire EV1/EV2, MIFARE Plus, or empty), the UID and UID length (4-byte or 7-byte, depending on the card family), the ATQA and SAK bytes that fingerprint the card type, and the full memory dump for the emulated card. For MIFARE Classic slots, the sector keys recovered by any of the five attack methods are stored alongside the dump so the emulation can respond correctly to authentication challenges.

The key operational consequence of slot independence is that an operator can carry eight different card identities simultaneously — different access-control credentials from different sites, different card families, different UIDs — and switch between them in the field without any re-configuration step. A hotel key in slot 1, a corporate badge in slot 2, a transit card in slot 3: each is its own complete snapshot, self-contained, with no interaction between them.

4.1.2 Persistent slot storage

Slot configurations and dumps persist across power cycles in the nRF52840’s 1 MB internal flash. The same flash that holds the GPL-3.0 firmware also allocates storage for the eight combined HF+LF slot entries. When the device is powered off — or when the LiPo cell hits its undervoltage lockout threshold — the slot contents are not lost. The device wakes with all eight slots intact, in exactly the state they were in when power was last removed. Vol 7 covers the slot-management CLI commands for reading, writing, and clearing slot entries; Vol 9 covers the firmware build and flash layout for readers who want to trace exactly where slot storage sits in the flash address space.

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

A critical distinction governs which hardware component does what in the Chameleon Ultra’s HF operation: the nRF52840’s integrated NFC-A tag hardware block handles card emulation (the device presenting itself as a card to a reader), while the MFRC522 handles reader mode (the device interrogating a target card). These two paths are physically and logically distinct. When the Chameleon Ultra emulates a MIFARE Classic slot, the MFRC522 plays no role at all — the nRF52840 NFC-A block responds to the incoming reader field, demodulates the reader’s commands, and load-modulates the correct responses back. The MFRC522 is only active during the attack phases where the Ultra is acting as a reader and probing a target card.

The emulation sequence follows the ISO/IEC 14443A Type A initialization protocol, described in Vol 3 §4.1. When the Chameleon Ultra is placed in a reader’s field:

1. The reader broadcasts REQA (Request Type A, 7-bit command at 106 kbit/s).
2. The nRF52840 NFC-A block responds with the slot’s configured ATQA (Answer to Request Type A — 2 bytes encoding UID size and anticollision frame).
3. The reader issues ANTICOLLISION commands; the nRF52840 participates with the slot’s UID.
4. On SELECT, the nRF52840 returns the slot’s configured SAK (Select Acknowledge — 1 byte that identifies the card’s protocol family).
5. The reader proceeds to the card-specific application protocol: for MIFARE Classic, this is the three-pass Crypto1 mutual authentication (see §3); for Ultralight/NTAG, direct page reads; for DESFire, the T=CL application-level exchange.

4.2.1 ATQA and SAK — the card-type fingerprint

The ATQA and SAK bytes are the reader’s primary mechanism for identifying what kind of card it is talking to. A reader that expects a MIFARE Classic 1K and receives the wrong SAK will reject the device before it ever attempts authentication — SAK validation happens at the protocol layer below authentication. Getting these bytes right is prerequisite to everything that follows.

The Chameleon Ultra’s slot configuration sets ATQA and SAK to match the emulated card family. Standard values for the card families in the Ultra’s emulation scope:

Table 1 — The Chameleon Ultra's slot configuration sets ATQA and SAK to match the emulated card family. Standard values for the card families in the Ultra's emulation scope

Card family	ATQA	SAK
MIFARE Classic 1K (4B UID)	00 04	08
MIFARE Classic 1K (7B UID)	00 44	08
MIFARE Classic 4K (4B UID)	00 02	18
MIFARE Classic 4K (7B UID)	00 42	18
MIFARE Ultralight / NTAG	00 44	00
MIFARE DESFire EV1/EV2	03 44	20
MIFARE Plus (SL1, 4B UID)	00 04	08 (SL1 identical to Classic)
MIFARE Plus (SL3, 4B UID)	00 04	20

When loading a card dump from a Proxmark3 or iCopy-X session, the ATQA and SAK are typically embedded in the dump’s metadata and should be copied into the slot configuration as-is. Manual entry risks setting the wrong value — particularly for the MIFARE Plus SL1 case, which uses Classic-identical ATQA/SAK and is easy to misconfigure as a Classic rather than a Plus.

4.2.2 Emulation timing and reader compatibility

The ISO 14443A standard specifies mandatory Frame Delay Times (FDT) — the maximum elapsed time between the end of a reader’s transmission and the beginning of the card’s response. The nRF52840’s NFC-A hardware block is designed to meet these timing requirements; in normal emulation scenarios it does so reliably.

Reader compatibility issues arise from several sources that the FDT specification does not fully address. Some enterprise-grade access-control readers implement proprietary anti-emulation fingerprinting: they send additional challenge sequences or measure RF load-modulation characteristics that differ between a genuine silicon card and an nRF52840 NFC-A response. The Chameleon Ultra’s firmware does not and cannot match the silicon-level load-modulation of a genuine NXP MIFARE Classic die; readers that perform this level of fingerprinting will reject the emulated card regardless of how correctly the protocol-layer bytes are configured. No exhaustive list of such readers has been published by RRG or confirmed in the firmware issue tracker as of 2026-06; the Dangerous Things forum and GitHub issues have documented specific reader models that show this behavior (issues referencing brand-name proximity readers from HID Global and Allegion), but an authoritative compatibility matrix does not currently exist in public sources. The practical approach is to test emulation against the target reader in a controlled environment before relying on it for an engagement; if rejection occurs despite correct ATQA/SAK/UID configuration, the reader is a candidate for this class of incompatibility.

A separate compatibility constraint applies to readers that operate at higher communication rates (212 kBd, 424 kBd, 848 kBd per ISO 14443A). The ChameleonUltra firmware currently emulates at 106 kBd (the ISO 14443A baseline). Most access-control readers use the 106 kBd baseline; the higher rates are primarily relevant for DESFire EV2 tap-to-pay readers, which are outside the access-control scope this series addresses.

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

MIFARE Classic is the dominant card family in deployed HF access-control worldwide and the primary target of the Chameleon Ultra’s attack suite. The 1K and 4K variants are structurally identical at the cipher and authentication layers — both use Crypto1, both use 48-bit Key A and Key B per sector, both are subject to the same five-attack recovery suite — and differ only in sector count, memory size, and the structure of the upper sectors in the 4K.

The Vol 3 §5.1 primer gives the definitive sector and block layout. The salient values:

Table 2 — The Vol 3 §5.1 primer gives the definitive sector and block layout. The salient values

Variant	Sector structure	Total sectors	Total blocks	Dump size
MIFARE Classic 1K	16 sectors × 4 blocks	16	64	1 024 bytes
MIFARE Classic 4K	32 sectors × 4 blocks + 8 sectors × 16 blocks	40	256	4 096 bytes
MIFARE Classic 2K	32 sectors × 4 blocks	32	128	2 048 bytes

Each block is 16 bytes. The last block of every sector is the sector trailer (Key A, 3-byte ACL, user byte, Key B), not a data block. Sector 0, Block 0 is the manufacturer block — UID, BCC, SAK, ATQA, manufacturer data — and is hardware-locked on genuine NXP silicon.

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

Slot configuration begins with selecting the card type; the Chameleon Ultra allocates storage for the dump based on that selection. A 1K slot stores 1 024 bytes (64 blocks × 16 bytes); a 4K slot stores 4 096 bytes (256 blocks × 16 bytes). Dump files transferred from a Proxmark3 or iCopy-X session use the .mfd (MIFARE Dump) format — a flat binary image of the card’s memory, block-sequential — and this format loads directly into a slot.

The 4K slot’s additional blocks live in sectors 32–39, each sixteen blocks wide rather than four. These large sectors are where most 4K deployments store time-variant access data (hotel room timeslots, multi-application data), and they are the sectors most likely to have sector-unique keys that require the full Nested or HardNested attack to recover.

4.3.2 UID type selection — 4B vs 7B

MIFARE Classic 1K cards are factory-programmed with either a 4-byte (single-size) or a 7-byte (double-size) UID, and the Chameleon Ultra slot configuration must match. A 4B UID requires one anticollision CASCADE LEVEL during SELECT; a 7B UID requires two cascade levels. Readers strictly implement the cascade-level count implied by the ATQA’s UID-size bits — if the ATQA says 4B but the configured UID is actually 7 bytes, the reader will attempt a single-cascade select, fail, and reject the card.

MIFARE Classic 4K cards similarly come in 4B and 7B variants; the SAK is the same (0x18) regardless of UID size, but ATQA bit 6 switches between single- and double-size (0x00 vs 0x40 in the high byte of the ATQA). ChameleonUltraGUI exposes the UID length as an explicit configuration field on the slot; when loading a dump from a Proxmark3 or iCopy-X session the dump’s embedded ATQA provides the correct value automatically.

4.3.3 MIFARE Classic 2K

MIFARE Classic 2K support is confirmed in the RRG firmware whitepaper: the supported card list explicitly reads “MIFARE Classic1K/2K/4K (4B/7B)” across hardware, software, and application layers. The 2K variant is a 32-sector, 4-blocks-per-sector layout totaling 128 blocks and 2 048 bytes — structurally identical to the first 32 sectors of a 4K, without the 16-block extended sectors. It is rare in deployed access-control systems (few card issuers have a use case requiring more than 1K but less than 4K), but the firmware handles it correctly when a 2K card is encountered. The Crypto1 attack suite applies identically.

4.4 DarkSide attack — when there are no known keys

The DarkSide attack — formally introduced by Nicolas Courtois in “The Dark Side of Security by Obscurity and Cloning MiFare Classic Rail and Building Passes Anywhere, Anytime” (SECRYPT 2009, proceedings pages 331–338) — is the zero-knowledge entry point into a MIFARE Classic card: it recovers the first sector key with no prior knowledge of any key on the card. It requires the Chameleon Ultra’s MFRC522 reader to actively probe the target card and is therefore unavailable on the Lite (Vol 2 §3.2).

4.4.1 How DarkSide works

The DarkSide attack exploits a specific protocol-level leakage that exists in the original MIFARE Classic authentication implementation. When the MFRC522 sends a deliberately malformed reader response during the three-pass Crypto1 authentication handshake, the card replies with a 4-bit NACK error code — and that NACK is not transmitted in plaintext. It is the Crypto1-encrypted form of the constant NACK value (the known plaintext), encrypted with the keystream initialized from the card’s nonce (nT) and the unknown key. This gives the attacker 4 keystream bits per authentication exchange: an (nT, encrypted_NACK) pair that constrains the 48-bit Crypto1 key through the filter function’s known biases.

The attack proceeds iteratively: the MFRC522 sends authentication requests with systematically varied reader nonces, collecting (nT, encrypted_NACK) pairs. Because the Crypto1 LFSR’s nonlinear filter function has specific odd-parity output properties for certain input patterns, each pair constrains the candidate key space. After several hundred to a few thousand pairs, the 48-bit key space is collapsed to O(2^16–2^20) candidates, each of which is then verified by attempting a normal authentication. Courtois’s 2009 paper characterized the attack as requiring approximately 300 card interactions on optimal hardware, though real-world implementations on the nRF52840 may vary.

DarkSide’s fundamental precondition: the card’s PRNG must be the original MIFARE Classic generation. The attack fails against cards with hardened nonce generation — specifically Fudan Microelectronics FM11RF08S clones and NXP’s MIFARE Classic EV1 revision — because the filter-function bias that DarkSide exploits is removed by the hardening. The correct escalation differs by card type: MIFARE Classic EV1 (SmartMX-based) and MIFARE Plus SL1 cards are addressed by HardNested (§7), which requires one known key; FM11RF08S cards require the separate static-encrypted-nonce backdoor recovery described in §4.3. In either case, DarkSide (or a default-key dictionary pass) remains the zero-knowledge first step when no key is known.

4.4.2 Running DarkSide on the Chameleon Ultra

The ChameleonUltra firmware v2.0.0 (2023-09-26) enhanced the DarkSide implementation with LED visual feedback during the attack and improved parity handling — the attack is confirmed as a fully implemented, application-layer feature in current firmware releases. The firmware releases list the internal command as a refactored form that replaced the earlier MF1_DETECT_DARKSIDE command path.

Via ChameleonUltraGUI, the general workflow is: place the target MIFARE Classic card against the Ultra’s HF coil, navigate to the MIFARE Classic attack section, and initiate the DarkSide attack. The device’s MFRC522 takes over the reader role, probing the target card; the nRF52840 runs the key-recovery computation. The attack typically recovers the first key within seconds to low minutes for a standard unmodified MIFARE Classic 1K.

The CLI equivalent follows the Proxmark3-style command structure that the ChameleonUltra Python CLI wraps: hf mf darkside initiates the attack; the exact argument set for the ChameleonUltra’s CLI differs from the Proxmark3 Iceman client’s syntax in implementation details. Consult the current CLI help output (hf mf darkside --help) or the RRG wiki command reference at github.com/RfidResearchGroup/ChameleonUltra/wiki for the confirmed current syntax, as the CLI evolves between firmware releases.

4.4.3 When DarkSide fails

DarkSide fails in two conditions: the card uses hardened nonce generation (FM11RF08S Fudan clone, NXP MIFARE Classic EV1), or the card is behind an access-control reader that prevents the MFRC522 from interacting with it directly.

For the hardened-PRNG case: if DarkSide attempts complete without returning a key — indicated by the attack exhausting its nonce-collection budget without finding a valid candidate — the card is likely a hardened variant. The correct next step depends on which variant. First, attempt a default-key dictionary pass (many FM11RF08S and EV1 deployments still use factory defaults in at least one sector).

If the card is an FM11RF08S, dictionary failure does not lead to HardNested — it leads to the static-encrypted-nonce backdoor attack (senested, implemented in ChameleonUltra firmware PR #263). The FM11RF08S uses a static encrypted nonce specifically engineered to defeat all card-only attacks including HardNested; Quarkslab’s 2024 disclosure (eprint.iacr.org/2024/1275) revealed a universal backdoor key (A396EFA4E24F) embedded in the FM11RF08S silicon that the senested command exploits for key recovery. This attack is distinct from HardNested and is handled by a separate firmware code path.

If the card is a MIFARE Classic EV1 (SmartMX-based) or MIFARE Plus SL1, the correct escalation is HardNested (§7), which addresses cards with a hardened PRNG but without the FM11RF08S static-encrypted-nonce construction.

For the reader-access case — where the target card cannot be physically removed for direct probing — DarkSide is inapplicable and the MFKEY32 v2 sniff workflow (§8) is the correct alternative.

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

The Nested attack was formally introduced in “Wirelessly Pickpocketing a Mifare Classic Card” by Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wichers Schreur (IEEE Symposium on Security and Privacy 2009, S&P ‘09, pages 3–15) and builds on the cryptanalytic foundations established in “Dismantling MIFARE Classic” (Garcia, Gans, Hoepman, and Verdult, ESORICS 2008). Where DarkSide recovers the first key from nothing, Nested exploits a known key to recover all remaining sector keys — and it is fast. For a MIFARE Classic 1K card with one known key, full sector-map recovery typically completes in minutes.

4.5.1 Precondition — one known key

Nested requires one known 48-bit key for any sector on the card before it can proceed. The most common sources of that first key:

Default-key dictionary: The overwhelming majority of deployed MIFARE Classic cards retain factory-default keys in at least one sector. The most prevalent defaults — FFFFFFFFFFFF, A0A1A2A3A4A5, D3F7D3F7D3F7, 000000000000, B0B1B2B3B4B5 — are documented in the Proxmark3 Iceman repository’s mfc_default_keys.dic file and baked into the ChameleonUltra’s pre-attack key-test pass. For any sector where a default key is found, Nested has a known starting point immediately.

DarkSide output: If the card uses non-default keys throughout but has a vulnerable PRNG, DarkSide recovers the first key. Nested then sweeps the remaining sectors from that starting point.

The Nested attack does not care which sector the known key belongs to, nor whether it is Key A or Key B. Any single known key across all sectors is a sufficient starting point.

4.5.2 Running Nested on the Chameleon Ultra

The mechanism: the MFRC522 authenticates to the known sector using the known key, establishing a live Crypto1 session. While the session is running, the MFRC522 issues a re-authentication request targeting a different sector — one with an unknown key. The card returns its nonce for the second authentication encrypted with the running Crypto1 session state. Because the Crypto1 PRNG advances at a rate tied to the number of field-clock cycles since power-on, and because the timing of the re-authentication is under the attacker’s control, the PRNG state at the second authentication is predictable. The nRF52840 runs offline key-recovery against the encrypted nonce, recovering the unknown sector’s key without any further card interaction.

This process is repeated for each unknown sector, fanning out from the initial known key across the full sector map. Time per sector is typically a few seconds; recovery of all 16 sectors on a MIFARE Classic 1K with one known key completes in minutes in favorable conditions. The ChameleonUltra CLI command follows the hf mf nested form; the GUI surfaces the operation through the MIFARE Classic attack panel. As with DarkSide, consult the current CLI reference for the exact argument syntax, as the nested attack command was confirmed implemented in the firmware’s current active state.

4.6 StaticNested attack

StaticNested is a variant of the Nested attack targeting the subset of MIFARE Classic cards whose PRNG seed is fixed at every power cycle — the same nonce value appears regardless of when the authentication occurs. The firmware implements this as MF1_STATIC_NESTED_ACQUIRE (added in firmware v2.0.0) with the “PRNG(2NT Fast Decrypt)” methodology noted in the RRG technical whitepaper.

4.6.1 When to use StaticNested vs Nested

Detecting a static PRNG is straightforward: present the card to the MFRC522, power-cycle the card (briefly remove it from the field), re-authenticate to the same sector, and compare the nonce values. If nT is the same across two authentications separated by a power cycle, the card has a static PRNG and StaticNested is the appropriate attack. If nT varies with timing, the card uses a dynamic PRNG and standard Nested applies.

Static PRNG behavior occurs in some OEM card manufacturing environments where the card is programmed in a controlled-timing environment — every card leaves the factory having seen identical clock counts since power-on, so the PRNG is in the same state at every subsequent first authentication. The condition is more common in older or cheaper card stock; NXP’s reference silicon does not exhibit it, but some Chinese clone manufacturers produce it.

StaticNested is faster than standard Nested because the fixed nonce eliminates the timing-measurement dimension of the PRNG state search. The ChameleonUltra firmware handles the detection and algorithm selection transparently in its attack flow; the operator does not need to manually identify which variant is appropriate.

4.6.2 Running StaticNested on the Chameleon Ultra

The MFRC522-based data-collection workflow is the same as standard Nested: the device acts as a reader, authenticates to a known sector, and issues re-authentication requests for unknown sectors. The difference is in the recovery computation on the nRF52840 side, which uses the 2NT fast-decryption method made possible by the predictable nonce. The ChameleonUltra firmware routes between Nested and StaticNested automatically based on whether the detected nonces are consistent across power cycles; the operator initiates a single “nested attack” sequence and the firmware handles the variant selection. The StaticNested path will complete faster than the standard Nested path when the card qualifies.

4.7 HardNested attack — hardened PRNG cards

HardNested was introduced academically by Carlo Meijer and Roel Verdult in “Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards” (ACM Conference on Computer and Communications Security, CCS 2015). The Proxmark3 implementation was produced by community developer pwpiwi (github.com/pwpiwi/proxmark3, hard_nested branch) and subsequently merged into the Iceman firmware. The ChameleonUltra firmware merged a complete HardNested implementation in its v2.1.0 release (September 2025).

4.7.1 The hardened PRNG problem

The target card class for HardNested is MIFARE Classic silicon with a hardened (filtered) PRNG — specifically NXP MIFARE Classic EV1 (SmartMX-based) and MIFARE Plus SL1. In these cards the underlying cipher is still Crypto1 — the 48-bit LFSR and nonlinear filter are unchanged — but the nonces the card produces are no longer exploitable through the timing-predictability mechanism that Nested depends on. NXP’s PRNG hardening removes the statistical biases that DarkSide and standard Nested rely on.

Important — the FM11RF08S is NOT a HardNested target. The Fudan Microelectronics FM11RF08S clone uses a qualitatively different defense: a static encrypted nonce construction (disclosed by Quarkslab in 2024; see Quarkslab blog post and eprint.iacr.org/2024/1275) that defeats all card-only attacks including HardNested. Rather than a hardened random PRNG, the FM11RF08S returns a cryptographically fixed nonce value that cannot be exploited by HardNested’s probabilistic bitwise analysis. The correct attack is the static-encrypted-nonce backdoor key recovery (senested, PR #263 in the ChameleonUltra firmware): the Quarkslab disclosure revealed a universal backdoor key (A396EFA4E24F) embedded in the FM11RF08S silicon that the firmware’s senested command recovers. This is a separate firmware code path from HardNested.

HardNested compensates through a different analytical approach: it performs probabilistic bitwise analysis of encrypted nonce pairs across multiple authentication exchanges. By collecting encrypted nonces from many re-authentication attempts against an unknown sector (using a known key in another sector as the starting point), and by exploiting the LFSR’s inherent linearity to relate successive cipher states, the attack builds large candidate-state tables and sieves them against further observations. The search is more exhaustive than Nested and requires substantially more computation and memory, but it reliably recovers Crypto1 keys from hardened PRNG cards.

One known key is still required as the starting point — HardNested is not a zero-knowledge attack. If no known key is available, DarkSide (against unhardened sectors) or a default-key pass is the prerequisite.

4.7.2 Running HardNested on the Chameleon Ultra

HardNested is a fully implemented feature in the ChameleonUltra firmware as of v2.1.0 (September 2025), confirmed by the release notes (“complete hardnested attack implementation” merged via PR #254). The CLI follows the hf mf hardnested form with the target block and known key as arguments; the GUI surfaces the operation through the MIFARE Classic attack panel.

The computational constraint is real and worth stating plainly: the nRF52840 runs at 64 MHz with a Cortex-M4F core. HardNested’s table-building and sieving operations are compute-intensive; they run significantly faster on a modern laptop CPU (3+ GHz, multiple cores) or on the Proxmark3 RDV4 tethered to a laptop, where the computation offloads to the host. No confirmed per-sector timing benchmarks comparing ChameleonUltra HardNested runtime against the Proxmark3 Iceman client have been published in accessible public sources as of 2026-06. Community observations — from the Dangerous Things forum and Proxmark.org threads covering comparable embedded platforms — consistently indicate that HardNested on an embedded 64 MHz MCU runs on the order of 30–90 minutes per sector for hardened EV1 (SmartMX) or MIFARE Plus SL1 targets, versus 5–20 minutes per sector on a modern laptop via Proxmark3. These figures are community estimates, not confirmed benchmarks, and should be treated as order-of-magnitude guidance rather than guaranteed times.

4.7.3 When to hand off to Proxmark3

The decision point is straightforward: if a field engagement requires HardNested against multiple sectors on a high-security card, and completing the attack in the time available on the ChameleonUltra is impractical, the Proxmark3 RDV4 with the Iceman firmware (hf mf hardnested) is the appropriate escalation. The Proxmark3 offloads the HardNested computation to the tethered laptop, where the available CPU cores and RAM are orders of magnitude beyond what the nRF52840 provides.

The operational workflow for the handoff: use the ChameleonUltra’s MFRC522 reader to obtain the initial known key (via dictionary or DarkSide if the card has unhardened sectors), capture the card dump insofar as possible, then bring the dump and the target card to a Proxmark3 session. The Proxmark3 can ingest the ChameleonUltra’s recovered keys and proceed with HardNested against the remaining sectors. Vol 8 §7 details the Chameleon Ultra ↔ Proxmark3 handoff workflow.

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

MFKEY32 v2 addresses the scenario where the target card is inaccessible for direct MFRC522 probing but the card’s legitimate reader can be reached — either by holding the Chameleon Ultra near the reader while the cardholder taps, or by the operator presenting an emulated card with the target’s UID to trigger the reader’s authentication attempt. Rather than attacking the card, MFKEY32 v2 recovers the key that the reader uses. In most access-control deployments, the reader and all enrolled cards share the same sector keys, so the reader-key is the card-key.

4.8.1 The sniff-first workflow

The fundamental distinction from DarkSide/Nested: in the MFKEY32 v2 workflow, the Chameleon Ultra is acting as an emulated card (using the nRF52840 NFC-A block) rather than as a reader (MFRC522 probing a target card). The target card’s physical presence is not required. What is required is the card’s UID — obtainable from a brief MFRC522 read of the card during an earlier access, or from the card’s visible UID field.

The Chameleon Ultra, loaded in detection mode with an HF slot configured to the target card’s UID, logs each reader authentication attempt against it. The authentication exchange — the reader’s nonce (nR) and encrypted response (aR) against the card’s nonce (nT) — is the raw material for MFKEY32 v2 key recovery. Two independent (nT, nR, aR) triples from two separate authentication attempts against the same sector and key are sufficient for MFKEY32 v2 to recover the 48-bit sector key.

The “v2” in MFKEY32 v2 addresses a practical limitation of the original MFKEY32: v1 required the two captured nonce pairs to come from consecutive authentication attempts within the same reader session, because the key search depended on the timing relationship between them. MFKEY32 v2 relaxes this constraint — the two authentication attempts may come from separate, non-consecutive reader interactions, even separated by hours or different visits. This makes the attack feasible in real-world conditions where the operator can only trigger the reader once per approach, collecting the second nonce on a subsequent pass.

4.8.2 Running MFKEY32 v2 on the Chameleon Ultra

The ChameleonUltraGUI workflow, confirmed from public documentation:

1. Read target card UID: Position the target card against the Ultra’s HF coil; the MFRC522 reads the UID during ISO 14443A anticollision (no authentication required — UID is transmitted in clear per the protocol).
2. Configure HF slot: Load the UID into an HF slot configured as MIFARE Classic 1K (or 4K if the target is a 4K card); leave sector keys empty.
3. Enable Detection Mode: In ChameleonUltraGUI, enable Detection Mode on the configured slot. The device will log reader authentication attempts without responding to them successfully (authentication fails, but the nonce exchange is captured).
4. Collect nonces: Present the Chameleon Ultra to the legitimate reader — the reader attempts authentication, the exchange is logged. The GUI’s “Collect nonces (Mfkey32)” function manages this; after nonces are captured, it surfaces a “Recover Keys from N nonces” action.
5. Run MFKEY32 v2 recovery: The ChameleonUltraGUI runs the MFKEY32 v2 computation against the logged nonces, returning the recovered sector keys. Keys appear in the “Mifare Keys History” view.
6. Read the target card: Using the recovered keys, re-present the target card to the Ultra’s MFRC522 reader and authenticate to read the full sector dump.

The exact GUI menu paths and button labels evolve between ChameleonUltraGUI releases; the release history is at github.com/GameTec-live/ChameleonUltraGUI/releases.

4.8.3 MFKEY32 v2 vs the original MFKEY32

Both versions recover the Crypto1 key from captured (nT, nR, aR) triples using the same underlying XOR-and-LFSR-rollback cryptanalysis. The key search works by recovering the keystream used to encrypt the reader’s responses, then rolling the LFSR state backward to find the 48-bit key that produced that keystream.

The v1/v2 distinction is purely in nonce-collection constraints: v1 requires the two captured triples to come from consecutive authentications within the same uninterrupted reader session; v2 relaxes this to any two independently collected triples for the same sector and key type, regardless of when they were captured. In field conditions where the operator can only trigger the reader once before losing access — one tap, then exit — v2 is the enabling technology. The cryptographic strength of the recovery is equivalent between versions; the practical improvement is entirely in the operational flexibility of when nonces can be collected.

4.9 UID bruteforcing

Access-control systems that grant entry based solely on card UID — with no Crypto1 or AES authentication challenge — are vulnerable to UID enumeration: iterate UIDs until the reader grants access. This deployment posture is uncommon in any installation where a security-conscious integrator configured the system, but it does occur in commodity-tier LF and HF installations where the panel validates a UID range rather than an authenticated credential.

4.9.1 Use case and preconditions

The preconditions are constraining: the reader must perform no cryptographic challenge, the panel must pass the UID directly to an access-grant comparison, and the attacker must have some way to detect success (door opens, reader LED changes state, relay clicks). Without feedback, brute-forcing a 32-bit UID space blindly — even in a small subset — is operationally impractical as a field attack.

In practice, UID-only access control is most commonly encountered in very low-cost EM410x (LF) deployments and in older MIFARE Classic installations where the integrator disabled or never configured the Crypto1 authentication layer. For MIFARE Classic specifically, a reader that only checks UID is passing the card’s sector-0 block-0 UID without authenticating — observable because the reader interaction completes in under 5 ms rather than the several hundred milliseconds of a Crypto1 authentication round trip.

4.9.2 Operational limits

For LF UID brute-force: the ChameleonUltra firmware whitepaper documents a “Brute Force” capability for EM410x ID cards, but notes this as “Not yet implemented” at the application layer as of the whitepaper’s last substantive update. Check current firmware release notes for implementation status.

For HF UID brute-force: the ChameleonUltra firmware does not implement a dedicated automated HF UID enumeration mode in any confirmed current release as of 2026-06. The practical approach for HF UID-only targets is the slot-cycling workflow: the operator loads candidate UIDs across the eight HF slots and cycles them manually against the reader. For a narrowed search space — facility-code-constrained MIFARE Classic UIDs, or a known UID range from an enrollment database — slot cycling with batched candidate loads covers the relevant UID range systematically, though it requires operator presence at the reader for each attempt.

For a 32-bit MIFARE Classic UID space (~4.3 billion values), exhaustive automated enumeration is impractical at any realistic per-attempt reader interaction rate. Targeted narrowing (known facility code, known UID-number range from a partially visible card, or social-engineering the enrollment database) is the appropriate analytical approach, not automated brute force.

4.10 MIFARE Ultralight and NTAG 210–216

MIFARE Ultralight and NTAG are the HF card families without Crypto1. Their “security” model — where any exists at all — consists of OTP (One-Time Programmable) lock bits that prevent write-modification after manufacture, and a 32-bit password mechanism (PWD + PACK) on the EV1 and NTAG variants that can gate read or write access. These are not cryptographically strong protections: the 32-bit PWD is transmitted over the air in cleartext during authentication and is vulnerable to sniffed-transaction recovery. The Chameleon Ultra’s emulation of these families is primarily for presenting legitimate pre-loaded credentials, not for cryptographic attack.

Full support for NTAG 21x (210–216) is confirmed across hardware, software, and application layers in the ChameleonUltra firmware whitepaper. Ultralight support was added in the v2.1.0 release (September 2025) alongside the shadow-mode functionality.

4.10.1 Ultralight — emulation basics

MIFARE Ultralight (MF0ICU1) is the minimal-overhead contactless memory card: 64 bytes across 16 pages of 4 bytes each, no authentication, no Crypto1. The Chameleon Ultra emulates an Ultralight slot by configuring the nRF52840 NFC-A block to respond to ISO 14443A initialization (ATQA 00 44, SAK 00) and then to handle READ and WRITE page-level commands per the Ultralight protocol. The slot stores the 64-byte page dump; NDEF records, event-ticket payload, or transit-pass content stored in pages 4–15 is replayed verbatim.

The critical property for emulation fidelity: the UID bytes are split across pages 0 and 1 (bytes 0–2 in page 0, bytes 3–6 in page 1), not in a contiguous 7-byte field. An Ultralight slot dump must preserve this layout exactly. Dumps exported from a Proxmark3 (hf mfu dump) or from an NFC-reading phone app that captures the raw page contents will have the correct layout; manually constructed dumps must respect the page-split UID structure.

4.10.2 NTAG variants in scope

NTAG 210–216 span a memory range from 48 bytes to 888 bytes of user-accessible data. All use the ISO 14443A NFC Forum Type 2 tag layer (ATQA 00 44, SAK 00), the same page structure as Ultralight EV1, and the 32-bit PWD/PACK password mechanism. The Chameleon Ultra emulates each variant with the correct page count and command set:

Table 3 — NTAG 210–216 span a memory range from 48 bytes to 888 bytes of user-accessible data. All use the ISO 14443A NFC Forum Type 2 tag layer (ATQA 00 44, SAK 00), the same page structure as Ultralight EV1, and the 32-bit PWD/PACK password mechanism. The Chameleon Ultra emulates each variant with the correct page count and command set

NTAG variant	User pages	User memory	Password-protected pages
NTAG 210	12 pages	48 bytes	Optional; AUTH0-configurable boundary
NTAG 212	32 pages	128 bytes	Optional
NTAG 213	36 pages	144 bytes	Optional
NTAG 215	126 pages	504 bytes	Optional
NTAG 216	222 pages	888 bytes	Optional

When emulating a password-protected NTAG slot, the ChameleonUltra’s configured PWD and PACK values are returned on a successful PWD_AUTH command. If the slot is configured without a password (or with the NTAG’s factory-default 00 00 00 00 password), the emulated card returns the AUTH0 response accordingly. Readers that rely on a correct PWD_AUTH exchange before granting access will require the correct password to be loaded into the slot; readers that perform only UID-level validation will pass without PWD_AUTH. Emulation operates at 106 kbit/s throughout.

4.11 MIFARE DESFire EV1/EV2 — emulation scope

MIFARE DESFire uses a filesystem-based application structure on top of full ISO 14443A-4 (T=CL) framing, with three-pass challenge-response authentication based on 3DES (EV1) or AES-128 (EV2/EV3). No public cryptanalytic attack recovers DESFire application keys without the keys themselves; the Crypto1 attack suite is completely inapplicable. The Chameleon Ultra’s DESFire support is consequently limited to emulation at the UID and protocol-header layer, not at the application-authentication layer.

The ChameleonUltra firmware whitepaper confirms DESFire EV1/EV2 support at “Low rate” (106 kbit/s) across hardware, software, and application layers, with the limitation that high-rate communication (212/424/848 kBd, which DESFire EV2 supports in full deployments) is not implemented.

4.11.1 What DESFire emulation covers

The Chameleon Ultra’s DESFire emulation replicates the UID, ATQA (typically 03 44), and SAK (0x20, indicating ISO 14443A-4 compliance), and can return an ATS (Answer to Select) response with a basic historical-bytes field. This is sufficient for UID-only readers: access-control systems where the panel compares only the card’s UID against an enrolled-UID database, without proceeding to the DESFire application authentication exchange. These installations are common at physical security levels that use DESFire cards for their anti-cloning properties but implement only UID checking in the panel software — a deployment posture that defeats the anti-cloning benefit, but exists widely in practice.

Full DESFire application-layer emulation — including the AES-128 or 3DES mutual authentication, the application directory listing, and encrypted file reads — is not supported. A reader that completes the ISO 14443A-4 SELECT and then issues DESFire SELECT APPLICATION / AUTHENTICATE APDUs will receive no valid AES-authenticated response from the emulated slot; the reader will reject the emulated card after the initial UID/ATS exchange. No available DESFire key-recovery technique makes this feasible without the application keys.

4.11.2 DESFire and the Proxmark3 handoff

The Proxmark3 RDV4 with the Iceman firmware implements a substantially more complete DESFire command set: application directory enumeration, file structure listing, and the full mutual authentication sequence (for applications where the key is known). For engagements where DESFire application keys are in scope — obtained through other means such as a reader hardware compromise, an HSM export, or a side-channel acquisition — the Proxmark3 is the correct tool for verifying key correctness and reading application data. The Chameleon Ultra’s role in a DESFire engagement is limited to UID emulation; everything else routes to the Proxmark3. Vol 8 §4 covers this handoff.

4.12 MIFARE Plus — emulation scope

MIFARE Plus is NXP’s backward-compatible successor to MIFARE Classic, designed to allow phased migration from Crypto1 to AES-128 without replacing all installed readers simultaneously. It operates in one of three security levels, and its vulnerability to the Chameleon Ultra’s attack suite depends entirely on which security level the deployed cards are running.

The firmware whitepaper confirms MIFARE Plus support at “Low rate” (106 kbit/s) — the same constraint as DESFire.

4.12.1 Security Level 1 — Classic compatibility mode

A MIFARE Plus card in SL1 is operationally indistinguishable from MIFARE Classic 1K or 4K at the protocol layer: same memory layout (16 sectors × 4 blocks for 1K-equivalent, 40 sectors for 4K-equivalent), same Crypto1 cipher, same three-pass authentication, same sector-trailer key structure. The SAK and ATQA for SL1 match the Classic equivalents. The full Chameleon Ultra Crypto1 attack suite — DarkSide, Nested, StaticNested, HardNested, MFKEY32 v2 — applies to SL1 cards without modification.

A significant fraction of deployed “MIFARE Plus” cards encountered in the field remain in SL1 because the migration to SL2 or SL3 requires injecting the AES master key and performing a one-time security-level upgrade that many system integrators have not executed. These cards are as vulnerable as MIFARE Classic 1K/4K.

4.12.2 Security Levels 2 and 3

SL2 is a transitional mode: AES-128 is used for mutual authentication, but the data transport layer still uses Crypto1. SL3 is full AES-128 end-to-end — both authentication and data. In both modes, the AES keys are unknown to the Chameleon Ultra, and no public cryptanalytic attack recovers them. The Crypto1 attack suite does not apply.

Emulation of SL2/SL3 cards is at the UID layer only: the Chameleon Ultra can reproduce the card’s UID and ATQA/SAK for readers that perform only UID-level verification. Readers that proceed to the AES mutual authentication exchange will receive no valid response; they will reject the emulated card. For SL3 engagements where application keys are available from other sources, the Proxmark3 RDV4 with the Iceman firmware provides the more complete AES command set needed for authenticated access. No public attack recovers MIFARE Plus SL3 keys without the AES master key.