Chameleon Ultra — RFID/NFC Primer

3.1 Why a primer here

This volume exists to make Vols 4 and 5 self-contained for readers arriving directly at the Chameleon Ultra series. A reader picking up Vol 4 (the MIFARE Classic attack suite) or Vol 5 (LF protocol emulation) without prior RFID background would encounter unexplained concepts — anticollision loops, Crypto1 state reuse, Manchester encoding, FSK subcarrier ratios — at exactly the points where the operational detail is densest. This primer establishes the minimum physics and protocol knowledge required to follow that material without having to look anything up mid-chapter.

It is deliberately condensed. The iCopy-X series includes a complete RFID/NFC primer at ../../iCopy-X/02-inputs/volume_sources/vol3.md — a 55 KB treatment of LF and HF physics, the ISO standards landscape, the NFC Forum tag type taxonomy, and the full crypto-strength taxonomy (Category 1 through 4: no-crypto, broken-crypto, AES-grade, asymmetric). Readers who have completed the iCopy-X series, or who already have a working grasp of ISO 14443A, MIFARE Classic Crypto1, and 125 kHz LF fundamentals, can skip directly to Vol 4. What follows is calibrated to the Chameleon Ultra’s specific scope — ISO 14443A HF emulation and attack, and 125 kHz LF emulation — and does not reproduce the iCopy-X primer’s wider coverage of ISO 15693, iCLASS, FeliCa, Legic, or the complete NFC Forum Type taxonomy.

A note on standards references: ISO/IEC 14443 Parts 1–4 are paywalled. The numeric values in this volume are sourced from the public literature, NXP and EM Microelectronic datasheets, the RRG firmware source tree and wiki, and the iCopy-X primer research, which itself cites manufacturer datasheets and the Proxmark3 RRG community knowledge base. Where a value originates from the standard text rather than a datasheet, the iCopy-X primer convention applies: the value is given with a note that the standard is the authoritative source for conformance purposes.

3.2 LF physics — 125 kHz, inductive coupling, modulation schemes

The Chameleon Ultra’s LF capability lives at 125 kHz, the dominant carrier frequency for legacy access-control credentials worldwide. Understanding why LF behaves differently from HF — shorter range, slower data rate, simpler protocol stacks — is prerequisite to understanding both the capabilities and the genuine limitations of the Chameleon Ultra’s nRF52840-driven LF path.

3.2.1 Inductive coupling at 125 kHz

At 125 kHz, the free-space wavelength is approximately 2400 m. Nothing in any realistic operating scenario comes remotely close to that wavelength, which means all energy transfer between reader and card happens in the near field — specifically the magnetic near field of two coupled loop inductors. The reader coil drives an alternating magnetic field; the card coil intersects that field, inducing a voltage that powers the card’s silicon and carries the downlink data. There is no battery on a passive LF tag: the card’s logic runs entirely on energy harvested from the reader’s field, which is why the card must remain within coupling distance throughout a transaction or lose power and reset.

The coupling factor between the two coils falls approximately as 1/r³ in the magnetic near field, where r is the separation between coil centers. Halving the gap multiplies the coupling by roughly eight; doubling it divides by eight. This steep geometric dependence is why LF read range is fundamentally short and highly sensitive to coil alignment. A card held flat and coaxially against a reader coil achieves maximum coupling; the same card held at 45 degrees has roughly half the coupling. In practice, 125 kHz access-control readers installed in door frames are designed to read a card presented flush against the reader face at zero to a few centimeters — that installation geometry, not some deficiency in LF as a standard, is why the range is short.

The Chameleon Ultra’s LF read range reflects its hardware architecture: the nRF52840 drives the LF coil through its own GPIO and PWM peripherals, without the matched filtering, automatic gain control, and amplification chain of a purpose-designed LF reader IC. Community measurements on the Dangerous Things forum report approximately 2 cm for the Ultra’s LF read range against typical fobs (one reviewer recorded “lf ~2cm” against a Flipper Zero reader field). No official LF read range specification has been published by RRG or Lab401 as of 2026-06, and the 2 cm figure is a community data point rather than a validated test. The operational implication is that the Ultra’s LF read capability is practical — adequate for presenting a fob directly to the antenna — but is not lab-grade; the Proxmark3 RDV4, with its dedicated LF analog front end and matched filtering, achieves 5–10 cm under the same conditions. For LF emulation (presenting a credential to an installed reader), the Chameleon Ultra’s range is typically adequate, since installed LF readers are designed to read a card held flush against the reader face at a distance that falls within the Ultra’s coupling window. For LF reading of an unknown fob in the field, the Ultra requires close, stable contact.

3.2.2 Modulation and encoding

A passive LF tag communicates back to the reader by modulating its own load on the reader’s carrier — switching a load resistor across the card coil periodically causes a measurable fluctuation in the current through the reader coil, which the reader’s analog front end detects and demodulates. The Chameleon Ultra’s nRF52840 detects this modulation via a comparator or ADC peripheral tied to the LF antenna receive tap; the demodulation and decoding logic runs in firmware.

Three modulation schemes are used across the LF protocol families the Chameleon Ultra supports:

