Chameleon Ultra — LF Emulation

5.1 The 8 LF slot model

The Chameleon Ultra’s slot architecture assigns eight independently addressable slots to LF (125 kHz) operation, mirroring the eight slots available on the HF (13.56 MHz) side. A slot is not a binary LF-or-HF resource: each of the eight numbered slots can simultaneously hold one HF card configuration and one LF card configuration. The slot number is the shared index; which frequency responds when the device detects a reader field is determined by the field’s frequency. An operator can configure slot 3 as MIFARE Classic 1K on the HF side and EM410x on the LF side simultaneously. When the device enters a building with an EM410x-gated door and later encounters a MIFARE Classic reader deeper in the facility, slot 3 responds to both without any reconfiguration.

5.1.1 LF slot independence

Each slot’s LF configuration is a tuple of (protocol type, credential value). The protocol type selects the modulation scheme and encoding the nRF52840 applies when generating a 125 kHz carrier; the credential value is the bit-stream payload — for EM410x, the 40-bit UID; for HID Prox, the facility code and card number; for other families, the format-specific identifier. The two fields are independently configurable: changing the credential value in a slot does not alter the protocol type, and switching the protocol type resets the credential value because the field formats are incompatible. There is no cross-contamination between slots — slot 2’s LF configuration is entirely independent of slot 7’s LF configuration, and a read-and-load operation targeting slot 4 does not affect any other slot’s stored state.

The LF side of a slot can also be left empty (no protocol type assigned), in which case the device does not respond on the LF band when that slot is active, even if a 125 kHz reader field is present. This lets an operator carry slots that are HF-only without the device generating spurious LF signals.

5.1.2 Persistence

LF slot data is stored in the nRF52840’s internal flash, in the same non-volatile slot storage block that holds HF slot data. Slot state survives power cycling, battery depletion (after which the device restores from flash on next power-up), and BLE disconnection. The nRF52840’s 1 MB flash provides adequate space for the 8×2 band slot table plus firmware, with room for future slot storage expansion. The only operation that erases LF slot data is an explicit slot-clear command issued through ChameleonUltraGUI or the USB CLI, or a full firmware factory-reset.

5.2 LF emulation mechanics on the nRF52840

The Chameleon Ultra has no dedicated LF reader IC. The entire 125 kHz signal chain — carrier generation, modulation, reception, and demodulation — is implemented using the nRF52840’s general-purpose digital peripherals. This is the defining architectural characteristic of the Ultra’s LF path, and it directly determines both the capabilities and the genuine limitations described in this volume.

5.2.1 Carrier generation

The nRF52840 generates the 125 kHz carrier by configuring one of its hardware PWM peripherals to produce a 50% duty-cycle square wave at that frequency. The PWM output drives a discrete analog driver stage on the secondary PCB, which amplifies the GPIO-level signal to the antenna coil drive current needed to establish a reader-class carrier field at the LF coil. The 125 kHz PWM output is a square wave rather than a sine wave; the LF antenna circuit’s resonance (the parallel LC tank formed by the coil inductance and tuning capacitors) filters out the harmonics and presents a sinusoidal field to the target card. The nRF52840’s 64 MHz system clock divides cleanly to 125 kHz (512 clock cycles per carrier period), giving an accurate carrier frequency without the fractional-division jitter that would complicate demodulation on some sensitive readers.

The nRF52840’s peripheral-driven approach — rather than a dedicated chip — means the carrier is generated entirely in software-configured hardware, with no chip-level trimming or automatic gain control for the transmit path. Per Vol 2 §4.1, community testing on the Dangerous Things forum has measured the resulting LF field at approximately 2 cm read range against typical fobs. No official LF carrier field strength specification has been published by RRG or Lab401 as of 2026-06.

5.2.2 Modulation and encoding

When the Chameleon Ultra writes to a physical T5577 blank or performs the UID brute-force attack, modulation is applied at the carrier level: the nRF52840 varies the PWM parameters (duty cycle or switching pattern) to encode the protocol-specific baseband onto the carrier. When the Chameleon Ultra emulates a passive LF credential (EM410x, HID Prox), it does not transmit — passive LF tags are powered by and respond to an external reader field. In emulation mode, the nRF52840 load-modulates the carrier field presented by the installed reader, switching a load across the LF antenna coil at the protocol-specific sub-carrier rate to transmit the credential’s bit-stream back to the reader. The nRF52840 applies the correct encoding for each protocol family: ASK/Manchester for EM410x, FSK2a/biphase for HID Prox, PSK1 for Indala, and ASK for the remaining families (per the RRG technical whitepaper’s modulation-type column). The encoding is implemented entirely in nRF52840 firmware; there is no signal-processing coprocessor.

