Chameleon Ultra — Legal, Ethics, Cheatsheet, and Glossary

12.1 Contents

1. The baseline legal rule
2. RFID emulation and the legal boundary
3. What the Chameleon Ultra cannot know — the operator’s burden
4. Specific use cases and their legal posture
   • 4.1 Authorized pentest with signed scope
   • 4.2 Facility-owner self-audit
   • 4.3 Red-team engagement
   • 4.4 Out-of-scope uses — payment cards, transit cards, government ID
5. Engagement documentation — what to carry
6. International variations
7. Cheatsheet — Chameleon Ultra field quick-reference
8. Glossary

---

12.2 The baseline legal rule

One sentence covers the entire scope of lawful use for the Chameleon Ultra: operate it only against systems you own outright or for which you hold current, written authorization from the system owner. Any use outside that boundary is unauthorized access regardless of the technical method employed — regardless of whether the target is an RFID reader, an access-control panel, a card-issuing system, or a cardholder’s credential. The tool itself confers no legal permission.

This principle is stated in the project-wide legal and ethics baseline: ../../_shared/legal_ethics.md. That document applies to every tool in this Hack Tools hub, and the Chameleon Ultra is not a special case. The RFID-specific standing rules in §RFID/NFC of that document are worth re-reading before any field operation:

• Reading a card the operator carries: legal.
• Cloning a building-access card without explicit written authorization from the building owner: illegal under U.S. CFAA and equivalents.
• Reading a card from someone else’s pocket without consent: depending on jurisdiction, somewhere between mischief and computer fraud.

Re-reading that document before each new engagement is not optional housekeeping — it is the minimum professional discipline for operating a device whose entire value proposition is credential capture and emulation.

---

12.3 RFID emulation and the legal boundary

RFID credential emulation occupies exactly the same legal space as any other unauthorized-access method. The relevant statutes do not define criminal liability by the physical method of access; they define it by whether access was authorized. A person who walks through a door using an emulated MIFARE Classic credential that they obtained by running hf mf darkside on a card they did not own, against a facility they were not authorized to test, has committed unauthorized access under any jurisdiction’s computer-crime statute — not because they emulated a card, but because the access itself was unauthorized.

In the United States, the Computer Fraud and Abuse Act (18 U.S.C. § 1030) prohibits intentional unauthorized access to a “protected computer,” a category that encompasses virtually any computer connected to the internet or used in interstate commerce — including the access-control panels that receive Wiegand data from RFID readers. State analogues (most U.S. states have their own computer-crime statutes) extend this coverage to facilities not otherwise reachable under federal jurisdiction. Physical-access card fraud statutes (often identity theft or fraud in the use of a counterfeit access device) may apply in parallel, providing additional exposure independent of the computer-crime theory.

The specific technical steps that produced the unauthorized access — whether DarkSide recovered a sector key, whether the nRF52840 emulated a 13.56 MHz card, whether the door reader passed the emulated UID to the panel — are irrelevant to the liability question. The courts and prosecutors assessing an unauthorized-access case do not apply a “technical sophistication” offset. Unauthorized access by emulation is unauthorized access.

The corollary that operators sometimes misunderstand: being a security researcher, owning the Chameleon Ultra, holding a CISSP or CEH certification, or having previously done authorized work for the same organization does not create a standing authorization for any specific engagement. Authorization must be explicit, written, and current for the specific systems and scope at hand.

---

12.4 What the Chameleon Ultra cannot know — the operator’s burden

The Chameleon Ultra has no awareness of authorization context. Its nRF52840 firmware does not know whether the operator is a facility owner running a self-audit, a pentester with a signed statement of work, or someone who found the device on a bus. When the operator issues hf mf darkside or presents an emulated slot to a reader, the firmware executes the command. It does not check. It has no mechanism to check. The GPL-3.0 firmware source is public and contains no authorization verification layer because no such layer is architecturally possible in a standalone handheld.

The operator bears full responsibility for ensuring every use falls within the authorized scope. This responsibility is not distributed to the hardware manufacturer (Proxgrind), the firmware maintainers (RRG), the distributor (Lab401), or the author of any tool in this deep-dive series. The open-source nature of the firmware and the existence of a public attack suite do not confer any legal permission, imply any endorsement of unauthorized use, or reduce criminal exposure in any jurisdiction.

Practically, this means the authorization check is entirely pre-field: before pressing the device’s first button against any target system, the operator must have confirmed in writing that the target is in scope. There is no firmware guard to catch scope drift in the field. Operators who have not internalized this often discover the gap when a security incident report attributes unauthorized access to a device that matches their kit.

---

12.5 Specific use cases and their legal posture

The four sub-sections below move from clearly authorized to clearly out-of-scope, covering the use patterns that arise most often in access-control audit and physical-penetration-testing practice.

12.5.1 Authorized pentest with signed scope

The gold standard for all field operations involving the Chameleon Ultra is a signed statement of work (SOW) or equivalent contractual instrument that explicitly names the facilities, card systems, date windows, and authorized access methods in scope. “Explicitly” is the operative word: a contract that authorizes “physical penetration testing of Headquarters Building A” does not automatically authorize RFID credential capture and emulation unless those methods are called out. The practitioner’s engagement contract must survive scrutiny by the client’s legal counsel, the practitioner’s own insurer, and — in the event of an incident — law enforcement.

What a meaningful signed scope document must include:

• Named locations: street addresses, floor or wing identifiers, specific access points (e.g., “Building A lobby turnstiles and elevator bank”). “Campus” without a floor list is insufficient if the engagement might touch floors the client did not intend to include.
• Named systems and card types: the access-control system vendor and credential technology in scope (e.g., “HID MIFARE Classic 1K credentials on HID RW300 readers”). This matters because the pentester’s engagement with a building’s MIFARE Classic system should not automatically extend to a co-located tenant’s DESFire EV2 deployment on the same physical readers.
• Date and time window: the authorized engagement window, including any mandatory notification procedures if the window is extended.
• Emergency-contact chain: a named individual at the client (not a department) who can confirm authorization on-site to responding law-enforcement or security staff — with a 24/7 reachable phone number. A chain with a backup in case the primary is unreachable.
• Authorized methods: if RFID/NFC credential capture and emulation are in scope, say so. If the engagement extends to reading credentials from employee pockets (with employee consent protocols), say that too.

The operator should carry an authorization letter distilled from the SOW to a single page — something a security guard or responding officer can read and act on in under thirty seconds.

12.5.2 Facility-owner self-audit

A facility owner who is auditing their own access-control infrastructure has the simplest authorization question: they own the system, and they are authorizing themselves. This resolves the core legal question but does not remove the need for documentation.

