Chameleon Ultra · Volume 12

Chameleon Ultra — Legal, Ethics, Cheatsheet, and Glossary

The legal envelope for RFID emulation work, the field cheatsheet, and a glossary of terms used in this series

Stub — section skeleton authored 2026-06-27; prose to follow.

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 [VERIFY]
  7. Cheatsheet — Chameleon Ultra field quick-reference
  8. Glossary

State the single governing principle for all work covered in this series: only use the Chameleon Ultra against systems you own outright or for which you hold current written authorization from the system owner; anything else is unauthorized access regardless of the technical method. Cross-link: ../../_shared/legal_ethics.md — the project-wide statement.

Explain why RFID emulation occupies the same legal space as any other unauthorized access method — the relevant statutes (CFAA in the US; Computer Misuse Act analogues elsewhere) do not exempt technical means; emulation is access regardless of whether a physical credential is used.

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

Note that the device has no awareness of authorization context; the operator bears full responsibility for ensuring each use falls within the authorized scope, and the device’s open-source nature does not confer any legal permission.

Introduce the four sub-sections as a use-case taxonomy moving from clearly authorized to clearly out-of-scope.

12.5.1 Authorized pentest with signed scope

Describe the gold-standard posture: a signed statement of work naming the facilities, card systems, and dates in scope; what “signed scope” must include to be meaningful (specific locations, specific infrastructure, emergency-contact chain).

12.5.2 Facility-owner self-audit

Describe the scenario where the operator is the facility owner auditing their own access-control infrastructure; note that ownership simplifies the authorization question but does not remove the need for documentation (insurance, staff communication, avoid police response).

12.5.3 Red-team engagement

Describe the red-team context: operator acting on behalf of a client under a master services agreement; note that the physical presence of the Chameleon Ultra on a red-team op without a get-out-of-jail letter is a significant risk even if the engagement is authorized — carry documentation.

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

Explicitly enumerate the categories that are out of scope for any engagement regardless of authorization: payment card emulation (card fraud statutes apply independently of access-control law), transit fare evasion, government-issued credential emulation (identity document statutes). These are hard lines.

12.6 Engagement documentation — what to carry

List the minimum documentation set for field operations: authorization letter with scope and dates, emergency-contact number for the client’s security team, operator’s own contact card, and any site-specific badging or visitor credentials; note that documentation on a phone is acceptable but a printed copy is more defensible.

12.7 International variations [VERIFY: UK Computer Misuse Act, EU directives, applicable statutes]

Survey jurisdiction-specific considerations beyond US CFAA: UK Computer Misuse Act 1990 (s.1 unauthorized access, s.3A making/supplying tools); EU NIS2 and member-state computer-crime directives; note that “authorized pentest” defenses vary in strength by jurisdiction and legal counsel is recommended before cross-border work.

12.8 Cheatsheet — Chameleon Ultra field quick-reference

Prose note: to be a laminate-ready single-page summary — slot management, key attack sequence, BLE app steps, common failure modes; structure as a two-column layout with command references and decision trees; authored during the prose pass, not here.

Skeleton sub-sections:

Slot management quick-reference — List the core BLE app and CLI commands for activating, naming, loading, and exporting slots.

HF attack sequence — Summarize the read → Crypto1 key recovery (DarkSide / Nested / HardNested) → dump → load-to-slot flow in five steps.

LF emulation quick-reference — List the protocol-family detection and slot-load steps for the most common LF targets (EM4100, HID Prox, T5577).

BLE app connection steps — Document the connect → authenticate → session-ready flow for ChameleonUltraGUI.

Common failure modes and fixes — Table of the most frequent field failures (BLE drops, slot not activating, reader rejection) with likely causes and corrective steps.

Glossary

Alphabetical glossary of RFID, NFC, Crypto1, and Chameleon-specific terms used across this series; to be populated during the prose pass.

Skeleton entries (fill in definitions during prose authoring):

Anti-emulation check — [define]

Crypto1 — [define]

DarkSide attack — [define]

DESFire EV1/EV2 — [define]

DFU (Device Firmware Update) — [define]

EM4XX / EM4100 — [define]

FDX-B — [define]

HardNested attack — [define]

HID Prox — [define]

Indala — [define]

ISO 14443A — [define]

LF (Low Frequency, 125 kHz) — [define]

Magic Gen1a / Gen2 / Gen3 — [define]

MFKEY32 v2 — [define]

MFRC522 — [define]

MIFARE Classic — [define]

MIFARE DESFire — [define]

MIFARE Plus — [define]

MIFARE Ultralight / NTAG — [define]

Nested attack — [define]

nRF52840 — [define]

OTA (Over-The-Air update) — [define]

PAC/Stanley — [define]

Paradox — [define]

RRG / Proxgrind — [define]

Sector trailer — [define]

Slot (emulation slot) — [define]

Sniff mode — [define]

StaticNested attack — [define]

T5577 — [define]

UID (Unique Identifier) — [define]