Chameleon Ultra — Card Stock, Magic Cards, and Physical Clone Interplay

---

10.1 Emulation vs physical clone — the strategic choice

The Chameleon Ultra’s core value proposition is emulation: all eight HF and eight LF slots hold software-resident card profiles that the device presents to readers without consuming a physical blank or leaving a physical artifact behind. For the majority of access-control audit scenarios this is operationally sufficient — the emulated credential either defeats the reader or it does not, the result is logged, and the operator moves on. No blank cards change hands; the credential data lives in the nRF52840’s flash and can be wiped in seconds.

Physical blank cards enter the workflow when three conditions diverge from that clean picture. First, some readers detect emulation — through anti-timing checks, rolling-UID enforcement, or electrical signal characteristics that differ from a genuine passive card. Second, some operational scenarios require leaving a working credential behind: a red-team engagement where the client wants to demonstrate the risk of a cloned credential in an adversary’s pocket, not just in a penetration tester’s device. Third, some physical constraints (LF coupling distance, reader anti-coupling housing) make close-proximity emulation impractical at the required range.

The decision tree is: start with emulation. If the emulated slot defeats the target reader in testing, physical blanks are unnecessary. If the reader rejects the emulation or the operational requirement mandates a physical clone, select the blank type whose write mechanism and detectability profile match the engagement requirement.

Cross-reference: the iCopy-X series Vol 9 covers the full blank-card ecosystem at full depth — all four MIFARE Magic generations, iCLASS blanks, the Lab401 vs AliExpress decision in detail, and the complete card-format-to-blank decision tree. This volume is scoped to the Chameleon Ultra’s specific write path: how the Ultra, in reader mode via its MFRC522, programs each HF magic blank family; and how the nRF52840 LF path programs T5577 blanks. The iCopy-X Vol 9 decision table (source card → recommended blank type) applies here unchanged.

---

10.2 When the Chameleon Ultra obviates the need for blanks

The Ultra’s MFRC522-backed HF emulation is transparent to the vast majority of installed 13.56 MHz access-control readers in commercial and enterprise deployments. The nRF52840’s NFC-A hardware faithfully reproduces the ISO 14443A anticollision sequence (REQA/ATQA/SELECT/SAK), and the emulated MIFARE Classic Crypto1 session exactly mirrors what a genuine card would produce once sector keys are loaded (see Vol 4). Readers that perform UID verification, Crypto1 authentication, or both — without additional physical-layer checks — cannot distinguish the Chameleon Ultra’s emulation output from a physical card at the protocol level.

Scenarios where physical blanks are not needed:

• Standard ISO 14443A readers (MIFARE Classic 1K or 4K credential): Readers that perform UID verification and/or Crypto1 sector authentication. This covers the large majority of HID-manufactured MIFARE Classic readers, generic access-control readers, and most building-entrance systems programmed before approximately 2022.
• EM4100/EM410x LF readers: Standard 125 kHz readers that verify the EM4100 40-bit ID in clear. The Ultra’s nRF52840 LF path reproduces the Manchester-encoded ASK signal with the correct timing. No T5577 blank is required unless the reader rejects the emulated signal.
• HID Prox H10301 (26-bit, standard): Readers that verify the 26-bit facility code and card number over FSK. The Ultra’s HID Prox emulation covers the standard case; see Vol 5 §4.3 for the known 6-byte RAW HID format issue (#325).
• Multi-slot carry: Any scenario where the operator needs multiple different credentials simultaneously. The Ultra’s eight HF + eight LF slots eliminate the need for a wallet of blank cards by carrying multiple pre-loaded profiles in one device.
• Opportunistic field capture: The Ultra’s MFRC522 reads and recovers keys in-place; an emulated slot can be loaded immediately after capture and tested against the same reader in the same session, with no blank required if the emulation succeeds.

---

10.3 When a physical blank is still required

Physical blanks are required in the following scenarios, each representing a case where the emulation layer is detectable, impractical, or insufficient for the engagement goal.

Anti-emulation timing readers. A small population of access-control readers — typically newer enterprise installations or government security systems — perform electrical or protocol timing checks that distinguish a genuine card’s passive field response from the nRF52840’s active NFC-A load-modulation output. The symptom is consistent rejection of the emulated slot by a specific reader model that a Proxmark3 or genuine card passes. A correctly written Magic Gen2 or Gen3 blank passes these readers because the write is applied to a genuinely passive card whose RF characteristics are native rather than synthesized.

Rolling-UID installations. Deployments that enforce UID uniqueness across consecutive presentations — blocking any static UID that appears in two successive field events — reject static-UID emulation. No current Chameleon Ultra firmware release reproduces rolling UIDs; the RRG roadmap notes this as a future capability. Until implemented, rolling-UID readers require a genuine card or a physical clone on a magic blank.

Leaving a credential behind. Red-team engagements where the deliverable is a functional cloned credential in the client’s possession — not just a field test of emulation — require a physical blank. The blank card is the artifact the client uses to demonstrate the risk to their security team. The Chameleon Ultra reads and recovers the keys; the blank card is the deliverable.

Long-duration or unattended credential use. Any scenario where the cloned credential must be usable without a Chameleon Ultra present — a guard badge that must work throughout a shift, a building key left in an asset rack — requires a physical clone. The Ultra can emulate on-demand but cannot be left unattended in a door frame.

HID Prox emulation fallback. As noted in Vol 5 §4.3, the known 6-byte RAW HID Prox format issue (#325, open as of 2026-06) causes some HID Prox readers to detect the LF signal but not grant access. Writing the credential to a T5577 blank via the Ultra’s LF write path is the reliable fallback for readers affected by this bug.

---

10.4 Magic Gen1a — UID-writable MIFARE Classic blanks

Gen1a cards (marketed as “UID-changeable v1,” “Chinese Magic Card v1,” or simply “Gen1”) are the oldest member of the MIFARE Magic ecosystem. Their defining characteristic is a two-step proprietary wakeup sequence that gates all block-0 write access, making Gen1a both the easiest generation to program and the most straightforwardly detectable.

10.4.1 The Gen1a backdoor mechanism

Gen1a’s block-0 write mechanism operates outside the normal ISO 14443A / MIFARE Classic protocol. After a standard anticollision and select exchange, the operator sends two proprietary commands before any write:

1. WUPC1 — command byte 40h, sent as a 7-bit frame (the notation 40(7) in community documentation indicates this non-standard framing). Genuine MIFARE Classic cards do not respond to this command; a Gen1a card acknowledges it with a single-byte response.
2. WUPC2 — command byte 43h, sent as a standard 8-bit frame. After this, the card enters an unlocked state.

After the 40(7) / 43h sequence, all blocks — including block 0 (the manufacturer block carrying the UID, BCC, and ATQA/SAK) — are accessible via standard MIFARE commands:

• Read any block: 30h <block> + CRC
• Write any block: A0h <block> + CRC → 16-byte payload + CRC

The operator writes the target UID, BCC (XOR of the four UID bytes), and remaining block-0 content with the standard MIFARE write command after unlock. Gen1a cards play block-0 data blindly — they do not auto-correct the BCC byte or the SAK. The operator must supply a valid BCC or the resulting card will fail anticollision on readers that verify the BCC field. Gen1a supports 4-byte UIDs only (per the Proxmark3 RRG magic_cards_notes.md); 7-byte UID variants of Gen1a do not exist.

10.4.2 Detectability

Gen1a detectability is high. The 40(7) wakeup is the detection probe: any reader firmware that sends this 7-bit command to a presented card and checks for a response identifies Gen1a unambiguously — genuine MIFARE Classic cards silently ignore 40(7), while Gen1a cards acknowledge it. Reader manufacturers began implementing this check from approximately 2018 onward. Modern enterprise and government access-control readers that have received firmware updates since 2018 can be expected to detect and reject Gen1a clones.

Gen1a remains appropriate for: lab bench work where detectability is irrelevant; training environments where card volume and low per-unit cost dominate; legacy installations whose reader firmware predates the detection implementation; and scenarios where the Gen1a blank is being programmed as an intermediate step (e.g., writing a dump for transport to another tool) rather than for direct field presentation.

10.4.3 Chameleon Ultra write path

The Chameleon Ultra writes to Gen1a blanks via the MFRC522 in reader mode. The MFRC522 drives the 13.56 MHz field; the nRF52840 orchestrates the backdoor sequence over SPI. The CLI path (per MTools BLE documentation at docs.mtoolstec.com):

hw mode -r
hf 14a raw -k -b 7 -d 40           # WUPC1 — 7-bit magic wakeup
hf 14a raw -k -d 43                # WUPC2 — unlock
hf 14a raw -c -k -cc -d A000       # write command for block 0
hf 14a raw -c -cc -d <32-hex-bytes-block0-data>   # 16-byte payload + CRC

The -b 7 flag specifies 7-bit framing for WUPC1. ChameleonUltraGUI and the MTools BLE App expose Gen1a write as a named “Write Gen1A dump” operation that handles BCC calculation and CRC generation automatically.

The Ultra also supports emulating a Gen1a card (responding to the backdoor from an external reader). The slot emulator in ChameleonUltraGUI includes a “Gen1A Magic Mode” toggle that causes the active slot to respond to the 40(7) / 43h sequence — enabling an external Proxmark3 in hf mf cload mode, or another reader-mode tool, to write a dump directly into the Chameleon’s emulation memory via the Gen1a backdoor. This is the emulator-side complement to the reader-mode write described above.

---

10.5 Magic Gen2 (CUID) — direct block-0 write, no backdoor

Gen2 cards (sold as “CUID,” “UID-changeable v2,” or “Direct Write”) address Gen1a’s detectability problem by eliminating the wakeup sequence entirely. Block 0 is writable via a standard MIFARE write command — no 40(7), no 43h. The card accepts a write to block 0 that a genuine MIFARE Classic would reject with a NAK error.

10.5.1 Write mechanism

The write path to block 0 on a Gen2 card is a two-step standard ISO 14443A / MIFARE exchange:

1. Standard anticollision, select (and optional authentication if the sector key is required by the card’s ACL).
2. Standard MIFARE write command: A0h 00h + CRC (write block 0), followed by the 16-byte block-0 payload + CRC.

No special unlock is required. In Proxmark3 tooling this is expressed as hf mf wrbl -b 0 --force, where --force overrides the tool’s default block-0 write guard. ChameleonUltraGUI exposes the equivalent through its “Write HF card” dialog with “Gen2 (Default)” as the default magic card type. The CLI equivalent uses the same standard write-to-block-0 path with the MFRC522 acting as the reader.

Gen2 supports both 4-byte and 7-byte UIDs (per the Proxmark3 RRG magic_cards_notes.md). Batch-level behavior varies: some Gen2 batches auto-correct the BCC byte on write; others play block-0 data blindly. Running hf mf info or hf 14a info against a sample card confirms which behavior the batch exhibits. If the batch plays block-0 blindly, the operator must supply a valid BCC in the written data.

10.5.2 Detectability

Gen2 detectability is lower than Gen1a but is not zero. A hardened reader can probe for Gen2 via:

• Write probe to block 0: A reader that authenticates with known keys (its own enrolled key set) and then issues a write command to block 0 can distinguish Gen2 (write acknowledged) from genuine MIFARE Classic (write rejected). This probe requires the reader to hold the enrolled sector keys and is only practical in “authorized environment” hardening deployments, not in standard gate readers.
• Nonce pattern analysis: Some Gen2 batches exhibit weak or static PRNGs. Performing back-to-back authentication requests and observing nonce reuse identifies the card as non-genuine. This requires multiple authentication rounds on a reader configured to run them.
• Manufacturer byte check: Genuine NXP MIFARE Classic cards embed specific byte patterns in the block-0 manufacturer bytes (bytes 8–15 of the block; in a 4-byte-UID layout, byte 4 = BCC, byte 5 = SAK, bytes 6–7 = ATQA, bytes 8–15 = manufacturer data). Gen2 batches vary in whether they reproduce these correctly; batch-dependent inconsistency creates a detectable signature for readers configured to validate it.

In practice, deployed gate readers in commercial installations do not implement any of these probes. Gen2 passes standard installed readers as a genuine MIFARE Classic and is not detected in typical access-control deployments as of 2026. It is the appropriate default choice for engagements where Gen1a detection is a concern but highest-stealth Gen3 or Gen4 is not required.

10.5.3 Chameleon Ultra write path

The Chameleon Ultra writes to Gen2 blanks via the MFRC522 in reader mode using standard MIFARE write commands. ChameleonUltraGUI’s “Write HF card” dialog selects Gen2 as the default magic type and writes the loaded dump (UID, ATQA, SAK, and all sector data). The slot emulator also supports a “Gen2 Magic Mode” toggle that allows an external reader-mode tool to write block 0 to the Chameleon’s active slot as if it were a Gen2 blank — the emulator-side complement to the reader-mode write path.

---

10.6 Magic Gen3 and Gen4/UMC — the advanced HF magic card generations

Generations 3 and 4 represent the current leading edge of the Magic card ecosystem. Both offer improved anti-detection profiles relative to Gen1a and Gen2; they differ in write mechanism and the degree of card-level configurability available to the operator.

10.6.1 Magic Gen3 — APDU-based block-0 write

Gen3 cards (marketed as “UID-changeable v3,” “Magic Card Gen3,” or “APDU magic card”) use ISO/IEC 7816-4 Application Protocol Data Unit (APDU) commands to write block 0 and change the UID. This is a different mechanism from Gen1a (proprietary raw wakeup frames) and Gen2 (standard MIFARE write command). The card’s ISO 14443A layer is standard — it responds to REQA, anticollision, and SELECT identically to a genuine MIFARE Classic — but it accepts a set of proprietary APDUs on top of that standard transport.

Gen3 APDU command set (per Proxmark3 RRG magic_cards_notes.md and mrnewpan Notes-on-Magic-Cards repository at github.com/mrnewpan/Notes-on-Magic-Cards-aka-UID-changeable):

Table 1 — Gen3 APDU command set (per Proxmark3 RRG magiccardsnotes.md and mrnewpan Notes-on-Magic-Cards repository at github.com/mrnewpan/Notes-on-Magic-Cards-aka-UID-changeable)

APDU bytes	Lc	Data	Function
90 F0 CC CC	10h (16 dec)	16-byte block 0	Write full block 0 (ATQA/SAK auto-corrected; BCC auto-corrected for 4-byte UID)
90 FB CC CC	04h or 07h	4- or 7-byte UID	Change UID only — does not alter the remaining 12 bytes of block 0
90 FD 11 11	00h	—	Permanently lock the card — irreversible

APDU structure follows ISO/IEC 7816-4 framing: CLA = 90h (proprietary class), INS = F0h / FBh / FDh, P1P2 = CC CCh or 11 11h (proprietary), Lc = data length, Data = payload. The APDUs are sent over the normal ISO 14443A transport after a standard anticollision and select; there is no magic wakeup sequence before them.

Key behavioral characteristics:

When writing block 0 via 90 F0 CC CC 10, the card auto-corrects ATQA and SAK to fixed values and auto-corrects the BCC byte for 4-byte UIDs. This means Gen3 block-0 writes cannot arbitrarily configure the ATQA or SAK — the card overrides them with its built-in fixed values. This is a limitation relative to Gen4/UMC but simplifies operation: the operator cannot produce an invalid anticollision response by writing an incorrect SAK.

Changing the UID via 90 FB is independent of block-0 content: the UID change does not alter the remaining 12 bytes of block 0, and a block-0 write does not change the UID set via 90 FB. The two operations are logically separate on Gen3.

The permanent lock command (90 FD 11 11 00) makes block 0 read-only permanently. The operator gives up re-cloning capability in exchange for eliminating the card’s APDU-write-probe detectability entirely — after locking, a Gen3 card is analytically indistinguishable from a genuine MIFARE Classic without silicon-level analysis.

Detectability: Gen3 is detectable by readers that send the 90 FB APDU and observe a positive acknowledgment — genuine MIFARE Classic cards do not recognize that APDU and respond with an error; Gen3 cards acknowledge it. However, this detection probe is not implemented in standard installed gate readers as of 2026. Gen3 is significantly harder to detect than Gen1a and somewhat harder than Gen2, making it the appropriate choice for engagements where Gen2’s manufacturer-byte and nonce-pattern gaps are a concern. After permanent lock is applied, detectability drops to near-zero for reader-level probing.

Gen3 supports 4-byte and 7-byte UIDs; 4-byte is the most commonly stocked variant from Lab401 and AliExpress suppliers.

Chameleon Ultra write path for Gen3: The Chameleon Ultra can write to Gen3 blanks. This is confirmed by two sources: (1) the MTools BLE App — a BLE control client for the Chameleon Ultra — explicitly lists Gen3 among its supported magic write targets (“Supported magic card type: Gen1A, Gen2 (Default), Gen3,” per docs.mtoolstec.com/how-to-use-chameleonultra-to-write-mifare-dump); and (2) the Chameleon Ultra CLI’s hf 14a raw command can send arbitrary ISO 14443A frames, including the Gen3 APDU sequences. The write path in reader mode:

hw mode -r
# Write full block 0:
hf 14a raw -s -c -t 2000 90F0CCCC10 <32-hex-bytes-block0>
# OR — change UID only (4-byte example):
hf 14a raw -s -c -t 2000 90FBCCCC04 <8-hex-bytes-4b-uid>
# Lock permanently (irreversible):
hf 14a raw -s -c -t 2000 90FD111100

The -s flag selects the card (performs anticollision first); -c appends CRC; -t 2000 allows 2 seconds for the APDU response. The MFRC522 in reader mode drives the field and transmits the APDU bytes. Command syntax should be verified against the current firmware’s hf 14a raw -h output, as CLI flag naming may change between firmware releases. The Proxmark3 named convenience commands hf mf gen3uid, hf mf gen3blk, and hf mf gen3freeze are Proxmark3-specific wrappers for these same APDU sequences; the Chameleon Ultra achieves the same result via hf 14a raw with the APDUs directly.

ChameleonUltraGUI’s native Gen3 write support in the slot-manager dialog was listed as “Coming soon” in an earlier wiki revision; verify against the current ChameleonUltraGUI release notes at github.com/GameTec-live/ChameleonUltraGUI/releases for the current state. The MTools BLE App path is the confirmed Gen3 write route as of 2026-06.

10.6.2 Gen4 / UMC — fully configurable emulation platform

Gen4 cards (sold as “Ultimate Magic Card,” “UMC,” or “GTU” by Lab401 and other suppliers) are the most advanced Magic variant. Rather than a backdoor write sequence or fixed-ATQA/SAK APDU scheme, Gen4/UMC provides a password-protected configuration channel that allows independent control of ATQA, SAK, ATS (Answer To Select), UID length, shadow mode, and the full block-0 content — parameters that Gen1a, Gen2, and Gen3 do not expose to the operator.

Configuration command structure:

All Gen4/UMC configuration commands share the pattern CF <4-byte password> <operation> <params>. Default password: 00 00 00 00. The operation codes (per Proxmark3 RRG community documentation and mrnewpan Notes-on-Magic-Cards-aka-UID-changeable):

Table 2 — All Gen4/UMC configuration commands share the pattern CF <4-byte password> <operation> <params>. Default password: 00 00 00 00. The operation codes (per Proxmark3 RRG community documentation and mrnewpan Notes-on-Magic-Cards-aka-UID-changeable)

Command	Function
CF <pw> 35 <2b ATQA> <1b SAK>	Configure ATQA and SAK independently
CF <pw> 34 <Lc> <0–16b ATS>	Configure ATS response (or disable)
CF <pw> 68 <00|01|02>	Set UID length: 4 bytes / 7 bytes / 10 bytes
CF <pw> 69 <00|01>	Enable / disable Ultralight emulation mode
CF <pw> 32 <00–03>	Configure shadow mode (see below)
CF <pw> CD <block> <16b>	Backdoor block write (bypasses authentication)
CF <pw> CE <block>	Backdoor block read
CF <pw> F0 <30b config>	Write full 30-byte configuration block in one command
CF <pw> FE <4b new\_pw>	Change the configuration password
CF <pw> C6	Dump current configuration

Shadow mode is unique to Gen4/UMC: writes to the card’s data memory are acknowledged but never committed to non-volatile storage. The card reverts to its configured baseline after every power cycle. This is operationally useful for simulating “read-once” credential behavior or for preventing accidental overwrite of a configured clone during field testing.

Configurability profile: A Gen4/UMC blank can emulate MIFARE Classic 1K, 4K, and Mini; MIFARE Ultralight families; and NTAG series — all from the same physical card, by reconfiguring ATQA/SAK, block 0, and the mode register. The 10-byte UID option covers the full ISO 14443A UID size range (single, double, and triple cascade levels). Configuring a non-default password from the factory 00000000 value makes the configuration channel inaccessible to any probe that relies on the default password, rendering the card analytically indistinguishable from the genuine card it is configured to emulate.

Detectability: Very low once the password has been changed from the factory default. Without the configuration password, no reader-level probe can distinguish a Gen4/UMC from a genuine card. A detection probe that sends CF 00000000 C6 (dump configuration at default password) identifies Gen4/UMC cards that still carry the factory password — a rapidly shrinking population once the operator rotates it. For engagements demanding the highest-stealth physical clone, Gen4/UMC is the appropriate choice.

Chameleon Ultra write path for Gen4/UMC: Lab401 explicitly lists the Chameleon Ultra among the compatible programming tools for their Gen4/UMC product (“Compatible Programming Tools: Proxmark3 / iCopy-XS, Flipper Zero, Android & iOS (via MTools), LibNFC, ChameleonUltra,” per the Lab401 Ultimate Magic Card product page at lab401.com/products/ultimate-magic-card-gen4). The MTools BLE App additionally confirms Gen4 write support (“Write Gen1A, Gen2, Gen3, Gen4 dump to tag with known keys”). The CLI path uses hf 14a raw to issue the CF command sequences. Forgotten Gen4/UMC passwords cannot be recovered — the card is permanently locked in its current state; track passwords in the engagement log.

10.6.3 Generation comparison

Table 3 — 6.3 Generation comparison

Generation	Block-0 write mechanism	UID sizes	ATQA/SAK control	Detectability	Chameleon Ultra write
Gen1a	Proprietary 40(7) + 43h wakeup, then standard MIFARE write	4-byte only	Blind (plays block 0 as written)	High — 40(7) probe	Yes — hf 14a raw; GUI
Gen2 (CUID)	Standard MIFARE write to block 0; no wakeup	4-byte, 7-byte	Blind (plays block 0 as written)	Medium — write probe; nonce analysis	Yes — standard write path; GUI
Gen3 (APDU)	APDU commands (90 F0, 90 FB, 90 FD)	4-byte, 7-byte	Auto-corrected to fixed values	Low–medium — 90 FB APDU probe	Yes — hf 14a raw APDUs; MTools BLE
Gen4/UMC	Password-protected CF commands; shadow mode	4-byte, 7-byte, 10-byte	Fully configurable	Very low (if password changed)	Yes — hf 14a raw CF commands; MTools BLE

---

10.7 T5577 LF blanks — the LF equivalent

The T5577 (Atmel/Microchip ATA5577C) is the LF equivalent of the MIFARE Magic card: a writable blank that can impersonate read-only target credentials at the protocol layer, covering essentially all deployed 125 kHz LF access-control formats from a single card SKU. Vol 3 §6.3 and Vol 5 §5 cover T5577 mechanics in operational depth; this section addresses how the Chameleon Ultra’s T5577 write path fits into the physical clone decision.

10.7.1 T5577 as the universal LF clone target

The ATA5577C’s Block 0 configuration word determines its on-air behavior: which modulation (ASK, FSK, PSK), which sub-carrier ratio, which bit rate, and which frame format the chip presents when interrogated by a 125 kHz reader (per Microchip ATA5577C datasheet DS70005357B). Writing the correct Block 0 configuration and the target credential data into Blocks 1–6 causes the T5577 to present identically to an EM4100, HID Prox 26-bit, Indala, or other LF format at the air interface. The Proxmark3 doc/T5577_Guide.md is the applied reference for the per-protocol configuration words.

The Chameleon Ultra’s LF emulation slots cover EM4100 and HID Prox (the two most common LF formats) for most scenarios. T5577 blanks serve as the fallback in two cases: HID Prox emulation where issue #325 causes reader rejection (Vol 5 §4.3), and engagements where leaving a physical LF credential is the deliverable.

10.7.2 Chameleon Ultra → T5577 write workflow

The write path from the Chameleon Ultra to a T5577 blank uses the nRF52840 LF analog path, not the MFRC522 (which operates exclusively at 13.56 MHz HF). The nRF52840 drives the 125 kHz carrier via PWM and modulates the write commands onto that carrier to program the T5577 blocks.

Workflow:

1. Capture or configure an LF credential: Read the source EM410x or HID Prox fob into a slot via the Ultra’s LF read function, or manually enter the target ID in ChameleonUltraGUI.
2. Place the T5577 blank on the LF antenna face (the secondary PCB, reverse face of the device, not the MFRC522/HF face).
3. Initiate write: In ChameleonUltraGUI, navigate to the slot’s LF settings and select “Write to T5577.” The nRF52840 programs Block 0 with the appropriate configuration word and writes the credential ID into Blocks 1–6.

Reliability caveat: GitHub issue #319 (“125khz LF T5577 not writing,” opened 2025-11-07, open as of 2026-06) documents write-failure conditions in some configurations. This is not a universal failure — many users report successful writes — but the issue is unresolved as of the current tracker status. Verify against github.com/RfidResearchGroup/ChameleonUltra/releases before depending on T5577 write for an engagement; carry a Proxmark3 RDV4 as backup for T5577 write operations where reliability is critical.

10.7.3 T5577 password protection

Block 7 of the ATA5577C optionally stores a 32-bit write-protect password. When active, any write command must be preceded by the correct 32-bit password; an incorrect password causes the T5577 to discard the write and reset to read-only mode. Factory-default T5577 blanks typically ship with password protection disabled. When password-protected T5577s are encountered in the field (some OEM access-control systems ship T5577-backed cards with a vendor-specific password), the Chameleon Ultra’s T5577 password brute-force attack iterates through the 32-bit space. The RRG technical whitepaper lists this attack as hardware ✓ / software ✓ / application layer “not yet implemented” as of the whitepaper’s current revision — verify against the current firmware release before planning an engagement around it. See Vol 5 §5.3 for the full treatment.

---

10.8 Sourcing blank card stock — Lab401, AliExpress quality variance

Blank card sourcing for the Chameleon Ultra operator follows the same calculus as for the iCopy-X operator, covered in detail in the iCopy-X series Vol 9 §6. The summary relevant to the Chameleon Ultra workflow:

10.8.1 Lab401 as the primary vetted supplier

Lab401 is the primary EU/global distributor for the Chameleon Ultra and the most reliable source for Chameleon-validated blank card stock. Their “Genuine” product line:

Table 4 — Lab401 is the primary EU/global distributor for the Chameleon Ultra and the most reliable source for Chameleon-validated blank card stock. Their "Genuine" product line

Blank type	Form factors	Approx retail price	Notes
Gen1a (MIFARE Classic 1K)	Card, keyfob	€1–2/card	Lab bench and legacy-reader use; 4-byte UID only
Gen2 / CUID (1K and 4K)	Card, keyfob	€1.50–2.50/card	Default for most MIFARE Classic cloning
Gen3 (1K and 4K)	Card	€2.50–4/card	Premium-stealth; confirm 1K vs 4K at ordering time
Gen4 / UMC	Card, keyfob	€3–5/card	Highest stealth; fully configurable
T5577	Card, keyfob, wristband	€1–2/card	Universal LF blank; same SKU covers EM4100, HID Prox, Indala

Lab401’s validation against the current Chameleon Ultra firmware is the sourcing advantage: cards listed as Chameleon Ultra compatible have been tested in the current ChameleonUltraGUI and MTools BLE App write workflows. Batch inconsistencies — Gen2 BCC auto-correction behavior, Gen3 APDU acknowledgment patterns, Gen4 shadow-mode behavior — are more common in AliExpress stock.

10.8.2 AliExpress cost versus quality variance

AliExpress pricing is approximately 2–5× lower per card across all Magic generations. The cost savings are real for high-volume lab use, training environments, and any scenario where a few percent card-level failure rate is acceptable. For client-facing engagements, the reliability differential favors Lab401: an AliExpress “Gen3” card that ships as Gen2, or a Gen2 batch with a static PRNG, can produce engagement-visible failures that the Lab401 premium eliminates. AliExpress Gen4/UMC supply is particularly variable; “Ultimate Magic Card” listings may ship Gen2 or Gen3 in different batches.

Pre-test protocol for AliExpress stock (sample 5 cards per 100-card batch before committing to engagement use):

1. Run hf mf info (or hf 14a info in the Chameleon Ultra CLI, or via ChameleonUltraGUI’s card-info scan) — confirm the detected Magic generation matches the listed generation.
2. Write a known UID to block 0 and verify with hf 14a scan that the card responds with the written UID.
3. For Gen2/Gen3 batches: collect 10–20 sequential authentication nonces (enable detection mode, present to a reader 10 times, check hf mf elog) — static-nonce batches are problematic for key-recovery operations.
4. Repeat block-0 write with a different UID and verify — confirms the card is not OTP-locked after first write.

Batches that pass all four tests are operationally equivalent to Lab401 stock for the scenarios they cover.

10.8.3 Minimum engagement kit

For a physical-pentest engagement where HF and LF physical clones may be required:

Table 5 — For a physical-pentest engagement where HF and LF physical clones may be required

Card type	Quantity per expected clone	Rationale
Gen2 blanks (MIFARE Classic 1K)	5–10×	Default; covers most MIFARE Classic targets; failure-margin buffer
Gen3 blanks	5–10×	Stealth-sensitive targets only; omit if Gen2 is adequate
Gen4/UMC	3–5×	Highest-stealth targets; bring only when engagement scope calls for it
T5577 cards	5–10×	Per expected LF clone; higher ratio until issue #319 is resolved
T5577 keyfobs	2–5×	For environments where the target LF credential is a fob form factor

Do not pack Gen4 blanks for standard engagements where Gen2 is adequate — the Gen4 configuration overhead (password management, shadow mode settings, ATQA/SAK configuration) adds complexity that is unnecessary for straightforward MIFARE Classic clone deliverables.