The practical risks for an undocumented self-audit are:

Insurance exposure: If the self-audit generates an incident (a door that opens unexpectedly, a system that logs anomalous activity, a staff member who sees unfamiliar equipment), the owner’s insurer may take an interest in whether the activity was authorized and controlled. A documented self-audit procedure — even an internal memo approving the activity, naming the person conducting it, and listing the scope — is the difference between “planned security test” and “unexplained breach” in the incident log.

Staff and law-enforcement response: Facility staff who see someone with an RFID device probing their access-control readers do not automatically know the person is the facility owner or their delegate. They call security or police. A pocket-sized authorization letter prevents escalation; the absence of one does not. The fact that the auditor is the facility owner is not self-evident to a responder who arrives without context.

Scope creep: Even owners sometimes probe access points they did not intend to audit — adjacent tenant spaces, emergency egress systems, parking facilities managed by a third party. Documenting the scope in advance creates the discipline to stay within it.

12.5.3 Red-team engagement

A red-team engagement is a contracted physical penetration test in which the operator acts on behalf of a client under a master services agreement (MSA) or equivalent framework. The engagement may involve social engineering, physical bypass, and RFID credential capture or emulation as components of a broader attack simulation. The authorization documentation requirements are the highest in this category.

The specific risk of carrying the Chameleon Ultra on a red-team operation without a physical “get-out-of-jail” letter is significant. Law enforcement responding to a call about suspicious activity at a facility — a call the red-team engagement may itself generate if the social engineering is working correctly — cannot assess from looking at the device or the operator’s conduct that the engagement is authorized. The responding officer’s authority to detain and search is not suspended by the existence of an authorization. What suspends the further consequences of that initial contact is documentation.

The minimum documentation for a red-team field operation involving the Chameleon Ultra:

• A one-page authorization letter on the client’s letterhead, signed by the client’s named security executive (not an IT manager — someone with actual authority over the physical facility), naming the engagement window, the operator’s name, and the specific systems in scope.
• The emergency-contact chain (§4.1) — ideally a direct cell number for someone who will actually answer at midnight if that is when law enforcement calls.
• The operator’s own identity documentation (the obvious baseline that some overlooked checklists miss).

The letter should explicitly state that the named individual is engaged in authorized security testing and that the client requests cooperation from law enforcement rather than interference. Experienced practitioners laminate a copy for field carry.

Scope discipline on red-team engagements: The ChameleonUltra’s eight HF and eight LF slots can be loaded with credentials from many different systems. On a red-team engagement, only credentials from systems explicitly named in scope should be in those slots. Credentials captured opportunistically from out-of-scope systems — a co-tenant’s RFID reader, a neighboring facility’s card — are evidence of unauthorized access regardless of what the operator learned or did with them. Load only in-scope credentials; clear slots that contained out-of-scope captures before leaving the facility.

12.5.4 Out-of-scope uses — payment cards, transit cards, government ID

The following categories are out of scope for any engagement, regardless of whether an authorization document names them, because independent statutes apply and no access-control engagement authorization overrides them:

Payment cards (EMV, contactless Visa/Mastercard/Amex): Payment card emulation for fraudulent transactions is card fraud under 18 U.S.C. § 1029 (U.S.) and equivalent statutes in every jurisdiction with a modern banking system. The Chameleon Ultra cannot perform full DESFire application-layer emulation in any case — EMV contactless and MIFARE DESFire EV2-backed payment credentials require AES-128 keys the device does not and cannot hold. This is both a legal hard line and a hardware non-capability. Do not attempt to capture or emulate payment credentials; do not test whether a reader that accepts MIFARE Classic emulation also accepts payment transactions.

Transit fare evasion: Using an emulated transit credential to bypass a fare gate is fraud against the transit operator and, in many jurisdictions, a specific offense under transportation or ticketing statutes independent of general computer-crime law. An access-control engagement authorization for a transit facility’s employee-access systems does not extend to the fare-collection system. These are typically separate systems with separate network architecture, separate card-key material, and separate legal characterization.

Government-issued credential emulation: Passports, national identity cards, military identification, law-enforcement credentials, and similar government-issued documents carry independent criminal exposure under identity-document statutes (e.g., 18 U.S.C. § 1543, § 1546 in the U.S.) that apply whether or not the emulation is for “research purposes.” The Chameleon Ultra’s emulation of an ISO 14443A credential that resembles a government document’s UID is a narrow technical action; the legal exposure for doing so without specific government authorization is not narrow.

These three categories are hard lines, not items to be risk-assessed against engagement scope. Keep them out of every slot, out of every dump file, and out of every scenario in the engagement report.

---

12.6 Engagement documentation — what to carry

The minimum field documentation set for any engagement involving the Chameleon Ultra:

Table 1 — The minimum field documentation set for any engagement involving the Chameleon Ultra

Document	Required for	Physical or digital
Authorization letter (one page, signed)	All field operations	Both — paper preferred
Emergency-contact card (client security POC, 24/7)	All field operations	Both
Scope summary (systems, locations, date window)	Pentest / red-team	Digital acceptable; paper backup for red-team
Master services agreement or SOW (reference)	Pentest / red-team	Digital on phone or laptop
Operator ID (driver’s license / passport)	All field operations	Physical — driver’s license or passport
Any site-specific visitor credentials issued by the client	Red-team / self-audit	Physical

Paper vs digital: Authorization documentation stored only on a phone is accessible only if the phone is unlocked. A responding officer or security guard may not wait for biometric authentication while the operator fumbles in a corridor. A printed or laminated one-page authorization letter in a shirt pocket is immediately producible. Digital copies on the phone are acceptable as backup — carry both. For red-team operations, a second printed copy in a different pocket (not the same pocket as the phone) eliminates the “phone confiscated” gap.

The operator’s own contact card (name, employer, email, professional phone) reduces the incident-reporting friction when the primary contact in the authorization letter is not immediately reachable. It does not substitute for the authorization letter but makes handoff to the client’s security team faster.

Authorization letter language: The letter should state plainly, in the first sentence, that the named individual is conducting authorized security testing of the named facility under contract with the named client, between the named dates. The balance of the letter can contain scope detail; the opening sentence is what the first responding security guard reads. Avoid jargon (“authorized pentest engagement”) unless the client’s security staff knows what that means.

---

12.7 International variations

The CFAA is a U.S.-specific statute; the underlying prohibition — unauthorized access to computer systems, including access-control infrastructure — has analogues in every major jurisdiction, with materially identical structures and similar consequences. This section outlines the principal frameworks operators encounter in international engagements. It is not a substitute for jurisdiction-specific legal counsel; it is a starting map.