ASK (Amplitude Shift Keying) — the card switches a load on and off, producing amplitude dips in the carrier. EM410x and PAC/Stanley use ASK. It is the simplest scheme and the easiest to detect, which is part of why EM410x has remained the baseline LF credential format for decades.

FSK (Frequency Shift Keying) — the card’s load switching alternates between two rates corresponding to two sub-carrier frequencies, typically at fc/8 and fc/10 of the 125 kHz carrier (approximately 15.625 kHz and 12.5 kHz). The reader demodulates which sub-carrier frequency is currently dominant to recover the bit stream. HID Prox and Paradox use FSK variants. FSK is more robust to amplitude noise than ASK, which is why it was adopted for the higher-reliability HID Prox standard.

PSK (Phase Shift Keying) — the card modulates the phase of its sub-carrier rather than its amplitude or frequency. Indala uses PSK. Less common than ASK or FSK and somewhat harder to implement in firmware, which partially explains why PSK-based protocol families are at a later firmware implementation stage on the Chameleon Ultra relative to ASK-based ones.

Underneath the modulation scheme is the bit encoding layer — how ones and zeros are represented in the bit stream. Manchester encoding (a transition mid-bit represents a one or zero depending on direction, giving self-clocking behavior) is used by EM410x in its standard mode. Biphase variants are used by HID Prox. NRZ (Non-Return-to-Zero) is used by some older families. The distinction matters for emulation fidelity: the Chameleon Ultra must reproduce not just the carrier modulation depth and frequency but the exact bit-level timing of the target protocol family, or an installed reader will reject the emulated credential.

Vol 5 covers the per-protocol modulation and encoding details for each LF family the Chameleon Ultra handles, including which families are currently implemented at the application layer and which have hardware support pending firmware completion.

3.3 HF physics — 13.56 MHz, near-field coupling, load modulation

The Chameleon Ultra’s HF capability lives at 13.56 MHz, the globally harmonized frequency for proximity contactless cards. The same inductive-coupling physics that governs 125 kHz operation applies here — both bands are near-field magnetic, both use coil-to-coil energy transfer, neither involves far-field radiation at card-reader distances — but the higher carrier frequency enables much faster data rates and more sophisticated protocol stacks on top.

3.3.1 Near-field coupling at 13.56 MHz

At 13.56 MHz, the free-space wavelength is approximately 22 m — still far larger than any realistic reader-card distance. The operation is still magnetically near-field, still 1/r³ falloff, still coaxial alignment sensitive. The HF coil on the Chameleon Ultra is physically smaller than its LF coil (fewer turns, smaller inductance, higher-frequency resonance), which is why the two coils occupy separate PCBs in the three-layer assembly — the HF coil is tuned for 13.56 MHz and the LF coil for 125 kHz, and they are ferrite-isolated to prevent mutual interference (per Vol 2 §5).

The card is still passively powered: a MIFARE Classic card, an NTAG sticker, or a DESFire EV2 fob has no battery. The 13.56 MHz reader field powers the card’s silicon continuously throughout the transaction. The same hold-stable requirement that applies at LF applies here — losing coupling during an authentication handshake resets the card’s state and aborts the transaction.

Why 13.56 MHz instead of 125 kHz for the faster standards? At higher carrier frequency, the available modulation bandwidth scales with the carrier, so faster bit rates are achievable on a given channel. ISO 14443A’s 106 kbit/s baseline data rate would be impossible at 125 kHz with its narrow carrier bandwidth; at 13.56 MHz the modulation bandwidth accommodates 106 kbit/s comfortably, and the standard defines higher rates of 212, 424, and 848 kbit/s for faster card families.

3.3.2 Load modulation and subcarrier

The card-to-reader communication channel at HF uses the same load-modulation principle as LF: the card switches a load across its coil, causing a perturbation in the reader’s carrier that the reader detects. At 13.56 MHz, the standard specifies a subcarrier architecture for this back-channel: the card does not modulate its load directly at the baseband data rate, but at a sub-carrier frequency of fc/16 — that is, 13.56 MHz / 16 = 847.5 kHz (per ISO/IEC 14443-2, the value is specified as fc/16; at fc = 13.56 MHz, the result is 847.5 kHz). The card switches its load at this subcarrier rate, producing sidebands at 13.56 MHz ± 847.5 kHz that the reader’s demodulator detects.

The bit encoding on top of the 847.5 kHz subcarrier is Manchester at the 106 kbit/s baseline data rate. This means each bit period is one full Manchester code element riding on the subcarrier: a 0 is encoded as a transition from high to low at the midpoint of the bit period, a 1 as low to high (or vice versa by convention — the standard defines the specific polarity). The Manchester encoding is self-clocking, which matters because the card’s clock is derived from the reader’s carrier field and must remain synchronized throughout a transaction without a separate clock wire.

For the reader-to-card direction, ISO 14443A uses 100% ASK with modified Miller encoding: the reader briefly turns its carrier off entirely (100% amplitude modulation depth, meaning the carrier drops to zero) at specific instants within each bit period. Modified Miller encoding defines where in the bit period the carrier-off pause occurs for 0s and 1s. The total downlink data rate at baseline is also 106 kbit/s.