5.2.3 Reader-compatibility considerations

The most significant known compatibility issue as of 2026-06 is GitHub issue #325 (opened December 2025, open at time of writing): the Chameleon Ultra fails to achieve access-grant when emulating 6-byte RAW HID LF credentials on some HID-compatible readers. The reader detects an LF signal (the slot’s LED indicates field coupling) but does not grant access. The root cause is that the GUI enforces a 5-byte UID input limit and does not accept the full 6-byte RAW HID credential; the emitted signal is therefore malformed for readers expecting the complete 6-byte format. The standard workaround is to program a physical T5577 blank with the HID Prox credential using the Ultra’s write path — T5577 clones present correctly to the same readers that reject the Ultra’s direct HID emulation. Operators relying on HID Prox emulation for an engagement should verify against the current firmware release at github.com/RfidResearchGroup/ChameleonUltra/releases before the engagement.

5.3 EM410x — the simplest LF credential; emulation and capture

EM410x (covering the EM4100, EM4102, and EM4200 chips from EM Microelectronic) is the most widely deployed 125 kHz access-control credential worldwide and the Chameleon Ultra’s most fully implemented LF protocol. Its simplicity is the point: no authentication, no cryptography, a fixed factory-programmed ID transmitted continuously in clear whenever a reader field is present. The EM4100 is the dominant variant and the origin of the format; the EM4200 is a pin-compatible successor with additional encoding options. This volume uses “EM410x” as the family name unless a specific variant is relevant.

5.3.1 EM410x protocol summary

The EM4100 datasheet (EM Microelectronic, Revision 3.1) defines a 64-bit read-only transponder. The 64-bit frame is structured as:

Table 1 — The EM4100 datasheet (EM Microelectronic, Revision 3.1) defines a 64-bit read-only transponder. The 64-bit frame is structured as

Field	Width	Content
Header	9 bits	All-ones leader (111111111) — marks the start of a frame
Data	40 bits	Version/customer code (8 bits) + UID value (32 bits); transmitted MSB first
Row parity	10 bits	Even parity bit per 4-bit row group (P0–P9)
Column parity	4 bits	Even parity bit per column across all 10 rows (PC0–PC3)
Stop bit	1 bit	Logic 0

The 40 data bits carry an 8-bit version or customer code (encoding vendor or application context) and a 32-bit UID value. The row parity and column parity bits together form a weak integrity check — they detect single-bit errors in the data field and allow the reader to discard corrupted reads, but they provide no authentication. The complete 64-bit frame is Manchester-encoded, using a mid-bit transition to represent each bit (low-to-high = 1, high-to-low = 0 by convention in the EM4100 specification). Encoding is at 64 carrier cycles per bit, giving a data rate of 125 kHz ÷ 64 ≈ 1.95 kbit/s. The chip transmits the frame repeatedly without pause for as long as it remains powered by the reader field.

The EM410x credential is read-only by design: the 64-bit ID is factory-programmed on the chip die and cannot be modified in the field. Cloning requires writing the credential ID to a writable blank (T5577 or EM4305) that emulates the EM4100 output. The Chameleon Ultra handles this entirely in software — the slot stores the ID value, and the nRF52840 generates the EM4100 Manchester-encoded ASK signal without any physical blank.

Cross-reference: Vol 3 §6.1 covers EM410x within the LF physics and protocol taxonomy. The bit-level frame structure above extends that treatment.

5.3.2 Capturing an EM410x credential

To read an EM410x card or fob into a slot, place the card directly against the Chameleon Ultra’s LF antenna face (the secondary PCB side — the reverse face from the USB-C port). Contact or near-contact is required; the Ultra’s LF read range is approximately 2 cm under ideal coupling conditions. In ChameleonUltraGUI, navigate to the target slot, select the LF read operation for EM410x, and trigger the scan. The nRF52840 drives the 125 kHz carrier, detects the card’s ASK/Manchester response, and decodes the 64-bit frame. A successful read presents the 40-bit credential value (typically displayed as a 10-digit hexadecimal string, representing the 8-bit version code + 32-bit UID). The CLI equivalent is hf lf em 410x read (command syntax may differ by firmware version; check help output for current syntax).

