Chameleon Ultra · Volume 1
Chameleon Ultra — Overview, Decision Graph & Series Guide
What it is, where it sits in the RFID toolkit, the read→emulate value proposition, and how to navigate this series
1.1 What this series is
This is the Chameleon Ultra deep dive — twelve volumes covering RRG/Proxgrind’s open-source handheld RFID/NFC emulator from end to end. The reader is assumed to be an engineer doing authorized physical-pentest work or access-control audit: someone who has already worked with RFID at the conceptual level, understands the difference between LF and HF protocols, and is looking for a rigorous operational and technical reference rather than a getting-started walkthrough. The series builds from hardware and protocol fundamentals through the complete operational workflow, then out to the ecosystem, firmware, comparisons, and the legal envelope.
The Chameleon Ultra occupies a specific and unusual position in the RFID toolkit. It is not a clone-to-blank device in the way the iCopy-X is, and it is not a protocol-research instrument in the way the Proxmark3 RDV4 is. It is an emulator first — a device that loads the bitwise identity of a card into one of its sixteen slots and presents that identity to any reader that interrogates it, without ever committing the clone to a physical blank. That posture opens a distinct class of field workflows: emulate multiple cards from a single device that fits behind a credit card in a jacket pocket, switch slots via a BLE-connected phone, iterate on key-recovery attacks in the field without burning blank-card inventory, and leave no physical artifact after an engagement closes. The series covers all of this in depth.
The twelve volumes are:
Table 1 — The twelve volumes are
| Vol | Title |
|---|---|
| 1 | Overview, decision graph, series guide (this volume) |
| 2 | Hardware tour — nRF52840, MFRC522, dual-band analog front end, button/LED/battery/antenna; Ultra vs Lite |
| 3 | RFID/NFC primer — condensed; cross-link to iCopy-X’s primer |
| 4 | HF emulation & attacks — ISO 14443A, MIFARE Classic (Crypto1 attack suite), Ultralight, NTAG; the 8 HF slots |
| 5 | LF emulation — 125 kHz (EM410x, HID Prox, T5577); the 8 LF slots |
| 6 | Read / sniff / clone workflow — read a card → emulate it; sniffing; MFKey32 key recovery |
| 7 | Slot management & card organization — 8+8 slot architecture; naming, ordering, exporting |
| 8 | Working with other tools — Proxmark3 RDV4, iCopy-X, Flipper Zero, Cardputer ADV, Cardputer Zero, ChameleonUltraGUI |
| 9 | Firmware & open-source ecosystem — RRG/Proxgrind firmware, community forks, update workflow |
| 10 | Card stock & magic cards — interplay with physical blanks; cross-link to iCopy-X’s magic-card volume |
| 11 | Comparison — vs Proxmark3 RDV4, iCopy-X, Flipper Zero, Chameleon Lite — when each wins |
| 12 | Legal/ethics, cheatsheet & glossary |
The series is designed to be read end-to-end on the first pass. For experienced operators returning to a specific question, Vol 4 (HF attack depth), Vol 8 (tool workflow integrations), Vol 11 (comparison and purchase justification), and Vol 12 (the laminate-ready cheatsheet) are the highest-density reference volumes for day-to-day field work. The hardware and primer volumes (2 and 3) are read once and consulted when a troubleshooting question requires going back to the physics.
1.2 What the Chameleon Ultra is, briefly
The Chameleon Ultra is a credit-card-thin RFID/NFC emulator produced by RRG/Proxgrind — the same group that maintains the Proxmark3 Iceman firmware, the dominant open-source RFID research firmware in the field. The device carries sixteen independent card slots (eight for HF at 13.56 MHz and eight for LF at 125 kHz) in a pocketable package measuring approximately 2.4 × 4.0 × 0.8 cm. It has no screen, no keypad, and no standalone UI; all control is exercised through a BLE connection to the ChameleonUltraGUI application (Android, iOS, and desktop) or through a USB-C serial command interface. A single physical button and an RGB LED on the device face provide minimal local feedback — button press cycles the active slot, LED color indicates the current state. The LiPo battery is 90 mAh, USB-C charged, with a standby life measured in months rather than hours.
The core MCU is Nordic Semiconductor’s nRF52840: an ARM Cortex-M4 running at 64 MHz with 1 MB of flash and 256 KB of RAM, supplemented by integrated BLE 5.0. The dual-band RF capability comes from two distinct paths. HF (13.56 MHz, ISO 14443A) is handled by a dedicated MFRC522 reader frontend chip, which gives the Ultra the ability to both emulate HF cards and actively read and write to HF tags it interrogates — a capability the Chameleon Lite (the sibling emulation-only device) lacks, because the Lite has no MFRC522. LF (125 kHz) is handled through the nRF52840’s own analog front-end path. The firmware is GPL-3.0 open source on GitHub under RfidResearchGroup/ChameleonUltra; the open-source nature of the full stack distinguishes the Ultra from the iCopy-X’s closed application layer, and it means that the firmware’s claimed capabilities are directly verifiable against the source and actively extended by the community.
The HF emulation suite covers ISO 14443A in depth: MIFARE Classic 1K, 2K, and 4K (both 4-byte and 7-byte UID), MIFARE Ultralight, NTAG 210 through 218, MIFARE DESFire EV1/EV2, and MIFARE Plus. The Crypto1 attack suite for MIFARE Classic key recovery includes MFKEY32 v2, DarkSide, Nested, StaticNested, and HardNested — five complementary attack paths that together cover virtually the full range of deployed MIFARE Classic key configurations. The LF suite covers the protocol families that account for the vast majority of deployed 125 kHz access-control credentials: EM4XX, T5577, HID Prox, Indala, FDX-B, Paradox, AWD, and PAC/Stanley — approximately 99% of deployed 125 kHz chipsets per the vendor’s documentation. T5577 brute-force password cracking and UID brute-force round out the LF attack capability.
Table 2 — 2. What the Chameleon Ultra is, briefly
| Parameter | Value |
|---|---|
| MCU | nRF52840, ARM Cortex-M4 @ 64 MHz |
| Flash / RAM | 1 MB / 256 KB |
| HF | 13.56 MHz, ISO 14443A — 8 slots |
| LF | 125 kHz — 8 slots |
| HF reader frontend | MFRC522 |
| Crypto1 attacks | MFKEY32 v2, DarkSide, Nested, StaticNested, HardNested |
| Battery | LiPo 90 mAh; USB-C charge |
| Standby life | ~6 months |
| Control | BLE (ChameleonUltraGUI) + USB-C CLI |
| Firmware | GPL-3.0 open source (RfidResearchGroup/ChameleonUltra) |
| Form factor | ~2.4 × 4.0 × 0.8 cm |
1.3 The read→emulate value proposition
The Chameleon Ultra’s workflow loop is: read a card into a slot, then present that slot’s contents to any reader that interrogates it. The read step uses the MFRC522 frontend to interrogate the target card — collecting its UID, sector keys (via the Crypto1 attack suite if the keys are not known), and full memory contents where readable. That data is loaded into one of the eight HF slots (or LF slots for LF targets). From that point forward, the Ultra answers any reader query for that card identity as if it were the original card, without the original card being present. The entire sequence — read to emulate — can be completed in the field, in the time it takes the BLE app to transfer the dump, without any physical blank card stock.
The contrast with the clone-to-blank model — the approach the iCopy-X uses — is operationally significant. When a card is cloned to a blank, the result is a physical object: a T5577 or MIFARE Magic Gen2 card that persists after the engagement ends. That physical object can be lost, confiscated, or left behind. The Ultra’s emulation posture leaves no physical artifact; when the engagement closes and the slot is cleared, there is nothing to recover. There is also no blank-card inventory to manage and no per-clone cost. An operator who needs to emulate a MIFARE Classic 1K site badge, a HID Prox door credential, and a T5577-cloned LF fob simultaneously carries all three in sixteen combined slots on a single device that is thinner than a credit card — rather than carrying a stack of blanks and hoping the right chemistry matches the target reader’s expectation on the first try.
The BLE application is the field interface for slot management. ChameleonUltraGUI exposes slot selection, slot naming, dump import and export, firmware update, and the full Crypto1 attack suite in a mobile-friendly UI. Because the control surface is a phone rather than a physical keypad or LCD, the device benefits from the phone’s screen real estate, persistent configuration history, and cloud backup of card dumps — at the cost of requiring the phone to be in range during active slot switching. For environments where phone use is restricted or BLE is actively jammed, the USB-C CLI provides a serial command interface that covers the same capabilities from a connected laptop. The single on-device button cycles slots in a fixed order when no BLE connection is active, which covers the narrowest possible standalone use case.
1.4 Decision graph — when the Chameleon Ultra wins, when something else wins
The Chameleon Ultra is the right tool when the task is emulation — specifically, when presenting a card identity to a reader without materializing that identity on a physical blank is the requirement. Outside emulation-centric workflows, other tools are better optimized, and an experienced operator chooses based on the task requirement rather than on which device is already in the bag.
What is the task?
Emulate a captured card against a reader, in the field,
without committing it to a physical blank?
--> Chameleon Ultra. This is its native use case.
8 HF + 8 LF slots means the operator carries
a full engagement card set in one sub-credit-card device.
Carry multiple distinct card identities simultaneously
and switch between them via a BLE app?
--> Chameleon Ultra. Its 16-slot architecture and BLE
slot-switching are specifically designed for this.
Need to recover MIFARE Classic keys in the field via
Crypto1 attacks (DarkSide, Nested, HardNested, MFKEY32)?
--> Chameleon Ultra has the full suite on-device.
For the most compute-intensive attacks (HardNested),
the nRF52840 is slower than a tethered Proxmark3 RDV4,
but the on-device capability is sufficient for typical
field deployments.
Clone a card to a durable physical blank — a T5577 or
a MIFARE Magic Gen2 — that survives without a phone nearby?
--> iCopy-X. The iCopy-X's push-button Auto Clone mode
to physical blanks is faster and more reliable for
this specific task. The Ultra can emulate but cannot
write to blank card stock.
Lab-grade key recovery, exotic protocol research, scripted
batch attacks, or work on non-ISO-14443A HF protocols
(ISO 15693, iCLASS SE/SEOS, FeliCa, Legic)?
--> Proxmark3 RDV4 with the open client SDK.
The Ultra covers the mainstream ISO 14443A attack
surface; the Proxmark3 covers the research frontier.
Multi-modal capability — sub-GHz, IR, BadUSB, GPIO,
BLE attacks — alongside RFID emulation?
--> Flipper Zero. Its RFID emulation capability is a
subset of the Ultra's (smaller antennas, fewer
attack protocols, no MFRC522 reader chip), but its
breadth across six radio/hardware domains is what
justifies it.
Emulation only, no reader needed, smallest/cheapest device,
button-cell battery for very long standby?
--> Chameleon Lite (same RRG family). The Lite is
emulation-only (no MFRC522 reader chip), runs on a
button cell, and costs less than the Ultra. Choose
the Lite when the use case is purely presenting
a pre-loaded identity, never reading or attacking
a live target card.
Just need to copy a HID Prox UID to a T5577 blank,
no key recovery, no emulation?
--> A $30 AliExpress UID duplicator does this in
ten seconds. The Ultra is overkill for UID-only
LF clone tasks with no attack requirement.The correct mental model is that the Chameleon Ultra covers the emulation-centric half of the physical-pentest RFID workflow, and the iCopy-X covers the clone-to-physical-blank half. They are complementary, not redundant. An operator with both handles every mainstream access-control scenario. An operator with only the Ultra cannot leave a physical artifact; an operator with only the iCopy-X cannot iterate on slot configurations without burning blank stock. The Proxmark3 RDV4 sits above both as the research instrument for the cases that require it.
1.5 Where this fits in the Hack Tools lineup
The Chameleon Ultra is one of four RFID/NFC-capable tools covered in the Hack Tools hub, and it is the only one whose primary posture is emulation rather than cloning, passive scanning, or research scripting. Understanding where the Ultra sits relative to its siblings clarifies when to reach for it and when to reach for something else.
The iCopy-X is the most direct complement. Where the Ultra’s strength is loading a card dump into a slot and presenting it indefinitely to readers without physical media, the iCopy-X’s strength is writing that same dump to a T5577 blank, a MIFARE Magic Gen2, or an iCLASS-compatible blank and handing it off as a physical credential. The iCopy-X has an LCD, a physical keypad, and standalone operation; it does not need a phone nearby once the clone operation is complete. The Ultra needs the BLE app for slot management but leaves no physical artifact when the engagement closes. The two tools together — Ultra for emulation and field attack iteration, iCopy-X for final clone production — form a complete portable RFID workflow. Vol 6 of this series covers the read→emulate loop in detail; the iCopy-X’s Vol 9 covers the blank-card ecosystem for when the physical-clone step is required.
The Proxmark3 RDV4 is the lab reference instrument. The Proxmark3 open client SDK (the Iceman fork, which is also the lineage the Chameleon Ultra firmware traces) supports every RFID protocol in research scope, custom scripting, batch automation, and the full exotic-protocol roster including iCLASS SE/SEOS, ISO 15693, FeliCa, Legic, and HITAG 2. The Ultra covers the mainstream ISO 14443A attack surface — the Crypto1 suite, the common LF protocol families — in a field-ready form factor; the Proxmark3 covers the research frontier in a laptop-tethered form factor. When an engagement turns up a card technology outside the Ultra’s scope, the Proxmark3 is the tool to bring to the bench. Vol 8 of this series covers the handoff workflow between the two in operational detail.
The Flipper Zero overlaps with the Ultra on RFID capability but serves a different purpose in the lineup. The Flipper’s RFID and NFC subsystems — smaller antennas, lower transmit power, no dedicated reader chip — cover a subset of what the Ultra does, and they do it less well. What justifies the Flipper is its breadth: sub-GHz RF (with the CC1101 transceiver), infrared, BadUSB via HID injection, GPIO, and a plugin ecosystem that extends those capabilities substantially. An operator who needs RFID emulation as the primary task carries the Ultra; an operator who needs five different RF modalities on one device carries the Flipper. They are not the same tool aimed at the same target.
The Chameleon Lite (same RRG family, same firmware lineage, same GitHub repo) is the emulation-only member of the family. The Lite lacks the MFRC522 reader chip, so it cannot actively read or attack a target card — it can only present a pre-loaded dump. It runs on a button cell, which makes its standby life dramatically longer than the Ultra’s 90 mAh LiPo, and it costs less. The Lite is appropriate for scenarios where the operator has already captured and processed a card dump elsewhere and needs a small, long-standby device to present it. The Ultra is appropriate for scenarios where the operator needs to read, attack, and then emulate in a single field session. Vol 11 of this series covers the Ultra-vs-Lite trade-off in depth, with a complete comparison table across all four sibling tools.
For readers who need the RFID physics primer before diving into the Ultra’s protocol and attack coverage — the carrier-frequency physics, the ISO 14443A frame structure, the Crypto1 cipher architecture, the modulation schemes — the iCopy-X Vol 3 RFID primer at ../../iCopy-X/02-inputs/volume_sources/vol3.md is the authoritative reference in this hub. Vol 3 of this series is a condensed treatment that cross-links to that primer rather than duplicating it.
The cross-cutting shared references that apply across all RFID tools in the hub are ../_shared/comparison.md for the full cross-tool decision matrix and ../_shared/legal_ethics.md for the baseline lab-discipline rules that govern all authorized-access-testing work here.
1.6 How to use this series day-to-day
On the first read-through, the volumes are sequenced to build understanding progressively: hardware grounding in Vol 2, protocol context in Vol 3, HF and LF capability depth in Vols 4 and 5, the operational workflow in Vols 6 and 7, tool integrations in Vol 8, firmware and ecosystem in Vol 9, physical card interplay in Vol 10, comparisons in Vol 11, and legal/cheatsheet in Vol 12. Reading end-to-end the first time builds the mental model that makes subsequent spot-checks fast.
For day-to-day use after the first pass, the load-bearing reference volumes are organized by workflow stage. Before an engagement, Vol 11 (comparison and justification) and Vol 12 (legal posture and the cheatsheet) are the pre-flight volumes — confirm the Ultra is the right tool for the scope and confirm the authorization documentation is in order. During an engagement, Vol 6 (the read→emulate workflow and MFKey32 key recovery) and Vol 7 (slot management) are the operational references; the Vol 12 cheatsheet is the laminate to keep accessible. When a card technology appears that requires deeper protocol understanding, Vol 4 (HF) or Vol 5 (LF) is the reference for the specific tag family in question.
When another tool in the lineup is part of the workflow — passing a card dump from the Proxmark3 RDV4 into a Chameleon Ultra slot, or using the ChameleonUltraGUI alongside the iCopy-X for a multi-step engagement — Vol 8 (Working with other tools) is the integration reference. It covers the specific data-exchange formats, the import/export workflow between tools, and the ChameleonUltraGUI cross-tool features.
When the firmware is updated, revisit Vol 9 (Firmware and open-source ecosystem) for the update workflow and check the RRG/ChameleonUltra GitHub changelog for capability additions. The firmware is actively developed; new tag family support and attack improvements ship regularly, and a stale mental model of what the device can do has cost field time on more than one engagement.
1.7 Resources
The authoritative firmware and documentation repository is the RRG/Proxgrind GitHub:
- Firmware and documentation: https://github.com/RfidResearchGroup/ChameleonUltra
- BLE control application (ChameleonUltraGUI): https://github.com/GameTec-live/ChameleonUltraGUI
The ChameleonUltraGUI repository is maintained separately from the firmware and covers Android, iOS, and desktop (Windows/macOS/Linux) builds. Installation and update procedures for both are covered in Vol 9.
Authorized distributors include Lab401 (https://lab401.com) and others [VERIFY current distributor list]. Lab401 is the same distributor that carries the iCopy-X and Proxmark3 RDV4 in the EU/global market; their Chameleon Ultra listing includes the current firmware version and shipping region notes.
Local resources for this subproject are in 05-resources/ — populate this directory after device acquisition with the vendor product page PDF, firmware release notes, and any application notes from the GitHub wiki. The directory structure mirrors the iCopy-X subproject layout.
Sibling tool references within this hub:
- iCopy-X Vol 3 RFID primer — the hub’s authoritative RFID/NFC physics reference; read before diving into Vols 3–5 of this series if the carrier-frequency and modulation fundamentals need grounding
- Proxmark3 RDV4 — the lab reference instrument for protocol research outside the Ultra’s scope
- Flipper Zero — the multi-modal counterpart when sub-GHz, IR, or BadUSB capability is also required
- Cross-tool decision matrix:
../_shared/comparison.md - Legal and ethics baseline:
../_shared/legal_ethics.md