The Chameleon Ultra’s MFRC522 handles all of this RF layer mechanics — subcarrier generation, load modulation detection, Miller/Manchester coding — in hardware, with the nRF52840 managing the framing, protocol state machine, and data payloads over SPI. When the Chameleon emulates a card, its nRF52840 NFC-A hardware block takes on the card-side role: it responds to the reader’s 13.56 MHz carrier, demodulates incoming commands, and load-modulates responses back using the fc/16 subcarrier scheme described above. The detail of how the nRF52840’s NFC-A hardware block interfaces to the antenna is in Vol 2 §2.2.

3.4 ISO 14443A — the HF standard the Chameleon cares about most

ISO/IEC 14443 is the air-interface standard for proximity contactless cards at 13.56 MHz. It is the load-bearing standard under every HF card family the Chameleon Ultra supports: MIFARE Classic, MIFARE Ultralight, NTAG, DESFire EV1/EV2, and MIFARE Plus are all ISO 14443A (Type A) implementations. The standard is published in four parts:

• Part 1 (Physical Characteristics) — card dimensions, mechanical durability, UV/X-ray resistance. Not relevant to the Chameleon Ultra’s firmware.
• Part 2 (RF Power and Signal Interface) — the 13.56 MHz carrier, the reader-to-card modulation (100% ASK, modified Miller), the card-to-reader modulation (load modulation, fc/16 subcarrier, Manchester). This is the physical layer the Chameleon Ultra’s NFC-A hardware implements.
• Part 3 (Initialization and Anticollision) — how a reader discovers cards in its field and selects one for a transaction. The REQA/ATQA/SELECT sequence the Chameleon Ultra must faithfully replay when emulating a card lives here.
• Part 4 (Transmission Protocol) — the T=CL higher-level protocol framing, equivalent to ISO 7816 for contact smartcards. Relevant for DESFire EV1/EV2 and MIFARE Plus at higher security levels; less relevant for MIFARE Classic, which uses its own authentication and memory protocol rather than full T=CL.

The split between ISO 14443 Type A and Type B happens at Part 2. Type B (used by Calypso transit cards, some passports) has different modulation — 10% ASK NRZ downlink, BPSK uplink — and a different anticollision algorithm. All card families the Chameleon Ultra emulates are Type A; Type B is out of scope for this series.

3.4.1 Initialisation and anticollision

The Type A initialization sequence is the opening handshake every ISO 14443A transaction must follow, whether a legitimate card or the Chameleon Ultra is responding. The sequence:

1. The reader broadcasts REQA (Request Type A), a 7-bit single-byte command at 106 kbit/s on the 13.56 MHz carrier. All Type A cards in field respond simultaneously.
2. Each responding card returns an ATQA (Answer to Request Type A) — a 2-byte response encoding the card’s UID size (4-byte, 7-byte, or 10-byte) and anticollision identifier. Where multiple cards respond simultaneously, their ATQA frames collide; the reader detects the collision and initiates the anticollision loop.
3. The reader issues ANTICOLLISION commands, working through the UID bit by bit using a binary tree search to isolate one card. When a single card is identified, the reader issues a SELECT command with the full UID, and the selected card responds with its SAK (Select Acknowledge), a 1-byte code that identifies the card’s protocol capabilities (e.g., SAK 0x08 for MIFARE Classic 1K, SAK 0x20 for ISO 14443A-4 compliant cards like DESFire).
4. All non-selected cards enter the HALT state and stop responding until a new REQA is issued.

The Chameleon Ultra, when emulating a card slot, must execute the card side of this sequence. The slot’s configured UID, UID size, ATQA, and SAK are loaded into the nRF52840’s NFC-A hardware block or the slot’s emulation state machine; when the device detects an incoming reader field and REQA command, it responds with the configured ATQA, participates in the anticollision loop, responds to SELECT with the correct SAK, and then enters the card-specific application protocol (MIFARE Classic authentication for Classic slots, NDEF read for NTAG slots, etc.). The fidelity of this replay — particularly the response timing, which must meet ISO 14443A’s Frame Delay Time requirements — is where the Chameleon Ultra’s performance characteristics matter for compatibility with strict-timing readers.

3.4.2 UID types — 4-byte, 7-byte, 10-byte

ISO 14443A defines three UID sizes:

Table 1 — ISO 14443A defines three UID sizes

UID size	Bytes	Total bits	Also called	Notes
Single size	4	32	nUID (non-unique) or 4B UID	Fits in one SELECT cascade level; used by MIFARE Classic 1K/4K and most legacy cards
Double size	7	56	7B UID	Requires two SELECT cascade levels; used by MIFARE Ultralight, NTAG, and some DESFire variants
Triple size	10	80	10B UID	Requires three SELECT cascade levels; rarely encountered in access-control contexts

The Chameleon Ultra supports both 4-byte and 7-byte UIDs for its emulation slots (per the Lab401 product specification). A slot configured as MIFARE Classic 1K uses a 4-byte UID by default; a slot configured as MIFARE Ultralight or NTAG uses a 7-byte UID. The UID is the critical identifier that the Chameleon must reproduce exactly: readers that perform only UID-level verification will grant access based solely on the UID match, and readers that perform full Crypto1 authentication will use the UID as input to the authentication nonce exchange.