If the read fails, the most common causes are insufficient coupling (move the card closer, ensure the orientation is coaxial to the antenna), a T5577 blank configured to emit EM410x format (distinguishable by the fact that a Proxmark3 would also read it as EM410x — the wire protocols are identical), or a non-EM410x credential (many commodity fobs that look like EM410x are actually HID Prox or T5577; try HID Prox read if EM410x fails).

5.3.3 Loading and emulating an EM410x slot

To load a credential manually (without reading from a physical card): in ChameleonUltraGUI, select the target slot, choose EM410x as the protocol type on the LF side, and enter the 10-digit hexadecimal UID. To load from a capture result, use the “load to slot” action after a successful read — this copies the scanned credential into the slot without re-entering the value. Once loaded, activate the slot (select it as the active slot using Button B or through the GUI), and present the device’s LF antenna face to the access-control reader at the reader’s normal card-presentation distance. The nRF52840 will generate the EM4100 Manchester-encoded ASK response when it detects the reader’s 125 kHz carrier field.

EM410x emulation is fully implemented at the application layer (confirmed in the RRG technical whitepaper’s support table) and is the most reliable LF emulation path on the Chameleon Ultra.

5.4 HID Prox — H10301 26-bit and variants; emulation scope

HID Prox is the dominant proprietary LF format in North American commercial access-control deployments. Unlike EM410x’s open specification, HID Prox is a proprietary format whose over-the-air encoding is well-characterized by the security research community even without an official public specification.

5.4.1 H10301 26-bit format

H10301 is HID’s 26-bit open format — the most widely deployed HID Prox configuration and the one most access-control systems expect. The 26-bit payload carries three fields: 1 parity bit (even parity over the first 12 data bits — the 8-bit facility code plus the top 4 bits of the card number), an 8-bit facility code (values 1–255), a 16-bit card number (values 1–65,535), and 1 parity bit (odd parity over the last 12 data bits of the card number). The facility code supports 255 possible site codes; the card number supports 65,535 unique IDs per facility code. This gives the format a theoretical namespace of approximately 16.7 million unique credentials, though many sites issue cards within a single facility code, compressing the effective namespace substantially.

The over-the-air modulation is FSK2a: the card’s sub-carrier alternates between two frequencies — fc/8 (125 kHz ÷ 8 = 15.625 kHz) representing bit 0 and fc/10 (125 kHz ÷ 10 = 12.5 kHz) representing bit 1. The data rate is RF/50, meaning each bit occupies 50 carrier clock cycles (50 ÷ 125,000 Hz = 400 µs per bit, or 2.5 kbit/s). The bit-level encoding above the FSK sub-carrier is biphase, where each bit is represented by a two-state sub-carrier transition pattern. This layering — FSK as the physical modulation, biphase as the logical bit encoding — is what makes HID Prox more robust to amplitude noise than EM410x’s ASK scheme.

The Wiegand interface is a separate protocol layer that operates between the reader and the access-control panel over a two-wire DATA0/DATA1 current-loop bus — it is not part of the card’s over-the-air transmission. When the Chameleon Ultra emulates an H10301 credential, it reproduces the card’s over-the-air FSK signal. The installed reader decodes that FSK signal, extracts the 26-bit credential, and forwards it to the access-control panel via Wiegand exactly as it would for a genuine HID Prox card. The Ultra does not interact with the Wiegand bus directly.

5.4.2 Extended HID formats

HID Corporation defines many proprietary formats beyond H10301. The documented extended formats include 35-bit Corporate 1000 (which expands the facility code space to 4,095 and the card number space to 1,048,575), 37-bit H10302 and H10304, and site-specific formats ranging from 26 to 255 bits. All share the same FSK2a physical-layer encoding; they differ in the bit count and the field allocation within the payload.