United Kingdom — Computer Misuse Act 1990 (CMA 1990)

The UK’s primary computer-crime statute defines three basic offences. Section 1 (unauthorized access to computer material) is the direct analogue to CFAA unauthorized access; it carries a maximum custodial sentence of two years. Section 2 (unauthorized access with intent to commit or facilitate further offences) applies when the access is preparatory to another crime and carries up to five years. Section 3 (unauthorized acts with intent to impair the operation of computers) covers acts that interfere with data or computer functions.

Most relevant to RFID tooling: Section 3A (added by the Police and Justice Act 2006) creates an offence for making, supplying, or obtaining an “article” — which can include a software tool or hardware device — intending it to be used to commit a Section 1 or Section 3 offence. This provision has been interpreted broadly enough that possession of the Chameleon Ultra combined with evidence of intent to use it without authorization is a realistic exposure under s.3A. The provision also extends to obtaining such articles “believing that it is likely to be used” for unauthorized access. For UK-based operators, this reinforces the importance of documentation: work done under signed authorization is not a Section 3A offence; work done without it might be.

European Union — Directive 2013/40/EU and national implementations

The EU’s criminal framework for computer offences is Directive 2013/40/EU on attacks against information systems (replacing Council Framework Decision 2005/222/JHA). This directive requires member states to criminalize: illegal access to information systems (Article 3), illegal system interference (Article 4), illegal data interference (Article 5), and illegal interception (Article 6). Minimum maximum penalties are two years imprisonment across the board; member states implementing the directive have in most cases set significantly higher maximums. Germany’s Strafgesetzbuch § 202a (unauthorized data access) and § 303a/b (data sabotage) are representative national implementations. France’s Code Pénal Articles 323-1 through 323-7 implement similar coverage with maximum penalties up to three years for basic unauthorized access. The Directive also addresses tools: Article 7 requires member states to criminalize making, producing, selling, procuring, importing, distributing, or otherwise making available tools primarily designed or adapted for computer offences. The same s.3A logic applies here as in the UK.

NIS2 Directive (EU) 2022/2555: NIS2 is a cybersecurity regulatory framework — it defines security obligations for organizations operating essential and important services and digital infrastructure. It is not a criminal law framework for unauthorized access. NIS2 is relevant to pentesters indirectly: organizations subject to NIS2 must have security testing programs, and authorized penetration testing of NIS2-regulated entities may carry additional documentation and disclosure requirements. But NIS2 does not create a new criminal offence for unauthorized RFID emulation; that exposure comes from national implementations of Directive 2013/40/EU.

Canada

Canada’s Criminal Code § 342.1 (unauthorized use of computer) is the direct analogue: it criminalizes obtaining directly or indirectly computer services, or intercepting or causing to be intercepted a function of a computer, without authorization. Section 430(1.1) (mischief in relation to data) adds coverage for unauthorized modification of computer data. Penalties range from summary conviction to ten years on indictment. Like the U.S. and UK frameworks, the relevant offence is the unauthorized access, not the physical method.

Authorized-pentest defences vary by jurisdiction: Some jurisdictions (notably the UK, following the Crown Prosecution Service’s published guidance on CMA 1990 and the Cybercrime Convention context) recognize a specific “authorized pentest” posture in prosecutorial discretion guidance, while others do not. In practice, a signed authorization letter that clearly names the authorizing party and scope is the most portable and jurisdiction-resilient documentation instrument across all of the above frameworks. The letter does not make the law; it establishes the authorization that satisfies the statutory element in each jurisdiction’s version of the offence.

Recommendation for cross-border work: Before any engagement that involves operating the Chameleon Ultra in a jurisdiction where the operator is not a regular practitioner, obtain a brief written opinion from local counsel confirming the authorization framework, whether carrying security-testing tools requires notification to national authorities, and whether specific consent procedures for RF operation at 13.56 MHz or 125 kHz apply under local telecommunications regulations. The RF question is separate from the computer-crime question but can produce its own administrative exposure in jurisdictions with active spectrum management.

---

12.8 Cheatsheet — Chameleon Ultra field quick-reference

12.8.1 Hardware at a glance

Table 2 — 7.1 Hardware at a glance

Parameter	Value
SoC	nRF52840, ARM Cortex-M4F @ 64 MHz
Flash / RAM	1 MB flash / 256 KB RAM
HF reader IC	NXP MFRC522 (Ultra only; absent on Lite)
HF emulation	nRF52840 integrated NFC-A tag hardware
LF signal chain	nRF52840 PWM + peripherals (no dedicated LF IC)
HF slots	8 (ISO 14443A / 13.56 MHz)
LF slots	8 (125 kHz); each slot = one HF + one LF config
Battery	90 mAh LiPo; USB-C charged; ~6 months standby
Interfaces	BLE 5.0 (ChameleonUltraGUI) + USB-C CDC ACM CLI
HF read range	~3–4 cm (MFRC522; community measurement)
LF read range	~2 cm (nRF52840 LF path; community figure, not official spec)
HF data rate	ISO 14443A 106 kbit/s baseline; 847.5 kHz subcarrier
Firmware	GPL-3.0 · github.com/RfidResearchGroup/ChameleonUltra

Firmware version reference:

Table 3 — Firmware version reference:

Version	Date	Key additions
v1.0	2023-06-06	Factory firmware
v2.0.0	2023-09-26	StaticNested (MF1_STATIC_NESTED_ACQUIRE), NTAG21x, BLE pairing, 30× faster dump I/O
v2.1.0	2025-09-02	HardNested (PR #254), hf mf senested FM11RF08S backdoor (PR #263), HID Prox LF, T5577 write, Ultralight EV1/NTAG shadow mode, Docker build, parallel MFKEY32v2

Check current firmware: hw version

12.8.2 Slot management quick-reference

Core CLI commands:

Table 4 — Core CLI commands:

Command	Effect
hw slot list	Full slot inventory (type, anticollision data, LF ID, nicknames, enable state)
hw slot list --short	Compact inventory; includes LF ID + HF anticollision + nicknames (v2.1.0+)
hw slot type -s <n> -t <TYPE>	Set card type for slot n (HF: MIFARE_1024, MIFARE_4096, MIFARE_ULTRALIGHT; LF: EM410X)
hw slot init -s <n> -t <TYPE>	Initialize slot emulation memory to type defaults
hw slot enable -s <n> --hf	Enable HF emulation for slot n
hw slot enable -s <n> --lf	Enable LF emulation for slot n
hw slot disable -s <n> --hf	Disable HF without clearing configuration
hw slot change -s <n>	Make slot n the active slot
hw slot nick -s <n> --hf -n "label"	Set HF nickname for slot n (max 32 bytes UTF-8)
hw slot nick -s <n> --lf -n "label"	Set LF nickname for slot n
hw slot nick -s <n> --hf -d	Delete HF nickname
hw slot delete -s <n>	Delete slot configuration
hw factory_reset --force	Full reset to factory defaults (clears all slots)
hw version	Show firmware version string
hw mode -r	Switch device to reader mode (MFRC522 active)
hw mode -e	Switch device to emulator mode

Button behavior (default firmware):

Table 5 — Button behavior (default firmware):

Action	Result
Button A short press	Previous slot (wraps 1 → 8)
Button B short press	Next slot (wraps 8 → 1)
Button A or B long press	Opportunistic UID copy from detected RF field into active slot (Ultra only)

LED color → slot content:

Table 6 — LED color → slot content:

LED color	Content
Green	HF card loaded and enabled; LF side empty or disabled
Blue	LF card loaded and enabled; HF side empty or disabled
Red	Both HF and LF loaded and enabled in same slot
Off	Slot empty or both bands disabled

Factory-reset defaults: Slot 1 = EM4100 LF (ID DEADBEEF88) + MIFARE Classic 1K HF (UID DEADBEEF); Slot 2 = MIFARE Ultralight HF; Slot 3 = EM4100 LF (ID DEADBEEF88); Slots 4–8 = empty.

12.8.3 HF attack sequence and command reference

MIFARE Classic — attack routing decision tree:

1. hw mode -r
2. hf 14a scan                    → UID / ATQA / SAK
3. Known-key probe (GUI or CLI: hf mf rdbl with FFFFFFFFFFFF etc.)
     ↓ sector key found → jump to step 6 (Nested)
     ↓ no key found →
4. hf mf darkside                 → one key, unhardened cards
     ↓ DarkSide fails (hardened PRNG or FM11RF08S) →
5a. hf mf hardnested --blk <n> -k <key> --tblk <n> ...
                                  → MIFARE Classic EV1 / MIFARE Plus SL1 (v2.1.0)
5b. hf mf senested                → FM11RF08S static-encrypted-nonce backdoor
                                    (universal backdoor key A396EFA4E24F; v2.1.0, PR #263)
6. hf mf nested --blk <known-blk> -a -k <known-key> --tblk <target-blk> --ta
                                  → sweep remaining sectors from one known key
                                    (StaticNested auto-routed if static nT detected; v2.0.0)
7. hf mf rdbl -b <block> --key <key>   → read each block with recovered key
8. hf mf esave -s <slot> -f dump.bin -t bin   → export binary dump
9. hf mf eload -s <slot> -f dump.bin -t bin   → load dump into slot
   hw slot enable -s <slot> --hf

Key ATQA / SAK values for slot configuration:

Table 7 — Key ATQA / SAK values for slot configuration:

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

MIFARE Classic memory geometry:

Table 8 — MIFARE Classic memory geometry:

Variant	Sectors	Blocks	Dump size
1K	16 sectors × 4 blocks	64	1 024 bytes
4K	32 sectors × 4 blocks + 8 sectors × 16 blocks	256	4 096 bytes

Detection mode + MFKEY32 v2 workflow (when card is inaccessible — reader key recovery):

hw slot type -s <slot> -t MIFARE_1024
hw slot init -s <slot> -t MIFARE_1024
hf mf econfig -s <slot> --uid <hex-uid> --atqa <hex-atqa> --sak <hex-sak>
hf mf econfig --enable-log          # enable detection log
hw mode -e                           # emulator mode
# Present to legitimate reader — twice per sector key needed
hf mf elog                           # view accumulated nonces
hf mf elog --decrypt                 # run MFKEY32 v2 → recovered sector keys
# Propagate to remaining sectors:
hf mf nested --blk 0 -a -k <recovered-key> --tblk <next-sector-first-blk> --ta

Full load-to-slot sequence for a binary dump:

hw slot type -s <slot> -t MIFARE_1024   # or MIFARE_4096
hw slot init -s <slot> -t MIFARE_1024
hf mf eload -s <slot> -f dump.bin -t bin
hw slot enable -s <slot> --hf
hw slot change -s <slot>

12.8.4 LF emulation quick-reference

EM410x:

lf em410x scan                         # read EM410x fob into buffer (LF face, ~2 cm max)
hw slot type -s <slot> -t EM410X
hw slot init -s <slot> -t EM410X
lf em 410x econfig -s <slot> --id <10-hex-digit-id>
hw slot enable -s <slot> --lf
hw slot change -s <slot>

HID Prox (H10301 26-bit): Reading implemented; emulation confirmed at application layer but has known open bug (GitHub issue #325, December 2025): 6-byte RAW HID format causes reader field-detect without access-grant on some readers. For affected readers, write credential to T5577 blank via GUI “Write to T5577” function as fallback. Verify emulation against target reader before engagement.

T5577 write (from GUI): Navigate to LF slot → “Write to T5577” → place T5577 blank on LF antenna face (secondary PCB, reverse of USB-C face). Known write-failure issue #319 (opened 2025-11-07, open as of 2026-06); verify firmware release notes.

LF protocol application-layer status (as of v2.1.0):

Table 9 — LF protocol application-layer status (as of v2.1.0):

Protocol	Read	Write	Emulate	Notes
EM410x	✓	N/A	✓	Fully implemented
T5577	✓	✓	Via protocol	Write: see issue #319
HID Prox	✓	Via T5577	Experimental	See issue #325
Indala	HW/SW ✓	Via T5577	Not yet implemented	PSK1 modulation
FDX-B	HW/SW ✓	—	Not yet implemented	Requires 134.2 kHz for genuine implants; Ultra LF is 125 kHz only
Paradox	HW/SW ✓	—	Not yet implemented	FSK
AWD	HW/SW ✓	—	Not yet implemented	FSK
PAC/Stanley	HW/SW ✓	—	Not yet implemented	ASK
EM4305, Keri, ioProx, gallagher, Presco, + 6 more	HW/SW ✓	—	Not yet implemented	Check current releases

12.8.5 BLE app connection steps

ChameleonUltraGUI (Flutter; Android, iOS, macOS, Windows, Linux; github.com/GameTec-live/ChameleonUltraGUI):

1. Power on the Chameleon Ultra (button press or plug in USB-C).
2. Open ChameleonUltraGUI → navigate to the connect screen.
3. Scan for BLE devices; select the “Chameleon Ultra” or the BLE device name set via hw ble name.
4. Accept BLE pairing if prompted (pairing added in v2.0.0; the device generates a secure link key).
5. Session ready: the GUI home screen shows the device’s firmware version and slot grid.

Alternatively, connect over USB-C: device enumerates as USB CDC ACM serial (COM port on Windows, /dev/ttyACM* on Linux, /dev/cu.usbmodem* on macOS). The chasing-LED animation on the slot strip confirms an active serial session.

GUI firmware version and CLI firmware version must be compatible — confirm both before an engagement (hw version on device; check ChameleonUltraGUI app version in its info screen).

12.8.6 Common failure modes and fixes

Table 10 — 7.6 Common failure modes and fixes

Symptom	Most likely cause	Fix
hf 14a scan returns nothing	Wrong face (MFRC522 is on main PCB / HF face, not antenna PCB reverse)	Flip device; present HF coil face to card
LF read returns nothing	Card too far; wrong face (LF = secondary PCB / reverse of USB-C face)	Contact or ≤2 cm; orient LF face to card
DarkSide returns no key	Hardened PRNG (MIFARE Classic EV1) or FM11RF08S clone	EV1/Plus SL1 → HardNested; FM11RF08S → hf mf senested
Nested returns no additional keys	Known-key bootstrap incorrect, or static-nonce card	Re-verify bootstrap key; firmware auto-routes to StaticNested if static nT detected
Reader detects card but rejects it	ATQA or SAK mismatch, or UID length wrong	Run hf 14a info on original; verify slot econfig ATQA/SAK/UID length match
HID Prox emulation: LED blinks, no access	Issue #325 (6-byte RAW HID format)	Write to T5577 blank via LF write path; verify emulation on target reader first
T5577 write reports error	Issue #319 in some configurations	Check latest firmware release notes; use Proxmark3 RDV4 as backup write path
Detection mode: zero nonces after reader presentation	Detection log not enabled, or device not in emulator mode	hf mf econfig --enable-log + hw mode -e before presenting
Detection mode: reader grants access without nonces	UID-gated reader (no Crypto1 authentication)	MFKey32 path does not apply; UID-only slot is sufficient
Emulated slot rejected despite correct ATQA/SAK/UID	Anti-emulation timing or rolling-UID reader	Use physical Magic Gen2 or Gen3 blank; verify reader model in RRG issue tracker
Device does not respond to BLE after firmware update	DFU error state (LEDs 4–5 slow-blinking red)	Connect USB-C; nrfutil device program --firmware dfu-app.zip --traits nordicDfu
Slot data cleared unexpectedly	hw factory_reset --force or firmware downgrade across v2.0.0 format boundary	Restore from Saved Cards library in ChameleonUltraGUI

---

Glossary

Alphabetical A–Z glossary of RFID, NFC, Crypto1, and Chameleon-specific terms used across this series.

---

Anti-emulation check — a proprietary reader fingerprinting measure that distinguishes an emulated card response from a genuine passive silicon card. Implementations vary: some readers measure RF load-modulation characteristics (rise time, damping coefficient) that differ between a genuine NXP MIFARE Classic die and the nRF52840’s NFC-A hardware block; others probe with specific challenge sequences or test PRNG nonce patterns for repeatability. No exhaustive public list of readers with anti-emulation checks exists; the practical test is emulation success or failure against the target reader model. If a correctly configured slot with verified ATQA/SAK/UID/keys is consistently rejected by a specific reader, an anti-emulation check is the leading hypothesis. Mitigation: use a physical Magic Gen2, Gen3, or Gen4/UMC blank, whose RF behavior is native to a genuinely passive card.

Crypto1 — NXP’s proprietary stream cipher used to protect MIFARE Classic memory sectors. A 48-bit linear feedback shift register (LFSR) with a nonlinear filter function on top; introduced in the mid-1990s and kept secret by NXP until physically reverse-engineered from the chip die by Karsten Nohl, Starbug, and Henryk Plötz (CCC 2007/2008). The LFSR state is initialized from the 48-bit sector key and a 32-bit nonce; subsequent keystream bits protect both data and parity in the three-pass authentication protocol. Publicly broken by multiple attacks (DarkSide, Nested, StaticNested, HardNested, MFKEY32 v2) across the academic literature from 2008 onward. See Vol 3 §5.2 for the full cryptanalytic treatment.

DarkSide attack — a zero-knowledge Crypto1 key-recovery attack requiring no prior sector-key knowledge. Exploits a 4-bit NACK leakage: when the MFRC522 sends a deliberately malformed reader response during authentication, the card’s encrypted error reply leaks 4 keystream bits per exchange. Iterating with varied reader nonces constrains the 48-bit Crypto1 key space to O(2^16–2^20) candidates, each then verified by a normal authentication. Introduced by Nicolas Courtois (“The Dark Side of Security by Obscurity,” SECRYPT 2009). Precondition: the card must have the original unhardened MIFARE Classic PRNG (not MIFARE Classic EV1, not MIFARE Plus SL1 in AES mode, not FM11RF08S). Escalation paths: hardened PRNG (MIFARE Classic EV1) → HardNested; FM11RF08S → hf mf senested. Implemented in all Chameleon Ultra firmware releases; enhanced in v2.0.0 with LED feedback and parity handling fixes. CLI: hf mf darkside.

DESFire EV1/EV2 — NXP MIFARE DESFire family; the dominant high-security HF contactless card in enterprise access control. Full ISO 14443A-4 (T=CL) implementation with a filesystem-based application structure; 3DES mutual authentication (EV1) or AES-128 (EV2/EV3). No public cryptanalytic attack recovers DESFire application keys without the keys themselves. Chameleon Ultra capability: UID + ATQA (03 44) + SAK (0x20) emulation only, at 106 kbit/s; sufficient for UID-gated readers. A reader that proceeds to DESFire application authentication (SELECT APPLICATION / AUTHENTICATE APDUs) will receive no valid AES-authenticated response and will reject the emulated card. See Vol 4 §11 for the full emulation-scope treatment.

DFU (Device Firmware Update) — the nRF52840’s built-in USB bootloader for application firmware updates. Activated by hw dfu via CLI, the “Firmware Update” function in ChameleonUltraGUI, or hardware forced-DFU (hold Button B, replug USB). During DFU: device re-enumerates as a Nordic DFU target (not CDC ACM); CLI is unavailable. LED indicators: LEDs 4 and 5 alternating green = idle awaiting package; fast-blinking blue = write in progress (do not disconnect); slow-blinking red = error. Normal application updates use dfu-app.zip (preserves the bootloader partition); full recovery uses dfu-full.zip. Host tool: nrfutil from Nordic Semiconductor (not the deprecated pip nrfutil package). Slot data is preserved across normal DFU updates; only hw factory_reset --force or cross-format-boundary downgrade clears slots.

EM4XX / EM4100 — EM Microelectronic’s 125 kHz read-only LF transponder family (EM4100, EM4102, EM4200). The most widely deployed LF access-control credential worldwide. 64-bit frame: 9-bit all-ones header, 40-bit data field (8-bit version/customer code + 32-bit UID value), row and column parity bits, 1-bit stop. Manchester-encoded ASK at 64 carrier cycles per bit (≈1.95 kbit/s). Factory-programmed and read-only: the 64-bit ID cannot be modified in the field. Cloning requires writing the credential to a writable T5577 or EM4305 blank that emulates the same EM4100 output. Chameleon Ultra: fully implemented at all layers (read, emulate; LF brute-force is hardware/software ✓, application layer not yet confirmed in a current stable release — verify). See Vol 5 §3 for the protocol frame structure.

FDX-B — ISO 11784/11785 Full Duplex B; the international standard for animal microchip transponders. 128-bit total frame: 38-bit animal ID, 10-bit country code (ISO 3166), 16-bit CRC-16 checksum, plus control and status bits. Differential biphase (DBP) bit encoding; data rate fc/32. Critical hardware constraint: genuine ISO 11785 FDX-B implant chips operate at 134.2 kHz — not 125 kHz. The Chameleon Ultra’s nRF52840 LF path operates at 125 kHz only; it can handle FDX-B format data carried on a 125 kHz T5577 blank but cannot activate or read genuine 134.2 kHz implant chips. Application layer not yet implemented in v2.1.0. For genuine FDX-B implant work, use a Proxmark3 RDV4 or a dedicated veterinary microchip scanner.

HardNested attack — a Crypto1 key-recovery attack targeting cards with a hardened PRNG that defeats both DarkSide and standard Nested. Primary targets: NXP MIFARE Classic EV1 (SmartMX-based) and MIFARE Plus SL1. Introduced academically by Carlo Meijer and Roel Verdult (“Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards,” CCS 2015). Method: probabilistic bitwise analysis of encrypted nonce pairs across many re-authentication attempts, exploiting the Crypto1 LFSR’s linearity to build candidate-state tables. Requires one known sector key as a starting point. Not applicable to FM11RF08S (which uses a static encrypted nonce construction, not a hardened random PRNG — use hf mf senested instead). Implemented in Chameleon Ultra firmware v2.1.0 (PR #254). Runtime on the nRF52840 Cortex-M4F @ 64 MHz: community estimates of 30–90 minutes per sector for hardened EV1/Plus SL1; the Proxmark3 RDV4 tethered to a laptop completes the same attack faster. CLI: hf mf hardnested. See Vol 4 §7.

HID Prox — HID Corporation’s proprietary 125 kHz LF credential standard; the dominant LF access-control format in North American commercial installations. Physical layer: FSK2a modulation (sub-carriers at fc/8 ≈ 15.625 kHz and fc/10 ≈ 12.5 kHz), biphase bit encoding. Most common format: H10301 26-bit open format (8-bit facility code, 16-bit card number, 2 parity bits). Additional proprietary formats: 35-bit Corporate 1000, 37-bit H10302/H10304, and site-specific formats. Wiegand interface is a separate reader-to-panel protocol (two-wire DATA0/DATA1 current-loop bus) and is not the same as the card’s over-air FSK signal. Chameleon Ultra: reading ✓; emulation confirmed at application layer but has known bug (issue #325) with 6-byte RAW HID format on some readers. See Vol 5 §4.

Indala — proprietary 125 kHz LF format from Motorola (later acquired by HID Global/Allegion). Physical layer: PSK1 (Phase Shift Keying, subtype 1) — the card modulates sub-carrier phase rather than amplitude or frequency; 180-degree phase shift encodes a bit transition. Multiple bit-length variants (26-bit to 64-bit) across installation vintages. Common in older North American enterprise and some government access-control deployments. Chameleon Ultra: hardware/software layer ✓ (nRF52840 can generate/demodulate PSK1); application layer not yet implemented as of v2.1.0. Current confirmed tool for Indala read/emulation: Proxmark3 RDV4 with Iceman firmware (lf indala commands) or Flipper Zero.

ISO 14443A — the international air-interface standard for proximity contactless cards at 13.56 MHz (Type A variant). Defined in four parts: Part 2 specifies the physical layer (100% ASK modified Miller downlink at 106 kbit/s; fc/16 = 847.5 kHz subcarrier load-modulation Manchester uplink at 106 kbit/s); Part 3 specifies initialization and anticollision (REQA → ATQA → ANTICOLLISION → SELECT → SAK); Part 4 specifies the T=CL higher-level transmission protocol. All card families emulated by the Chameleon Ultra (MIFARE Classic, Ultralight, NTAG, DESFire, MIFARE Plus) are ISO 14443A Type A implementations. Type B (Calypso, some passports, EMV) uses a different physical layer and is out of scope for the Chameleon Ultra firmware. Higher data rates (212, 424, 848 kbit/s) are defined by the standard; the Chameleon Ultra emulates at the 106 kbit/s baseline. See Vol 3 §3–§4 for the full physics and protocol treatment.

LF (Low Frequency, 125 kHz) — the magnetic near-field band used for legacy access-control credentials. Inductive coupling (1/r³ field falloff); passive card powered by reader field; data rate typically 1–3 kbit/s. The Chameleon Ultra’s LF capability is implemented entirely via the nRF52840’s PWM, timer, comparator, and ADC peripherals driving a discrete LF analog front end on the secondary PCB — no dedicated LF reader IC. Practical read range: approximately 2 cm against typical fobs (community-measured figure on the Dangerous Things forum; no official spec published by RRG or Lab401 as of 2026-06). Emulation range is generally adequate for installed readers (designed for flush card presentation at 0–2 cm).

Magic Gen1a / Gen2 / Gen3 / Gen4 (UMC) — writable MIFARE Classic blank card generations that allow the UID and block-0 content to be programmed to arbitrary values:

• Gen1a: proprietary 40h (7-bit frame) + 43h unlock sequence before any block-0 write; 4-byte UID only; high detectability (any reader that sends the 7-bit probe identifies it).
• Gen2 (CUID): standard MIFARE write command to block 0, no backdoor unlock; 4-byte and 7-byte UID; medium detectability (write probe + nonce-pattern analysis).
• Gen3: APDU commands (90 F0 CC CC = write block 0; 90 FB CC CC = change UID only; 90 FD 11 11 = permanent lock — irreversible); ATQA/SAK auto-corrected to fixed values; 4-byte and 7-byte UID; low–medium detectability; permanent lock eliminates APDU-probe detectability entirely.
• Gen4/UMC: password-protected CF <pw> <op> configuration commands; fully configurable ATQA, SAK, ATS, UID length (4/7/10 byte), shadow mode; lowest detectability once password changed from factory 00000000. Chameleon Ultra can write all four generations via MFRC522 reader mode (hf 14a raw sequences); ChameleonUltraGUI supports Gen1a and Gen2 natively in “Write HF card” dialog; Gen3/Gen4 via MTools BLE App or CLI hf 14a raw APDUs. See Vol 10 §4–§6.

MFKEY32 v2 — Crypto1 key recovery from sniffed reader–card authentication exchanges. Input: two independent (nT, nR, aR) triples for the same sector key, captured during two separate reader authentication attempts. Method: XOR-and-LFSR-rollback to reverse the Crypto1 keystream and recover the 48-bit sector key. v2 improvement over v1: the two triples may come from any two independent authentication events (separated by hours or separate visits), not from consecutive authentications within one reader session. Computation runs host-side in ChameleonUltraGUI or via hf mf elog --decrypt; parallelized across CPU cores (v2.1.0). See §7.3 and Vol 6 §5 for the full workflow.

MFRC522 — NXP contactless reader/writer IC for 13.56 MHz ISO 14443A; present in the Chameleon Ultra only (absent on the Lite). Interfaces to the nRF52840 over SPI at up to 10 Mbit/s. Handles: 13.56 MHz carrier generation, 100% ASK modified Miller modulation for commands, 847.5 kHz subcarrier load-modulation demodulation for card responses, ISO 14443A anticollision and select, MIFARE Classic Crypto1 three-pass mutual authentication. 64-byte internal FIFO. Also supports 212/424/848 kBd higher rates. POWER_DOWN current approximately 10 µA (NXP MFRC522 datasheet Rev 3.9). The MFRC522 is what enables all HF card reading and all Crypto1 attacks on the Ultra; its absence on the Lite is the defining capability boundary between the two models. See Vol 2 §3.

MIFARE Classic — NXP’s dominant HF access-control card family; the primary target of the Chameleon Ultra’s attack suite. Memory organized into independently keyed sectors, each protected by a 48-bit Key A and 48-bit Key B with a 3-byte access-condition (ACL) field. 1K variant: 16 sectors × 4 blocks = 64 blocks total, 1 024 bytes. 4K variant: 32 sectors × 4 blocks + 8 sectors × 16 blocks = 256 blocks total, 4 096 bytes. Each block is 16 bytes; the final block of each sector is the sector trailer (Key A, ACL, user byte, Key B). Sector 0 Block 0 is the manufacturer block (UID, BCC, SAK, ATQA, manufacturer data); hardware-locked after manufacture on genuine NXP silicon. Crypto1 cipher is broken by all five Chameleon Ultra attacks. NTAG family tops at NTAG216 (no NTAG218). See Vol 3 §5 for the full sector structure and cipher analysis.

MIFARE DESFire — see DESFire EV1/EV2 above.

MIFARE Plus — NXP backward-compatible successor to MIFARE Classic; three security levels. SL1: Crypto1-compatible — memory layout and cipher identical to MIFARE Classic 1K or 4K, same ATQA/SAK; the full Chameleon Ultra attack suite applies. SL2: AES-128 authentication, Crypto1 data transport — transition mode; AES keys not obtainable by public attack. SL3: AES-128 end-to-end (authentication and data); UID emulation only on the Chameleon Ultra; no public key recovery attack. Chameleon Ultra: full attack suite applies to SL1; UID-layer emulation only for SL2/SL3. Many deployed “MIFARE Plus” cards remain in SL1 because the migration step requiring AES master-key injection was never performed. See Vol 4 §12.

MIFARE Ultralight / NTAG — minimal-overhead HF card families without Crypto1. ISO 14443A-3 NFC Forum Type 2 tags (ATQA 00 44, SAK 00). Security: OTP lock bits (prevent post-manufacture write modification); optional 32-bit PWD/PACK password on EV1 and NTAG variants (transmitted in cleartext during PWD_AUTH, vulnerable to sniffed-transaction recovery). NTAG 21x user memory range: NTAG210 = 48 bytes, NTAG212 = 128 bytes, NTAG213 = 144 bytes, NTAG215 = 504 bytes, NTAG216 = 888 bytes. Chameleon Ultra: full emulation for NTAG 210–216 (application layer ✓ in v2.0.0+); MIFARE Ultralight EV1 and NTAG shadow mode added in v2.1.0. See Vol 4 §10.

Nested attack — Crypto1 key recovery using one known sector key as a bootstrap to recover all remaining sector keys on the same card. Exploits the Crypto1 PRNG’s nonce predictability: the MFRC522 authenticates to the known sector, then issues re-authentication requests for unknown sectors while the session is running; the encrypted nonce for the second authentication is predictable from timing, enabling offline key search. Introduced by Garcia, van Rossum, Verdult, and Wichers Schreur (IEEE S&P 2009). Typical runtime: seconds to minutes per sector on a MIFARE Classic 1K with one known default key. CLI: hf mf nested. The firmware auto-routes to StaticNested when a static nT is detected. See Vol 3 §5.3 and Vol 4 §5.

nRF52840 — Nordic Semiconductor’s ARM Cortex-M4F system-on-chip; the Chameleon Ultra’s central compute platform. 64 MHz clock; 1 MB internal flash / 256 KB RAM; 55 nm process node. Integrated: BLE 5.0 (2.4 GHz), NFC-A tag hardware interface (13.56 MHz card emulation), USB 2.0 Full Speed (12 Mbit/s); SPI (×4), I²C (×2), PWM (×4), 12-bit ADC, comparators. Role in dual-band operation: (1) integrated NFC-A hardware block handles HF card emulation; (2) MFRC522 controlled over SPI for HF reading (Ultra only); (3) PWM + comparator/ADC peripherals drive and sense the entire LF signal chain. Shared across Ultra and Lite; firmware conditional compilation gates MFRC522-dependent features. See Vol 2 §2.

OTA (Over-The-Air update) — firmware update transferred via BLE through ChameleonUltraGUI, using the Nordic DFU protocol. The GUI sends hw dfu, the device reboots into the DFU bootloader, and the GUI transfers the signed .zip firmware package. Recommended to keep device on USB-C power during OTA transfer (charging and BLE operate concurrently per Vol 2 §8). Slot data is preserved across OTA updates; the DFU process explicitly does not overwrite the user-data flash region. Only hw factory_reset --force or GUI “Factory reset” clears slot data.

PAC/Stanley — proprietary 125 kHz LF format from PAC (a UK brand, now part of Stanley Security); ASK modulation. Common in UK and European commercial access-control installations. Chameleon Ultra: hardware/software layer ✓; application layer not yet implemented as of v2.1.0. Current confirmed tool: Proxmark3 RDV4 with Iceman firmware. See Vol 5 §7.3.

Paradox — Paradox Security Systems proprietary 125 kHz LF access-control format; FSK modulation; facility code range 1–254; common in mid-range residential and light-commercial alarm and access-control panels (C704 teardrop and C705 clamshell fob form factors). Chameleon Ultra: hardware/software layer ✓; application layer not yet implemented as of v2.1.0. Current confirmed tool: Proxmark3 RDV4 with Iceman firmware (lf paradox commands). See Vol 5 §7.2.

RRG / Proxgrind — RfidResearchGroup (RRG) is the firmware-maintainer consortium behind the Chameleon Ultra firmware (github.com/RfidResearchGroup/ChameleonUltra, GPL-3.0); the same group maintains the Proxmark3 Iceman firmware. Proxgrind is the hardware manufacturer and primary distributor for the Chameleon Ultra and Lite. Both are credited in the device ecosystem; the firmware and hardware are co-developed but maintained separately. Lab401 is the European retail distributor. @doegox is the primary firmware maintainer as of 2026-06 (most changelog entries across v2.0.0 and v2.1.0). See Vol 9 §1.

Sector trailer — the final block of every MIFARE Classic sector; not a data block. 16-byte layout: [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 under a correctly programmed ACL (reads return zeroes). The 3-byte access-condition (ACL) field governs which operations Key A and Key B can authorize, on a per-block and per-operation basis (read, write, increment, decrement, transfer). An incorrectly programmed ACL can permanently lock a sector. In the sector dump, the sector trailer appears as block 3 for each 4-block sector in a 1K card, and block 3 or block 15 depending on sector index in a 4K card. See Vol 3 §5.1.

Slot (emulation slot) — one of the eight numbered positions in the Chameleon Ultra’s dual-band slot architecture. Each slot is a compound record: an HF configuration (card type, UID, ATQA, SAK, full memory dump) and an LF configuration (protocol family, credential ID), held independently. Both sides of a slot can be populated simultaneously; a slot carrying a MIFARE Classic 1K HF credential and an EM4100 LF credential responds to HF readers on its HF face and to LF readers on its LF face without reconfiguration. Slot data persists in the nRF52840’s 1 MB internal flash across power cycles, DFU updates, and BLE disconnection; only hw factory_reset --force or an incompatible firmware downgrade clears it. See Vol 7 §1.

Sniff mode / detection mode — in the Chameleon Ultra’s architecture, the functional equivalent to sniffing is detection mode: the device emulates a target card’s UID (loaded in a slot with hf mf econfig --uid ...), enables the nonce log (hf mf econfig --enable-log), and enters emulator mode (hw mode -e). When a legitimate reader attempts Crypto1 authentication, the (nT, nR, aR) exchange is logged even though authentication fails. Two such log entries per sector key are sufficient for MFKEY32 v2 recovery via hf mf elog --decrypt. Note: the hf 14a sniff command exists in the CLI but has a documented bug in v2.1.0-series (GitHub issue #444: encrypted block responses captured incorrectly after authentication); use detection mode for key-recovery nonce logging, not hf 14a sniff. See Vol 6 §1.2 and §4.

StaticNested attack — a variant of the Nested attack targeting MIFARE Classic cards whose PRNG seed is fixed at every power cycle — the same plaintext nonce nT appears regardless of authentication timing. This static plaintext nonce condition (distinct from the FM11RF08S static encrypted nonce construction) enables a faster “2NT Fast Decrypt” recovery path. Implemented as MF1_STATIC_NESTED_ACQUIRE in Chameleon Ultra firmware v2.0.0 (2023-09-26); auto-routed transparently within hf mf nested when the firmware detects a static nT across power cycles — no separate command is required. Occurs in some OEM card manufacturing environments where cards are programmed in a fixed-timing environment. StaticNested is not the same as hf mf senested: senested targets the FM11RF08S static encrypted nonce construction (a qualitatively different and more resistant defense) via a universal backdoor key (A396EFA4E24F), introduced in v2.1.0 (PR #263, Quarkslab 2024 disclosure). See Vol 4 §6 for StaticNested and Vol 4 §4.3 for the senested distinction.

T5577 — Atmel/Microchip ATA5577C; the dominant writable 125 kHz LF blank chip and the universal clone target for deployed LF credentials. Memory: eight 32-bit blocks. Block 0 = configuration register (selects modulation: ASK/FSK/PSK; sub-carrier ratio; bit rate; target protocol format); Blocks 1–6 = credential data payload; Block 7 = optional 32-bit write-protect password. By writing the correct Block 0 configuration and the target credential ID into Blocks 1–6, a T5577 presents identically to an EM4100, HID Prox, Indala, or other LF format when interrogated by a reader. Password space: 2^32 (~4.3 billion combinations); brute-force is hardware/software ✓, application layer not yet confirmed in a stable release — verify against current firmware before planning around it. Write reliability: see GitHub issue #319 (write-failure in some configurations, open as of 2026-06). The Chameleon Ultra does not emulate a T5577 chip per se; it emulates the underlying protocol (EM410x, HID Prox) that the T5577 emits when programmed to that format. See Vol 3 §6.3 and Vol 5 §5.

UID (Unique Identifier) — the ISO 14443A card identifier transmitted in the clear during anticollision; the first data element a reader obtains from any card. Three sizes defined by the standard: 4-byte (single-size, single SELECT cascade level; ATQA bit-6 = 0); 7-byte (double-size, two SELECT cascade levels; ATQA bit-6 = 1); 10-byte (triple-size, three cascade levels; rare in access-control contexts). In MIFARE Classic, the UID occupies the first four bytes of Block 0 in Sector 0 (the manufacturer block); the fifth byte is the BCC (Block Check Character = XOR of the four UID bytes). On genuine NXP MIFARE Classic cards, Block 0 is hardware-locked after manufacture. The Chameleon Ultra’s firmware allows any UID to be programmed into any slot without hardware restriction, since the slot is software state rather than a silicon fuse. UID correctness (matching the original card’s UID) is prerequisite to authentication success on any system that passes the UID to the access-control panel.