Note on “magic” UIDs: MIFARE Classic cards normally fix the UID at manufacture (sector 0, block 0 is factory-locked). Magic Gen1a, Gen2, and Gen3 blanks can write to block 0, enabling the operator to program any UID onto the blank. The Chameleon Ultra emulation sidesteps this issue entirely: the firmware allows any UID to be programmed into any slot regardless of manufacturer restrictions, since the slot is software state rather than a hardware fuse.

3.4.3 Card families under ISO 14443A

The card families the Chameleon Ultra supports are all ISO 14443A implementations. Briefly:

Table 2 — The card families the Chameleon Ultra supports are all ISO 14443A implementations. Briefly

Family	ISO 14443A compliance	Security	Chameleon scope
MIFARE Classic 1K / 2K / 4K	ISO 14443A-3 only (own auth protocol, not full T=CL)	Crypto1 — broken	Full emulate, read, attack. Primary focus of Vol 4.
MIFARE Ultralight / Ultralight EV1	ISO 14443A-3 (Type 2 NFC tag)	None (Ultralight); lightweight counter (EV1)	Emulate; UID-only in most access-control contexts
NTAG 210–218	ISO 14443A-3 (Type 2 NFC tag)	Optional page-locking, no crypto key	Emulate; used heavily in NFC sticker applications
MIFARE DESFire EV1 / EV2	Full ISO 14443A-4 (T=CL)	3DES (EV1) / AES-128 (EV2) — not broken	Emulate UID; low-rate (106 kbit/s) only; encrypted contents not reachable
MIFARE Plus	ISO 14443A-4	AES-128 in SL3 mode; Crypto1-compatible in SL1	Emulate; SL1 mode attackable as MIFARE Classic

Vol 4 covers MIFARE Classic in full operational depth. Vol 7 covers slot configuration for each family above. The DESFire and Plus limitations are detailed in §7.1 below.

3.5 MIFARE Classic — Crypto1, sector structure, why it cracks

MIFARE Classic is the dominant HF access-control card worldwide and the primary target of the Chameleon Ultra’s attack suite. Understanding the sector structure and the Crypto1 cipher at a conceptual level is necessary to follow the attack workflows in Vol 4; the full cryptographic treatment is in the iCopy-X primer (§8.2 of that volume).

3.5.1 Sector and block layout

MIFARE Classic memory is organized into sectors, each protected by an independent pair of 48-bit keys (Key A and Key B). The 1K and 4K variants differ in sector count and the block structure of the upper sectors:

Table 3 — MIFARE Classic memory is organized into sectors, each protected by an independent pair of 48-bit keys (Key A and Key B). The 1K and 4K variants differ in sector count and the block structure of the upper sectors

Variant	Sector structure	Total sectors	Total blocks
MIFARE Classic 1K	16 sectors × 4 blocks	16	64
MIFARE Classic 4K	32 sectors × 4 blocks + 8 sectors × 16 blocks	40	256
MIFARE Classic Mini	5 sectors × 4 blocks	5	20

Each block is 16 bytes. In the 1K variant, all 64 blocks are 4-block sectors; in the 4K variant, sectors 0–31 each have 4 blocks (totaling 128 blocks) and sectors 32–39 each have 16 blocks (totaling 128 additional blocks), for 256 blocks total across 40 sectors. This structure is defined in the NXP MF1S70YYX datasheet.

Within each sector, the final block is the sector trailer — not a data block. It holds the sector’s two 48-bit keys and the three-byte access-condition (ACL) field that controls which operations Key A and Key B can authorize:

Sector trailer (Block n):
  [Key A : 6 bytes] [Access bits : 3 bytes] [User byte : 1 byte] [Key B : 6 bytes]

Key A is never directly readable from the card (a correctly configured ACL will always return zeros when Key A bytes are read, even if the reading session is authenticated). Key B may be readable or not depending on the ACL. The ACL bits govern read, write, increment, decrement, and transfer operations on a per-sector, per-block basis. An incorrectly programmed ACL can lock a sector permanently; the iCopy-X primer §9 (on magic blanks and sector restoration) covers the recovery path.

Sectors 0–N hold the access-control data relevant to the site’s application: typically the credential ID, facility code, and any cardholder data the access-control system uses. Sector 0 Block 0 is additionally the manufacturer block — it holds the card’s UID and some factory-programmed metadata — and is normally hardware-locked after manufacture on a genuine card (the magic blank exception, noted in §4.2 above).

3.5.2 Crypto1 — the broken cipher

Crypto1 is NXP’s proprietary stream cipher, introduced with MIFARE Classic in 1994. It is a 48-bit linear feedback shift register (LFSR) with a nonlinear filter function on top: the 48-bit LFSR state advances on each clock cycle, and the nonlinear filter produces one keystream bit per clock from a subset of the LFSR’s taps. Authentication to a MIFARE Classic sector proceeds via a three-pass mutual authentication:

1. The reader requests authentication for a specific sector and key type (Key A or Key B).
2. The card responds with a 32-bit random nonce (nT).
3. The reader XORs its response (nR) against the keystream generated by seeding Crypto1 with the 48-bit key and nT.
4. The card replies with its own 32-bit challenge response (aR), also keystream-encrypted.
5. All subsequent communication in the session is encrypted with Crypto1.