The Chameleon Ultra’s HID Prox support at the application layer (confirmed ✓ per the RRG whitepaper) is primarily tested against the H10301 26-bit format. The specific emulation behavior for extended formats (35-bit, 37-bit) is not explicitly broken out in the whitepaper’s application-layer confirmation. Issue #325 (open, December 2025) is specifically about 6-byte RAW HID LF format, where the GUI caps UID entry at 5 bytes. Operators using non-standard or extended HID formats should verify emulation against the target reader and current firmware release before an engagement.

5.4.3 Capturing and emulating HID Prox

Reading a HID Prox card follows the same physical procedure as EM410x: card against the LF antenna face at contact or near-contact distance. In ChameleonUltraGUI, select the slot, choose HID Prox as the read target, and trigger the scan. The nRF52840 detects the card’s FSK2a sub-carrier response, demodulates the biphase bit-stream, and decodes the 26-bit (or wider) credential. A successful read presents the facility code and card number.

For emulation: configure the slot as HID Prox, enter or load the facility code and card number, and activate the slot. The nRF52840 generates the FSK2a signal with the encoded credential when it detects a reader field. As noted in §2.3 and §4.2, emulation reliability for some HID Prox variants (particularly 6-byte RAW HID) has an open bug (issue #325) as of 2026-06. For engagements where HID Prox emulation is critical, confirm functionality against the actual target reader model; program a T5577 blank via the Ultra’s write path as a backup if direct emulation does not produce access-grant on the target hardware.

5.5 T5577 emulation and T5577 password brute-force attack

The T5577 (Atmel/Microchip ATA5577C) occupies a unique position in the Chameleon Ultra’s LF workflow: it is not a credential format the Ultra emulates at the slot level (you configure an EM410x or HID Prox slot, not a “T5577 slot”), but it is the writable physical blank that sits behind most commercial LF cloner workflows — and it is the target of the Ultra’s write path and the T5577 password brute-force attack.

5.5.1 T5577 as a multi-protocol blank

The ATA5577C datasheet (Microchip, document DS70005357B) defines a fully configurable 125 kHz LF transponder. Its memory is organized as eight 32-bit blocks:

Table 2 — The ATA5577C datasheet (Microchip, document DS70005357B) defines a fully configurable 125 kHz LF transponder. Its memory is organized as eight 32-bit blocks

Block	Function
Block 0	Configuration register — selects modulation (ASK/FSK/PSK), sub-carrier ratio, data rate, bit encoding, and which target protocol format the chip presents
Blocks 1–6	Data payload — holds the credential ID bits for the programmed protocol
Block 7	Password — stores the 32-bit write-protect password (if password mode is active)

By writing the correct Block 0 configuration and the target credential into Blocks 1–6, the T5577 presents identically to an EM4100, HID Prox, Indala, or other protocol format when interrogated by a reader. A single T5577 blank can be reprogrammed between formats without hardware changes.

The RRG technical whitepaper lists T5577 under both “Low Frequency Reader” (read ✓, write ✓ at the hardware and software layers) and “Low Frequency Emulation” (hardware ✓, software ✓). The application layer for T5577 as a standalone slot type is marked “Not yet implemented” in the whitepaper — this is not a contradiction: the Chameleon Ultra presents T5577 blanks as EM410x or HID Prox at the slot level (the underlying protocol the T5577 is programmed to emit), not as a T5577 chip exposing its own block-read protocol. When you configure a Chameleon Ultra slot as EM410x and use the “write to T5577” function, the nRF52840 programs the physical T5577 blank to emit EM410x format, and the blank then presents as EM410x to any reader. The Chameleon Ultra itself never emulates a T5577 chip with T5577’s own block-read framing.

5.5.2 T5577 password protection

Block 7 of the ATA5577C is designated as the password register. When the device’s PWD configuration bit is set, any write command must be preceded by the 32-bit password as the first operand; if the submitted password does not match Block 7’s contents bit-for-bit, the chip discards the write and resets to Regular Read mode. This prevents unauthorized reprogramming of a locked T5577 blank. The password space is 2^32 (approximately 4.3 billion combinations).

Many commercially sold T5577 blanks leave password protection disabled (PWD = 0). Some OEM access-control systems ship T5577-backed credentials with the password set to a factory default or a predictable value derived from the card number. Finding the correct password is a prerequisite for reprogramming these locked blanks.

5.5.3 T5577 write and the EM410x UID brute-force attack

T5577 write to a physical blank: The Chameleon Ultra supports writing EM410x (and in principle other protocol formats) to a physical T5577 blank. Community testing in the Dangerous Things forum review thread confirms the write path working in practice. However, GitHub issue #319 (opened 2025-11-07, open as of 2026-06) documents a write-failure condition: some users encounter “Something went wrong in writing the card” when attempting to write a saved EM410x credential to a T5577 blank. The failure is not universal (many users report successful writes), but the issue is unresolved in the open tracker. Check the firmware release notes at github.com/RfidResearchGroup/ChameleonUltra/releases for the current status before depending on T5577 write for an engagement.

EM410x UID brute-force: The RRG technical whitepaper lists “Brute Force” against EM410x ID as hardware ✓ / software ✓ at the hardware and software layers, but the application layer is marked “Not yet implemented” — the same status as the T5577 password brute-force. In principle, this attack would iterate through a configurable EM410x credential space, presenting each candidate ID to an access-control reader in sequence until a match is found (i.e., the reader grants access for the candidate credential). Whether the application-layer implementation has landed in a firmware release after this volume was written should be verified against github.com/RfidResearchGroup/ChameleonUltra/releases before planning an engagement around it. If available, the practical utility would depend on the site’s rollout: a building where all EM410x cards share a known facility code with sequential card numbers represents a tractable search space; a site using random card numbers across an unknown facility code is effectively unbrute-forceable in reasonable time.

T5577 password brute-force: The RRG firmware’s attack CLI reportedly supports T5577 password brute-force (iterating through the 32-bit password space against a locked T5577 card until a matching password is found), as documented in Vol 3 §6.3 based on RRG technical documentation and community sources. This attack is distinct from the EM410x UID brute-force: it targets the write-protect password on a locked T5577 blank, not a live access-control reader. The whitepaper’s attack table lists T5577 password brute-force as hardware ✓ / software ✓ with the application layer also “Not yet implemented” — the same honest status as EM410x UID brute-force. The full 32-bit password space (approximately 4.3 billion combinations) is feasible in theory but the wall-clock time is not officially specified — it depends on the per-attempt LF write/verify cycle time, which varies by target and firmware version. In practice, most deployed T5577 blanks that use a non-default password use one of a small set of known common passwords, making a dictionary-first approach substantially faster than exhaustive search. Verify the current firmware’s T5577 password brute-force CLI availability against the release notes before an engagement.

5.5.4 Limitations and when to use Proxmark3 instead

The Proxmark3 RDV4 (with Iceman firmware) is the more mature T5577 toolchain for edge cases: it provides direct block-level inspection of T5577 configuration, fine-grained control over timing parameters, and a larger community of T5577 command documentation. For systematic T5577 forensics (diagnosing why a blank is presenting an unexpected format, restoring a corrupted Block 0, or brute-forcing with precise per-attempt timing control), the Proxmark3’s dedicated T5577 guide (doc/T5577_Guide.md in the RRG/proxmark3 repository) is the appropriate reference. The Chameleon Ultra’s T5577 support is sufficient for the write-and-present workflow in the common case; the Proxmark3 wins for low-level T5577 diagnosis and edge-case recovery. See Vol 8 for the side-by-side comparison.

5.6 Indala

Indala is a proprietary 125 kHz LF credential format introduced by Motorola and subsequently acquired by HID Global (now Allegion/HID). It appears most commonly in older North American enterprise access-control installations and some government sites that deployed Motorola’s access-control hardware in the 1990s and 2000s. Indala credentials are physically indistinguishable from other 125 kHz fobs in external appearance; the modulation scheme is the distinguishing characteristic.

5.6.1 Indala encoding

Where EM410x uses ASK and HID Prox uses FSK2a, Indala uses PSK1 (Phase Shift Keying, sub-type 1) modulation. In PSK, the card modulates the phase of its sub-carrier rather than switching between two frequencies or switching its load amplitude. PSK1 encodes a bit transition as a 180-degree phase shift in the sub-carrier; a bit period with no phase shift encodes the opposite bit state. This phase-based scheme is somewhat more complex to implement in firmware than ASK or FSK, which partially explains why PSK-based families (Indala, Keri, NexWatch) have later application-layer completion than the ASK and FSK families in the ChameleonUltra firmware.

Indala supports multiple credential bit lengths. The Proxmark3 Iceman firmware’s Indala implementation (which is the best-characterized public reference for the format) handles 26-bit, 27-bit, 29-bit, 32-bit, 35-bit, 37-bit, 40-bit, 42-bit, 50-bit, and 64-bit Indala formats. The 26-bit format (also known as the Indala 26-bit or format H10302, though H10302 refers to HID’s own 37-bit format in some documentation — terminology varies by vendor) is the most common in deployed installations, encoding a facility code and card number in the same conceptual structure as H10301. The exact physical bit count and encoding vary by installation vintage; reading the card on a Proxmark3 before loading it into the Chameleon Ultra is the safest way to confirm which format variant you are working with.

5.6.2 Capturing and emulating Indala

The Chameleon Ultra’s Indala support as of 2026-06 is: hardware ✓, software ✓, application layer “Not yet implemented” per the RRG technical whitepaper. The hardware and software layers mean the nRF52840 can generate and demodulate PSK1 signals; the absence of an application-layer implementation means Indala credentials cannot be configured into a slot as a standalone Indala card type through the current ChameleonUltraGUI or CLI commands. Operators who need to emulate an Indala credential on the Chameleon Ultra as of 2026-06 should verify against the current firmware release notes — the application layer status may have changed in a firmware version released after this volume was written. For confirmed Indala emulation availability, the Proxmark3 RDV4 and Flipper Zero (which has a functional Indala implementation) are the current alternatives; a T5577 blank programmed with the Indala credential via Proxmark3 is also a viable physical clone path.

5.7 FDX-B, Paradox, AWD, PAC/Stanley

The RRG technical whitepaper lists 19 LF protocol families under hardware and software support. The four covered in this section — FDX-B, Paradox, AWD, and PAC/Stanley — are the most operationally relevant of the non-EM410x, non-HID Prox families for access-control and identification contexts. All four show “Not yet implemented” at the application layer as of the whitepaper’s current revision. That means the nRF52840 can generate and demodulate their modulation types, but the application-layer firmware commands that would let an operator configure a slot as “FDX-B” or “PAC/Stanley” and populate it with a read credential are not yet exposed in the ChameleonUltraGUI or CLI. The situation may change with future firmware releases; check github.com/RfidResearchGroup/ChameleonUltra/releases for the current state before an engagement.

5.7.1 FDX-B (ISO 11784/11785)

FDX-B is the animal identification transponder standard defined in ISO 11784 (code structure) and ISO 11785 (technical concept). It is the format used in pet and livestock microchips worldwide.

A critical hardware-level constraint applies: ISO 11785 specifies FDX-B transponders operate at 134.2 kHz — not 125 kHz. The Chameleon Ultra’s nRF52840-driven LF path is documented in the RRG technical whitepaper as operating at “only 125 kHz RF.” Genuine ISO 11785 FDX-B implant chips (pet microchips) require a 134.2 kHz interrogation field to power them; a 125 kHz field will not activate them. The ChameleonUltra’s inclusion of FDX-B in its supported protocol list therefore applies to FDX-B format data carried on T5577 blanks operating at 125 kHz — not to reading or emulating genuine 134.2 kHz ISO 11785 implants. For operations involving actual implanted animal microchips, a 134.2 kHz-capable reader (such as the Proxmark3 RDV4 with an appropriate low-frequency antenna setting, or a dedicated veterinary microchip scanner) is required.

The FDX-B data frame is 128 bits total. The bit encoding is differential biphase (DBP): a logic 0 is encoded as a mid-bit-period transition; a logic 1 has no mid-bit-period transition. The data rate is fc/32 (at 134.2 kHz, this gives a bit period of 32/134,200 ≈ 238 µs per bit). The frame carries a 38-bit animal identification number, a 10-bit country code, a 16-bit CRC checksum, and control and status bits. For the access-control pentesting context, FDX-B’s relevance is narrow: authorized TSCM/audit scenarios involving livestock tracking facilities or veterinary campuses where FDX-B credentials control physical access. In those settings, a Proxmark3 RDV4 configured for 134.2 kHz is the appropriate read tool.

5.7.2 Paradox

Paradox Security Systems credentials are proprietary 125 kHz LF fobs used with Paradox alarm and access-control panels (the C704 teardrop and C705 clamshell form factors being the most common). The modulation is FSK, confirmed by both the RRG whitepaper and Proxmark3 community analysis. The facility code range is 1–254. The format is proprietary (no public specification from Paradox); the bit structure and framing are characterized in the Proxmark3 community but not officially documented by the vendor.

Application-layer status: “Not yet implemented” per the whitepaper. Paradox credential emulation on the Chameleon Ultra requires a future firmware update that exposes the Paradox application layer. For current Paradox emulation needs, the Proxmark3 RDV4 with Iceman firmware’s lf paradox command set is the appropriate tool.

5.7.3 AWD and PAC/Stanley

AWD: AWD (spelled AWD in the RRG whitepaper — not AWID, which is a common mis-spelling in community documentation) is a 125 kHz LF format common in Australasian and Pacific commercial access-control installations. The RRG whitepaper classifies it as FSK modulation. Application-layer status: “Not yet implemented.” Confirmed spelling: “AWD” per the whitepaper’s protocol support table.

PAC/Stanley: PAC (a UK brand, now part of Stanley Security) is a proprietary 125 kHz LF format common in UK and European commercial installations. The RRG whitepaper classifies it as ASK modulation. Application-layer status: “Not yet implemented.” PAC/Stanley credentials are rarely encountered outside European markets; the Proxmark3 RDV4 with Iceman firmware handles PAC/Stanley reading and cloning when this format is encountered.

The remaining 11 extended LF families in the whitepaper (EM4305, Keri, ioProx, securakey, gallagher, Presco, Visa2000, Viking, Noralsy, NexWatch, Jablotron) are similarly at “Not yet implemented” application-layer status. For any of these formats, the Proxmark3 RDV4 with Iceman firmware is the confirmed tool for read and emulation as of 2026-06.

5.8 Reading LF cards — the nRF52840 LF read path vs MFRC522 (HF-only reader)

A persistent operational confusion arises from the Chameleon Ultra’s dual-band architecture: the MFRC522 chip is visible in teardown photos and documentation, and operators sometimes assume it handles LF reading. It does not. The MFRC522 is an NXP 13.56 MHz HF reader IC; it has no capability at 125 kHz. All LF card reads — and all LF emulation — are performed exclusively by the nRF52840’s own peripheral-driven analog path. This is the “no dedicated LF reader IC” architectural fact established in Vol 2 §4.

5.8.1 The LF read path in detail

When the operator triggers an LF read, the nRF52840 executes the following signal chain:

1. Field activation: The nRF52840 configures a PWM peripheral for 125 kHz output (or 134.2 kHz for FDX-B if the firmware supports frequency selection) and drives the LF antenna coil through the discrete amplifier stage on the secondary PCB. This establishes the reader-class interrogation field.

2. Card response detection: A passive LF tag powered by the field load-modulates the carrier — the tag’s logic switches a resistive load across its coil at the protocol-specific sub-carrier rate, causing measurable perturbations in the current through the reader’s LF coil. The nRF52840 detects these perturbations through a comparator or ADC peripheral tapped onto the LF antenna’s receive side (a separate or shared node on the antenna circuit that is isolated from the full-swing transmit path by the discrete front-end design).

3. Demodulation and decoding: The firmware demodulates the received waveform — extracting the sub-carrier frequency or phase from the raw ADC/comparator samples — and then decodes the bit-level encoding (Manchester for EM410x, FSK2a/biphase for HID Prox, PSK1 for Indala). The entire DSP stack runs on the nRF52840 Cortex-M4F in firmware; there is no hardware demodulator.

4. Frame validation: The decoded bits are checked against the protocol’s error-detection structure (parity bits for EM410x, format-specific checks for others). Valid frames are presented to the application layer as the decoded credential value.

The absence of automatic gain control (AGC) on the receive path, and the absence of matched filtering (a hardware bandpass centered on the card’s sub-carrier frequency), means the firmware DSP must operate on a raw signal that includes all the receive-path noise the nRF52840’s ADC captures. This is why the LF read path requires close coupling: signal-to-noise ratio drops rapidly as card distance increases, and without AGC there is no hardware compensation for weak signals.

5.8.2 Common LF read failures and fixes

Table 3 — 8.2 Common LF read failures and fixes

Symptom	Most likely cause	Resolution
No credential decoded after multiple attempts	Incorrect card placement — card not coaxial to LF coil	Place card flat against the secondary PCB face (LF antenna side) at contact distance
Credential decoded but wrong format	Unknown LF credential type — not EM410x	Try HID Prox read or use a Proxmark3 for auto-detect
Credential decoded on Proxmark3 but not Chameleon Ultra	Coupling distance too large for Ultra’s LF sensitivity	Contact or near-contact positioning required
Write to T5577 reports error	Issue #319 — some write configurations fail	See §5.3; check firmware release notes for fix status
Emulation: LED blinks, reader doesn’t grant access	Issue #325 (HID Prox 6-byte format) or coupling distance	For HID: use T5577 physical clone; for coupling: ensure reader face contact

5.9 Limitations — LF read range vs Proxmark3 RDV4

The Chameleon Ultra’s LF capability is operationally sufficient for the common case: reading an EM410x or HID Prox fob at contact or near-contact distance and emulating it against an installed access-control reader in a standard door-frame installation. For anything beyond that common case, the limitations are real and should be understood before an engagement.

5.9.1 Where the Chameleon Ultra LF is sufficient

The device’s LF path covers the scenarios that constitute the large majority of physical-pentest LF encounters:

• EM410x credential capture and emulation. Contact-distance read of an EM410x fob and emulation against a standard installed reader. This is fully implemented, well-tested, and the Ultra’s most reliable LF operation.
• HID Prox H10301 capture. Reading standard 26-bit HID Prox fobs. Read is implemented and functional. Emulation works for many readers (see issue #325 for the 6-byte RAW HID exception).
• Installed LF reader range. Installed 125 kHz door readers are designed to read a card held flush against the reader face at zero to two centimeters — within the Ultra’s coupling window for emulation. The Ultra’s emulation field does not need to reach across a room; it needs to couple at the distance the reader is designed to read, which aligns with the Ultra’s capability.
• BLE-managed slot switching in the field. Swapping between LF slots via ChameleonUltraGUI while approaching a reader is the Ultra’s core value proposition and is not limited by LF read range.

5.9.2 Where Proxmark3 wins

The Proxmark3 RDV4 outperforms the Chameleon Ultra in every LF measurement category:

Read range: The community-measured LF read range for the Chameleon Ultra is approximately 2 cm for HID Prox fobs (per the Dangerous Things forum review thread, “lf ~2cm” measured against a Flipper Zero reader field). This is a community data point, not an official spec. The Proxmark3 RDV4 with its purpose-matched LF antenna board achieves approximately 5–10 cm. No official LF range specification has been published by RRG or Lab401 for the Ultra. The Proxmark3’s advantage derives from its dedicated LF analog front end: automatic gain control, a hardware-tunable matching network, and a FPGA-based demodulator optimized for 125 kHz — capabilities the Ultra does not have.

Protocol breadth. The Proxmark3’s Iceman firmware has application-layer implementations for most of the 19 LF families the Chameleon Ultra lists as “not yet implemented.” For Indala, FDX-B, Paradox, AWD, PAC/Stanley, Keri, ioProx, securakey, gallagher, and the remaining extended families, the Proxmark3 is the confirmed tool as of 2026-06.

T5577 forensics. The Proxmark3’s doc/T5577_Guide.md (in the RfidResearchGroup/proxmark3 repository) and its lf t55xx command set provide block-level inspection and repair capabilities for corrupted T5577 blanks that the Ultra’s write path does not expose.

Signal quality analysis. The Proxmark3’s Graph mode and demodulation tools allow an operator to visualize the raw 125 kHz waveform and diagnose signal anomalies (timing drift, multi-card field collisions, non-standard encoding) that the Chameleon Ultra’s firmware-only receive path cannot surface.

When the Chameleon Ultra is the right LF tool: proximity credential capture (EM410x and HID Prox H10301) at contact distance in the field, emulation against standard installed readers, and situations where the device needs to remain in a pocket or card holder while cycling slots over BLE — use cases where portability and multi-slot management outweigh read range and protocol depth. For lab-grade LF analysis, extended protocol families, or any scenario requiring more than 2 cm of LF read range, the Proxmark3 RDV4 is the appropriate complement. See Vol 8 for the full side-by-side comparison and the decision framework for choosing between them in the field.