This protocol was reverse-engineered starting in 2008. Karsten Nohl, Starbug, and Henryk Plötz physically delayered and photographed a MIFARE Classic chip die under microscope, reconstructing the LFSR polynomial and the nonlinear filter function from the silicon geometry (“Mifare Security” — CCC 2007/2008). Flavio Garcia, Gerhard de Koning Gans, Ruben Muijrers, Peter van Rossum, Roel Verdult, Ronny Wichers Schreur, and Bart Jacobs published the full software-side analysis with working attacks (“Dismantling MIFARE Classic,” ESORICS 2008), establishing the logical algorithm description that all subsequent attack tools use.

The core weaknesses exploited by the Chameleon Ultra’s attack suite:

1. The PRNG is weak and predictable. The card’s random nonce nT is generated by a simple 16-bit PRNG that advances with time (specifically, with the number of carrier-field cycles since power-on). The PRNG state at the point of authentication is therefore predictable from timing, and two consecutive authentication attempts will produce nonces that differ by a fixed offset. This predictability is what makes the DarkSide and StaticNested attacks possible.

2. The keystream leaks through parity bits. MIFARE Classic ISO 14443A frames include parity bits that are encrypted by Crypto1 along with the data, but the reader’s encryption of parity under the SAME keystream that encrypts the data means the parity bits expose keystream bits directly (xoring data-bit and parity-bit recovers a keystream bit). This parity-bit exposure is one of the mechanisms the DarkSide attack exploits.

3. Authentication nonce pairs enable offline key recovery. If an attacker can observe multiple authentication nonce exchanges (either as a sniffing observer or as an active reader probing the card), the (nT, nR, aR) tuples constrain the Crypto1 key space sufficiently that offline brute-force or meet-in-the-middle search can recover the 48-bit key.

3.5.3 Why the attack suite exists

A single attack mechanism is insufficient to recover all sector keys across all MIFARE Classic deployment variants the Chameleon Ultra will encounter in the field. The five-attack suite exists because:

DarkSide (DarkSide: Nicolas Courtois, 2009) targets sectors with completely unknown keys, exploiting the fact that when the card receives a malformed authentication request, its error response leaks keystream bits that constrain the key search. DarkSide requires no prior key knowledge and works against the original MIFARE Classic generation. Its limitation: it does not work against MIFARE Classic EV1 and some later variants that harden the PRNG initialization.

Nested (Garcia et al., 2009) requires one known sector key as a starting point — typically a factory-default key (FFFFFFFFFFFF or A0A1A2A3A4A5 are common) that has not been changed — and uses it to authenticate to the known sector, then issues authentication requests for unknown sectors while the cipher is still running. The known session’s keystream state combined with the card’s predictable PRNG allows offline recovery of the second sector’s key without interaction with the card beyond the authentication exchange itself. Nested is fast — seconds per sector — and handles almost all field-deployed MIFARE Classic 1K cards that retain at least one default key.

HardNested (Meijer & Verdult, CCS 2015; Proxmark3 implementation by pwpiwi) handles the class of cards that resist the original Nested attack because their PRNG initialization prevents the timing-based prediction. It uses a probabilistic bitwise analysis of encrypted nonce pairs to reconstruct the key, and requires more computation (minutes to tens of minutes per sector) but reliably recovers keys from hardened variants including MIFARE Classic EV1.

MFKEY32 v2 (Iceman/piwi, various dates) is a reader-sniff attack: the Chameleon Ultra, positioned between a reader and a legitimate card, captures the authentication exchange (nT from the card, nR+aR from the reader) and recovers the key the reader used. This is the canonical attack for deployments where direct card access is unavailable but the legitimate reader can be prompted to authenticate while the Chameleon is sniffing. Vol 4 §7 covers the MFKEY32 v2 workflow in operational detail.

StaticNested targets the small population of MIFARE Classic deployments where the card is configured to use the same PRNG seed across all sectors — a common occurrence in some OEM access-control card manufacturers who program the card in a fixed timing environment. When the PRNG seed is static, the nT values across different sectors are deterministically related, allowing faster key recovery than HardNested with a smaller number of interactions.

The practical implication: most field-encountered MIFARE Classic 1K cards programmed with any default keys yield to Nested in seconds. Cards with all-unknown keys yield to DarkSide or HardNested in minutes. The full five-attack suite covers essentially all MIFARE Classic variants encountered in commercial access-control deployments through mid-2026. Vol 4 covers each attack’s CLI invocation and the decision tree for which attack to try first.

3.6 LF protocols in scope — EM410x, HID Prox, T5577

The Chameleon Ultra’s LF protocol scope covers the 125 kHz credential families that account for the overwhelming majority of deployed LF access-control badges. The firmware distinguishes between read capability (the Ultra’s MFRC522-less LF path can interrogate and decode an LF tag), emulate capability (the Ultra can present an LF credential to a reader), and write capability (the Ultra can program a writable LF blank). The support level varies significantly across families, as detailed below and in §6.4.

3.6.1 EM410x

EM410x (also EM4100, EM4102, EM4200) is the simplest 125 kHz LF credential family and the most widely deployed globally. The EM4100 specification (EM Microelectronic, original design dating to the 1990s) defines a 64-bit read-only transponder: the chip carries a factory-programmed 64-bit identifier, encodes it using Manchester encoding at the 125 kHz carrier rate (typically at 64 clock cycles per bit, giving a data rate of approximately 125 kHz / 64 ≈ 1.95 kbit/s), and transmits continuously whenever powered by a reader field.

Key characteristics:

• Read-only: the 64-bit ID is factory-programmed and cannot be written in the field. This is the defining property — EM4100 fobs and cards cannot be reprogrammed, only cloned to a writable blank (T5577 or EM4305) that mimics the same EM4100 output.
• No authentication: the card transmits its ID in clear, continuously. Any reader that can tune to 125 kHz and demodulate ASK/Manchester can read an EM410x credential without any protocol handshake.
• 64-bit frame: structured as a 9-bit leader, a 40-bit data field (carrying the version/customer code and the UID value), and row/column parity check bits totaling 64 bits. The effective unique ID space is 40 bits (~1 trillion combinations), but many OEM installers use only the lower 24–32 bits, narrowing the practical collision risk.

EM410x is the baseline LF credential for commodity access-control duplicator tools (the common $5 handheld LF cloners) because its no-authentication, ASK/Manchester protocol is trivially readable and writeable. The Chameleon Ultra’s EM410x support is fully implemented at all layers: read, emulate, and UID brute-force attack.

3.6.2 HID Prox

HID Prox is the dominant proprietary LF credential standard for North American commercial access-control deployments. Introduced by HID Corporation (now part of Allegion/HID Global), HID Prox credentials use FSK modulation at 125 kHz — specifically, the sub-carriers at approximately fc/8 (15.625 kHz) and fc/10 (12.5 kHz) are alternated to encode bits, making HID Prox more resilient to ambient noise than ASK-based credentials. The data layer uses a Biphase bit encoding at the sub-carrier rate.

The most widely deployed HID Prox format is H10301, the 26-bit open format: an 8-bit facility code (0–255), a 16-bit card number (0–65535), and two parity bits — 26 bits total, transmitted from the card to the reader. The reader decodes the 26-bit stream and passes it to the access-control panel via the Wiegand interface (a two-wire current-loop serial bus with DATA0 and DATA1 lines). The Wiegand interface is a reader-to-panel protocol, not a card-to-reader protocol — a common source of confusion, since “Wiegand” is often used loosely to mean any HID Prox credential. What the card transmits is an FSK-modulated biphase-encoded 26-bit frame over the air; what the reader passes to the panel is an electrical Wiegand signal.

HID Prox also defines proprietary multi-bit formats (35-bit, 37-bit, 40-bit, and site-specific formats with up to 255 bits) that encode additional facility-code and card-number space. The Chameleon Ultra’s emulation of HID Prox reproduces the card’s over-the-air signal — the FSK-modulated biphase bit stream — rather than the reader-to-panel Wiegand electrical interface. An access reader that reads the Chameleon Ultra’s emulated HID Prox slot must decode the FSK signal identically to a genuine HID Prox fob, then forward the decoded data to the access panel via Wiegand as it normally would.

The emulation status of HID Prox on the Chameleon Ultra as of mid-2026 has an important caveat: a GitHub issue (#325, opened December 2025) documents a known bug where 6-byte RAW HID LF emulation produces a signal that readers detect but reject — the LED indicates field coupling but the access reader does not grant access. This issue was open and unresolved as of the authoring of this volume. Operators should verify the current firmware’s HID Prox emulation reliability against their specific reader model before relying on it for an engagement; T5577 clones of HID Prox credentials remain the more reliable emulation path for HID Prox-gated readers where the Chameleon’s HID emulation does not work.

3.6.3 T5577

T5577 (Atmel/Microchip ATA5577C) is the dominant writable LF blank chip, and it occupies a different role in the Chameleon Ultra workflow than the other LF families: it is the target of the write path (programming an EM410x or HID Prox ID onto a T5577 blank), not the primary credential being emulated. Understanding T5577 is prerequisite to understanding why LF cloning to a physical blank works the way it does.

The T5577 is a fully configurable 125 kHz transponder. Its internal memory is organized as a configuration register (Block 0) followed by data blocks (Blocks 1–6). Block 0 carries the modulator configuration: which encoding to use (ASK/Manchester, FSK, PSK), what sub-carrier ratio, what bit rate, and whether the chip presents as an EM4100, HID Prox, Indala, or one of a dozen other protocol formats. Writing the correct Block 0 configuration plus the target ID data into Blocks 1–6 causes the T5577 to present identically to the target credential type when interrogated by a reader.

Key T5577 capabilities:

• Configurable modulation: ASK, FSK (fc/8/fc/10 and fc/5/fc/8 variants), PSK — covers the three modulation classes used by all supported LF families
• Password protection: a 32-bit write-protect password that prevents unauthorized reprogramming; the Chameleon Ultra supports T5577 password brute-force (up to 4 billion combinations; the practical wall-clock time depends on the per-attempt LF write/verify rate and is not officially specified)
• Multi-protocol: a single T5577 blank can be reprogrammed between EM4100, HID Prox, Indala, and other formats by rewriting Block 0 and the data blocks, without hardware changes

The Chameleon Ultra’s T5577 support in terms of physical blanks is: read (the Ultra can decode a T5577’s content) and write (the Ultra can program Block 0 and data blocks). The firmware’s T5577 brute-force attack (for password-protected T5577 cards) is confirmed implemented in the attack CLI. Write reliability has seen community-reported issues (GitHub issue #319, “125khz LF T5577 not writing”, opened 2025-11-07 — a flat write-failure bug in some configurations); check current firmware release notes for resolution status.

In terms of emulation, the Chameleon Ultra emulates the protocols T5577 can target (EM410x, HID Prox) at the slot level — the Chameleon Ultra does not present itself as a T5577 chip per se (with T5577’s own protocol framing and block-read commands), but as the underlying credential format (EM4100, HID Prox, etc.) that the T5577 would emit when programmed to that format. Vol 5 covers the write and brute-force workflows in detail.

3.6.4 Other families (Indala, FDX-B, Paradox, AWD, PAC/Stanley, and extended families)

The Chameleon Ultra’s LF hardware supports 19 distinct protocol families, per the RRG technical whitepaper’s protocol support table at github.com/RfidResearchGroup/ChameleonUltra/wiki/technical_whitepaper. The Lab401 product listing names all 19: EM410x, T5577, EM4305, HID Prox, Indala, FDX-B, Paradox, Keri, AWD, ioProx, securakey, gallagher, PAC/Stanley, Presco, Visa2000, Viking, Noralsy, NexWatch, and Jablotron. Each of these has confirmed hardware and software layer support — the nRF52840 LF analog path can generate and demodulate the modulation types (ASK, FSK, PSK) required by all 19 families.

The critical distinction is between hardware/software support and application-layer implementation — the firmware logic that parses a specific protocol’s framing, encodes it for emulation, and integrates it into the CLI and BLE app slot-management commands. Per the technical whitepaper’s support table (verified against the wiki in June 2026):

• EM410x: fully implemented (read, emulate, brute-force). The foundational LF protocol; this was the first LF family completed in the firmware.
• HID Prox: reading implemented; emulation has a known open bug (issue #325, December 2025) that produces reader detection without access-grant on some readers — treat as experimental until confirmed fixed in a released firmware version.
• T5577: read and write implemented; password brute-force implemented; see §6.3 for write reliability caveats.
• EM4305: hardware/software support; application layer is listed as “Support” in the whitepaper but community issues suggest read may work while emulation completeness varies by firmware version.
• Indala, FDX-B, Paradox, AWD, PAC/Stanley, Keri, ioProx, securakey, gallagher, Presco, Visa2000, Viking, Noralsy, NexWatch, Jablotron: the whitepaper’s support table shows “Support” at the hardware and software layers but “Not yet implemented” at the application layer for these families as of the whitepaper’s last substantive update. The Lab401 product listing’s inclusion of all 19 reflects hardware-level capability, not confirmed application-layer completeness.

The practical implication for the operator: EM410x is the fully reliable LF protocol on the Chameleon Ultra today. HID Prox reading is functional; emulation requires verification against the current firmware and target reader. The extended family list represents the firmware’s roadmap rather than its current field-ready capabilities. Operators who need reliable Indala or FDX-B emulation in 2026 should verify against the current firmware release notes at github.com/RfidResearchGroup/ChameleonUltra/releases before an engagement; the situation may have improved since this volume was written, given the actively maintained firmware. For those families where the Chameleon Ultra’s application layer is not yet complete, the Proxmark3 RDV4 (with the Iceman firmware and its comprehensive LF library) remains the more reliable tool — see Vol 8 §9 for the comparison.

3.7 What the Chameleon Ultra can and cannot do at the protocol layer

This section provides a clean protocol-capability summary before the reader enters the operational detail of Vols 4 and 5. The table and notes here are the distillation of the preceding sections.

3.7.1 In-scope capabilities table

Table 4 — 7.1 In-scope capabilities table

Protocol family	Standard / layer	Read	Write	Emulate	Attack capability	Vol reference
MIFARE Classic 1K	ISO 14443A-3, Crypto1	Yes (MFRC522)	Yes (MFRC522)	Yes	MFKEY32 v2, DarkSide, Nested, StaticNested, HardNested	Vol 4
MIFARE Classic 4K	ISO 14443A-3, Crypto1	Yes (MFRC522)	Yes (MFRC522)	Yes	Same as 1K	Vol 4
MIFARE Classic 2K	ISO 14443A-3, Crypto1	Yes	Yes	Yes	Same as 1K	Vol 4
MIFARE Ultralight / EV1	ISO 14443A-3, NFC Type 2	Yes	Yes	Yes	None (no crypto to attack)	Vol 4 §8
NTAG 210–218	ISO 14443A-3, NFC Type 2	Yes	Yes	Yes	None	Vol 4 §8
MIFARE DESFire EV1 / EV2	ISO 14443A-4 (T=CL), 3DES/AES-128	UID + metadata only	No	UID emulation only	None (AES-128 not broken)	§7.2
MIFARE Plus (SL1)	ISO 14443A-3/4, Crypto1-compat	Yes	Yes	Yes	Crypto1 attacks (SL1 = Classic-compatible)	Vol 4
MIFARE Plus (SL3)	ISO 14443A-4, AES-128	UID only	No	UID emulation only	None	§7.2
EM410x (LF)	Proprietary EM, ASK/Manchester	Yes (nRF52840 LF)	N/A (read-only tag)	Yes	UID brute-force	Vol 5
T5577 (LF)	Proprietary Atmel, configurable	Yes	Yes	Via protocol emulation	Password brute-force	Vol 5
HID Prox (LF)	Proprietary HID, FSK/Biphase	Yes	Via T5577	Experimental (see §6.2)	None on-device	Vol 5
Other LF families	Proprietary, ASK/FSK/PSK	Read ✓ (per whitepaper)	Via T5577 (when protocol complete)	Not yet implemented	N/A	Vol 5

Notes on the table:

• “MFRC522” in the Read/Write column indicates that operation requires the MFRC522 HF reader IC, which is only present in the Ultra (not the Lite).
• “UID emulation only” for DESFire EV1/EV2 means the Chameleon Ultra can reproduce the card’s UID and ATQA/SAK in the anticollision sequence, but the DESFire application protocol authentication — which requires the AES-128 keys — will fail. Systems that verify only the UID will pass an emulated DESFire UID; systems that perform full DESFire authentication will reject it.
• MIFARE DESFire emulation on the Chameleon Ultra is limited to 106 kbit/s (low rate) per the RRG technical whitepaper. This is not a blocking limitation for most access-control readers, which operate at the baseline 106 kbit/s rate, but it does mean that readers that negotiate 424 or 848 kbit/s communication with genuine DESFire cards may fall back to 106 kbit/s or reject the emulation depending on their implementation.

3.7.2 Out-of-scope protocols

The following protocols are outside the Chameleon Ultra’s capability envelope, by design, by hardware constraint, or by the current state of firmware development:

ISO 15693 (HF vicinity cards) — HID iCLASS Legacy and iCLASS Elite sit on an ISO 15693 physical layer at 13.56 MHz. The MFRC522 supports ISO 15693 in hardware (it is a multi-standard HF reader IC), but the Chameleon Ultra firmware does not implement an ISO 15693 stack. iCLASS Legacy/Elite emulation and reading are therefore out of scope. The iCopy-X with its Proxmark3 FPGA silicon is the appropriate tool for iCLASS work; see Vol 8 §3 and the iCopy-X series Vol 6.

iCLASS SE / SEOS — HID’s second-generation iCLASS family uses AES-128 with proper key management. Even if the physical layer were supported, the cryptographic protection is not broken. The iCS Decoder accessory for the iCopy-X handles iCLASS SE/SEOS protocol decoding; the Chameleon Ultra has no equivalent capability.

FeliCa — Sony FeliCa (JIS X 6319-4, NFC Type 3) is physically at 13.56 MHz but uses a different modulation (Manchester coding on a different subcarrier) and a different anticollision scheme than ISO 14443A. The MFRC522 does not implement FeliCa in hardware. FeliCa is primarily a Japan-market technology (Suica, PASMO transit cards); for any FeliCa work, the Proxmark3 RDV4 with the Iceman firmware is the appropriate tool.

Legic — Legic Prime and Legic Advant are European access-control card standards (common in Switzerland, Germany, and broader continental Europe) with proprietary physical layers and proprietary cryptography. Not implemented in the Chameleon Ultra firmware.

ISO 14443B — Calypso transit cards, some passports, and EMV payment cards sit on ISO 14443B’s 10% ASK BPSK physical layer. The MFRC522 can operate in ISO 14443B mode in hardware, but the Chameleon Ultra firmware does not implement Type B initialization or application protocols. Proxmark3 RDV4 is the appropriate tool for Type B work.

UHF RFID (860–960 MHz, ISO 18000-6 / EPC Gen2) — retail anti-theft tags, inventory tracking, and supply-chain RFID operate in the UHF band. Entirely different physics (far-field coupling, backscatter modulation), entirely different hardware. No handheld multi-protocol tool in this hub’s lineup covers UHF; a dedicated UHF reader/writer is required. This is not a Chameleon Ultra limitation specifically — none of the RFID tools in this hub cover UHF.

NFC peer-to-peer and card emulation on smartphones — Android and iOS phones emulate ISO 14443A cards via Host Card Emulation (HCE), with the cryptographic credentials protected in the phone’s hardware-backed secure element. The Chameleon Ultra can read the public metadata and UID from an HCE-presenting phone; the underlying tokenized credentials are not accessible.

For any protocol outside the Chameleon Ultra’s scope listed above, the appropriate reference tools are:

• Proxmark3 RDV4 (Iceman firmware): ISO 15693, iCLASS Legacy/Elite/SE, FeliCa, ISO 14443B, HITAG variants beyond the Chameleon’s LF scope — see Vol 8 for the side-by-side comparison
• iCopy-X with iCS Decoder: iCLASS SE/SEOS decoding for authorized engagements — see ../../iCopy-X/02-inputs/volume_sources/vol6.md