Chameleon Ultra — Firmware and Open-Source Ecosystem

---

9.1 The open-source story

RfidResearchGroup (RRG) is the same consortium that maintains the Proxmark3 Iceman firmware — the most capable and actively maintained fork of the Proxmark3 toolchain, which is itself the de facto standard for RFID/NFC research and access-control auditing. The Chameleon Ultra firmware emerged from this same research culture: contributors who had been shaping the Proxmark3 Iceman ecosystem applied the same iterative, research-grade open-source discipline to the Chameleon Ultra platform when RRG and Proxgrind co-developed the device. The lineage is not merely organizational — iceman1001, who maintains the Proxmark3 Iceman fork, is credited in the ChameleonUltra AUTHORS.md, and the CHANGELOG shows his udev rules file contribution in the v2.0.0 batch.

The firmware is released under the GNU General Public License version 3.0 (GPL-3.0), a copyleft license that requires any distributed derivative to be released under the same terms. For users, GPL-3.0 means every capability claimed by the firmware is auditable in source form at github.com/RfidResearchGroup/ChameleonUltra — there is no closed execution layer, no vendor-only binary blob for the attack algorithms, and no obscured key-handling logic. The Crypto1 attack suite (DarkSide, Nested, StaticNested, HardNested, MFKEY32 v2, and the FM11RF08S senested backdoor path) can be inspected, reproduced, and verified against the academic literature entirely from the public repository. This is a significant auditability advantage over closed devices in the same category.

The GPL-3.0 copyleft also governs derivative works: any firmware fork that is distributed must be GPL-3.0. In practice, the RRG ecosystem has produced a single canonical firmware repository with a rich contributor history rather than a fragmented closed-fork landscape — contributors who improve the firmware typically return those improvements upstream via PR. The Proxmark3 cross-project context reinforces this posture: RRG contributors are accustomed to the open upstream model and the engineering benefits of shared testing across a large installed base.

The companion ../Proxmark3 RDV4/ subproject in this Hack Tools hub covers the Proxmark3 Iceman firmware from the tool operator’s side; the structural overlap with the Chameleon Ultra’s development culture is covered there. For this series, the relevant implication of the shared lineage is that the Chameleon Ultra firmware’s cryptanalytic implementations — DarkSide, Nested, StaticNested, and HardNested — draw on the same academic foundations and community implementations that the Proxmark3 Iceman firmware uses, adapted for the nRF52840’s single-core Cortex-M4F execution model.

9.2 Firmware repository layout

The canonical repository is RfidResearchGroup/ChameleonUltra on GitHub (approximately 2.8k stars and 404 forks as of 2026-06). The top-level directory structure:

ChameleonUltra/
├── .github/          # CI workflows, issue templates, PR templates
├── docs/             # Documentation source files
├── firmware/         # nRF52840 device firmware (C, Assembly)
├── hardware/         # PCB schematics and Gerber files for Ultra and Lite
├── resource/         # Reference resources
├── software/         # Host-side Python CLI client
├── CHANGELOG.md      # Version history — authoritative change record
├── CONTRIBUTING.md   # Contribution guidelines
├── AUTHORS.md        # Contributor acknowledgements
├── LICENSE           # GPL-3.0 full text
└── README.md         # Project overview and quickstart

The firmware/ directory holds the nRF52840 firmware source:

firmware/
├── application/      # Main application layer (C: protocol stacks, attack algorithms, CLI handlers)
├── bootloader/       # DFU bootloader (nRF52840 USB DFU bootloader configuration and build)
├── common/           # Shared utilities and data structures used across application and bootloader
├── nrf52_sdk/        # Nordic nRF5 SDK (vendored in-tree)
├── Makefile.defs     # Shared make variable definitions
├── build.sh          # Primary build script
├── Dockerfile        # Container image for reproducible builds
├── docker-compose.yml # Docker Compose configuration (added v2.1.0)
├── flash-dfu-app.sh  # Helper: flash application-only DFU package
└── flash-dfu-full.sh # Helper: flash complete (bootloader + application) DFU package

The application/ directory is the bulk of the firmware: the HF ISO 14443A stack (card emulation via the nRF52840 NFC-A hardware block and MFRC522 reader logic over SPI), the LF protocol implementations (EM410x, HID Prox, T5577, Indala, and the other families in Vol 2 §4.2), the Crypto1 attack suite (DarkSide, Nested, StaticNested, HardNested, MFKEY32, senested), the BLE peripheral stack, the USB CDC serial handler, and the slot storage management that writes to the nRF52840’s 1 MB internal flash. The bootloader/ directory builds the nRF52840 USB DFU bootloader, which is flashed once as part of a full-image install and remains resident across normal application updates — the bootloader partition only changes when dfu-full.zip is used, not during routine dfu-app.zip updates.

The software/ directory contains the Python CLI client: the host-side tool that communicates with the device over USB CDC ACM serial or BLE. It is a Python 3.9+ project managed with uv (pyproject.toml, uv.lock), with source under software/src/ and helper scripts under software/script/; the DFU helper script resides at resource/tools/enter_dfu.py (BLE variant: resource/tools/enter_dfu_over_ble.py). A PyInstaller configuration (pyinstaller.spec, added in v2.1.0) produces a standalone executable for hosts without a Python runtime. The CLI client is the reference implementation of the ChameleonUltra BLE/serial protocol and is the tool used in the CLI examples throughout this series.

The hardware/ directory contains PCB schematics and Gerber files for both the Ultra and Lite variants — the authoritative source for the coil geometry described in Vol 2 §5.

The language breakdown of the repository (C: 96.3%, Assembly: 1.9%, Python: 1.6%) reflects the primary concerns: real-time embedded C for the nRF52840, a small amount of Assembly for timing-critical interrupt and startup paths, and Python for the host CLI.

A companion documentation repository, RfidResearchGroup/ChameleonUltraDocs, hosts the user guides and wiki source. The firmware wiki at github.com/RfidResearchGroup/ChameleonUltra/wiki is the primary human-readable reference for command syntax, LED state maps, and the protocol specification; entries like the LED color→state table cited in Vol 2 §6.2 are sourced from that wiki.

9.3 Release cadence and version numbering

The ChameleonUltra firmware uses a major.minor.patch version string derived from git tags (e.g., v2.1.0). The firmware build embeds the tag automatically — the APP_FW_VER was changed in v2.0.0 “to be deduced from git tag vx.y.z” (CHANGELOG) — so hw version on the device reflects the exact tagged commit. To date, the project has published only major and minor increments; no patch-level releases (e.g., v2.1.1) appear in the release history.

The release history from CHANGELOG.md (github.com/RfidResearchGroup/ChameleonUltra/blob/main/CHANGELOG.md):

Table 1 — The release history from CHANGELOG.md (github.com/RfidResearchGroup/ChameleonUltra/blob/main/CHANGELOG.md)

Release	Date	Key content
v1.0	2023-06-06	Factory firmware shipped with initial production units
v2.0.0	2023-09-26	Major protocol overhaul; StaticNested (MF1_STATIC_NESTED_ACQUIRE); NTAG21x emulation; BLE security and pairing; 30× faster dump upload/download; DFU helper scripts
v2.1.0	2025-09-02	HardNested PR #254; FM11RF08S senested backdoor PR #263; HID Prox; Ultralight EV1/NTAG shadow mode; Docker build; parallelized MFKEY32v2; regression tests

The gap between v2.0.0 (September 2023) and v2.1.0 (September 2025) reflects the project’s feature-driven release model: approximately 35 distinct changes from over a dozen contributors were accumulated in the v2.1.0 batch before a stable tag was published. The project is not on a time-boxed release schedule — stable releases are published when a feature batch reaches sufficient quality, not on a calendar cadence.

An “[Unreleased]” section at the top of CHANGELOG.md accumulates in-progress changes merged since v2.1.0. As of 2026-06, that section includes additional LF protocol additions (Jablotron, IDTECK, PAC/Stanley, ioProx) and NFC import functionality that have landed in the main branch but are not yet in a stable tagged release. Treat these as available in development builds, subject to further revision before stabilization.

9.4 OTA update via ChameleonUltraGUI

The primary firmware update path for most operators is over-the-air via ChameleonUltraGUI over BLE. No host-side toolchain installation is required; the GUI handles the Nordic DFU protocol transparently. The firmware package (a .zip archive containing the signed application binary) is transferred from the GUI to the device, where the nRF52840 DFU bootloader writes it to the application flash partition.

Pre-conditions:

• BLE stability: The GUI must maintain a stable BLE connection for the duration of the transfer — typically 60–120 seconds depending on BLE data rate and interference. Perform the update at close range; do not attempt at the edge of BLE coverage.
• Power supply: A heavily discharged LiPo that hits its undervoltage lockout threshold mid-flash will interrupt the update and leave the device in a partially written state. The community recommendation (Dangerous Things forum) is to plug the device into USB-C power during any firmware update, even when using the BLE OTA path — USB charging proceeds concurrently with BLE operation (Vol 2 §8), and the combination of wall power plus BLE transfer eliminates the battery risk.
• GUI compatibility: ChameleonUltraGUI versioning (GameTec-live/ChameleonUltraGUI/releases) is independent of the firmware versioning. The GUI may add features before the firmware release that enables them, or may enforce minimum firmware version requirements. Confirm that the installed GUI version supports the target firmware version before initiating an update.

OTA update workflow:

1. Open ChameleonUltraGUI and connect to the Chameleon Ultra over BLE.
2. Navigate to the device information screen; the current firmware version string is displayed. Compare it against the latest stable release at github.com/RfidResearchGroup/ChameleonUltra/releases.
3. In the GUI’s firmware update section (the exact menu path evolves between GUI releases; look for a “Firmware Update” or equivalent entry in the device settings screen), initiate a firmware update. The GUI offers to download the latest stable package from GitHub releases or to load a locally saved .zip.
4. Trigger the update. The GUI sends the hw dfu command over BLE; the device reboots into the DFU bootloader. The USB CDC serial interface goes offline at this point — the device is exclusively in the bootloader.
5. The GUI transfers the firmware package via the Nordic DFU protocol over BLE. The on-device LED pattern transitions to the DFU indicators from Vol 2 §6.2: LEDs 4 and 5 alternating green while the bootloader awaits data, fast-blinking blue while the flash write is in progress. Do not disconnect BLE or remove USB power during the write phase.
6. On completion, the device reboots into the new application firmware. The GUI reconnects automatically and displays the updated version string. Confirm with hw version in the CLI or the GUI info screen.

If the OTA transfer fails mid-write and the device is left in DFU error state (Vol 2 §6.2: LEDs 4 and 5 slow-blinking red), the bootloader is still intact. Connect the device over USB-C and use the USB DFU path described in §5 to complete the flash.

9.5 USB DFU update

The USB DFU path is the recovery option for devices that cannot complete an OTA update — a failed BLE transfer, an interrupted write, a corrupted application that prevents normal BLE enumeration, or bench-mode firmware development. It uses the nRF52840’s built-in USB DFU bootloader, which exposes a Nordic DFU target USB device class when DFU mode is active (Vol 2 §8). The host-side tool is the modern nrfutil — Nordic Semiconductor’s unified command-line interface.

Entering DFU mode:

Two confirmed paths from the RRG development wiki (github.com/RfidResearchGroup/ChameleonUltra/wiki/development):

1. From a live device via CLI: Issue hw dfu from the Python CLI client. The firmware sends the bootloader entry command, the device reboots, and re-enumerates on USB as a Nordic DFU target rather than the normal CDC ACM serial device.
2. Via the helper script: resource/tools/enter_dfu.py wraps the same command for environments where the interactive CLI is not convenient.

If the application firmware is non-functional and the device cannot enumerate its normal USB interface — the recovery scenario after a corrupted flash — the nRF52840 supports a hardware-level bootloader entry. The RRG development wiki documents the hardware forced-DFU procedure: unplug the device, let it fully sleep, hold button B, then replug. The device will enter the DFU bootloader.

Installing nrfutil:

The modern nrfutil (the Nordic unified CLI tool, distinct from the deprecated Python nrfutil package used with older nRF5 SDK toolchains) is required. The installation subcommand per the RRG development wiki:

nrfutil install completion device nrf5sdk-tools trace

Platform-specific installation uses the Nordic package distribution: Windows via Chocolatey, Debian/Ubuntu via the Nordic APT repository, macOS via the Nordic download. The legacy pip install nrfutil Python package is not the correct tool for this workflow; the RRG build documentation is explicit that nrfutil must be installed from Nordic’s distribution.

Flashing the firmware:

Two DFU packages are produced by the build process and published in the GitHub releases:

Table 2 — Two DFU packages are produced by the build process and published in the GitHub releases

Package	Contents	Use case
dfu-app.zip	Application firmware only	Normal firmware update — bootloader stays intact
dfu-full.zip	Bootloader + application (complete image)	Recovery from bootloader corruption or first-time full flash

For a standard firmware update, dfu-app.zip is correct:

nrfutil device program --firmware objects/dfu-app.zip --traits nordicDfu

For a full re-flash:

nrfutil device program --firmware objects/dfu-full.zip --traits nordicDfu

The --traits nordicDfu flag specifies that the target is a Nordic DFU bootloader device. nrfutil device auto-discovers the DFU target when exactly one is enumerated; the --serial-number or --device-id flag disambiguates when multiple Nordic devices are connected simultaneously.

The helper scripts firmware/flash-dfu-app.sh and firmware/flash-dfu-full.sh wrap the above commands and are the recommended invocation for build-and-flash development cycles where the environment is confirmed working.

LED indicators during USB DFU are identical to the OTA indicators (Vol 2 §6.2): LEDs 4 and 5 alternating green while the bootloader is idle awaiting a package, fast-blinking blue during the write phase, slow-blinking red on error.

9.6 Building from source — toolchain requirements

Building the ChameleonUltra firmware from source requires the ARM bare-metal GCC toolchain, the Nordic nRF5 SDK (vendored in-tree), GNU Make, and the Nordic command-line tools. No Zephyr RTOS and no nRF Connect SDK are used. The firmware builds against the nRF5 SDK in firmware/nrf52_sdk/ — the older Nordic SDK targeting ARM GCC and Make — consistent with the firmware’s bare-metal priority-ordered event loop architecture (Vol 2 §2.3) rather than an RTOS-based execution model.

Supported compilers:

Two ARM GCC toolchain versions are confirmed working per the RRG development wiki (github.com/RfidResearchGroup/ChameleonUltra/wiki/development):

Table 3 — Two ARM GCC toolchain versions are confirmed working per the RRG development wiki (github.com/RfidResearchGroup/ChameleonUltra/wiki/development)

Toolchain version	Source
gcc-arm-none-eabi-10.3-2021.10	developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
arm-gnu-toolchain-12.2.rel1-*-arm-none-eabi	Same

The development wiki explicitly warns: do not use the Debian/Ubuntu packaged gcc-arm-none-eabi (available via apt). The Debian-packaged version produces a bootloader binary that exceeds the nRF52840’s allocated bootloader flash partition; the build will appear to succeed but the resulting image will not fit. Always use the ARM-published toolchain from the ARM Developer downloads page.

Required tools:

Table 4 — Required tools:

Tool	Purpose
arm-none-eabi-gcc (10.3-2021.10 or 12.2.rel1)	C and Assembly compilation
GNU Make	Build orchestration (build.sh invokes Make)
nrfjprog + mergehex	Nordic nRF Command Line Tools — JTAG/SWD programming and hex-file merging
nrfutil (modern Nordic unified version)	DFU package programming over USB

Host OS support:

The development wiki documents three build environments: Windows (using Chocolatey for toolchain installation), Debian/Ubuntu, and macOS. The Docker option (firmware/Dockerfile and firmware/docker-compose.yml) provides a reproducible container-based build environment that avoids the host toolchain sensitivity issues entirely. Docker support was added in v2.1.0 (CHANGELOG: “Added firmware/docker-compose.yml to build firmware in local docker”).

Build invocation:

cd firmware
./build.sh

The build script invokes Make with the appropriate nRF5 SDK targets. Build outputs are placed in objects/: dfu-app.zip (application-only DFU package) and dfu-full.zip (bootloader + application). Because the nRF5 SDK is vendored in firmware/nrf52_sdk/, no separate SDK download step is required after cloning the repository.

Debugging and JTAG:

Source-level debugging uses arm-none-eabi-gdb from the toolchain, connected via J-Link or ST-Link V2. The development wiki documents both:

• J-Link: Segger J-Link Software with nrfjprog. Note that J-Link OB (on-board) variants from other Nordic development kits are not compatible with nRF52840 target devices; a stand-alone J-Link or a Segger EDU Mini is required.
• ST-Link V2: Via OpenOCD. Documentation added in v2.0.0 (CHANGELOG: “Added support for ST-Link and debugging documentation”).

RTT-based firmware logging (NRF_LOG over the SWO pin, enabled via CONFIG_NRF_LOG_BACKEND_UART_RTT) is the firmware’s debug output channel. The v2.0.0 CHANGELOG entry “Added option to enable NRF_LOG UART on SWO pin” describes the configuration; the development wiki covers the RTT setup for both J-Link RTT Viewer and OpenOCD’s RTT support.

9.7 Community forks and third-party firmware variants

The ChameleonUltra ecosystem concentrates its diversity in the control application layer rather than in firmware forks. As of 2026-06, no publicly documented stable alternative firmware for the Chameleon Ultra — analogous to the Momentum or Xtreme ecosystems for the Flipper Zero — is identifiable in accessible public sources. The GitHub fork network shows approximately 404 forks, consistent with a project of this star count, but examination of active forks indicates these are predominantly contributor development forks used during active PR work rather than independently maintained firmware variants. The GPL-3.0 copyleft dynamic reinforces this pattern: contributors who develop improvements are strongly incentivized to submit upstream rather than maintain divergent forks, since submitting upstream gives their work wider testing and maintenance than any individual fork would receive.

The application-layer ecosystem currently contains two documented options:

ChameleonUltraGUI (GameTec-live/ChameleonUltraGUI): The reference companion application, written in Flutter for cross-platform deployment. Platform support: Android, iOS, iPadOS, macOS, Windows, Linux. Distribution channels: Google Play Store, Apple App Store, Flathub (Linux), Debian APT repository, Arch Linux (AUR), and direct APK/installer downloads from the GitHub releases page (github.com/GameTec-live/ChameleonUltraGUI/releases). Approximately 1,000 GitHub stars as of 2026-06. Communicates with the device over BLE or USB-C serial. The GUI implements the full firmware protocol: slot management, OTA firmware updates, card read/attack/emulation workflows, detection-mode nonce logging and MFKEY32 v2 key recovery, dump import and export (CUGUI JSON, binary .bin, and MCT formats), and per-slot configuration. The lead maintainer @GameTec-live is also a firmware contributor (multiple entries in the v2.0.0 and v2.1.0 CHANGELOGs), which keeps protocol implementation alignment tight between the firmware and the GUI. This is the GUI used in the step-by-step workflows throughout this deep-dive series; GUI version and firmware version must be compatible — confirm both hw version (device) and the GUI’s own version string before an engagement.

MTools BLE: A commercial iOS and Android application by MTools Tec (shop.mtoolstec.com). Supports multiple RFID device backends in a single app — PN532 BLE, PCR532, Chameleon Ultra/Lite/DevKits, and Pixl.js. Supported card operations include MIFARE Classic 1K/4K, Ultralight/C/EV1, DESFire, NTAG 21x, MIFARE Plus, and other NFC tags via APDU commands. RRG officially acknowledges MTools BLE in their wiki (github.com/RfidResearchGroup/ChameleonUltra/wiki/mtoolsble) and in the companion documentation repository (RfidResearchGroup/ChameleonUltraDocs). MTools BLE is not open-source. It is the alternative for operators who prefer its UI or who manage multiple RFID device backends through a single application.

The RRG README also lists community Discord channels (specifically a “Software/chameleon-dev” channel) as the coordination point for in-progress integrations. Any third-party apps beyond these two that emerge should be verified against the RRG wiki before use — unofficial integrations not listed in the RRG documentation may not correctly implement the firmware protocol or may lag behind firmware changes.

No third-party firmware variant, modded firmware image, or community-maintained firmware fork with documented features or a release history was identifiable in public sources as of 2026-06. This may change; the GitHub fork network and the RRG wiki’s “Third party moddings worth mentioning” section are the appropriate places to monitor for any future entrants.

9.8 Contributing upstream

The contribution model is a standard GitHub fork-and-PR workflow with no Contributor License Agreement (CLA) requirement. The CONTRIBUTING.md makes no mention of a CLA; contributors are bound only by the GPL-3.0 terms of the repository.

Workflow:

1. Fork RfidResearchGroup/ChameleonUltra on GitHub.
2. Create a focused branch for the specific feature or fix. CONTRIBUTING.md calls for “Atomic PRs” — scoped to one logical change, independent of unrelated modifications, and self-contained. Large omnibus PRs mixing unrelated changes are explicitly discouraged (“Focused Scope”).
3. Write code following project conventions. For the Python CLI client: Python 3.9+ type annotations required throughout; Ruff for formatting and linting (enforced in CI via the UV linter/formatter integration added in v2.1.0, CHANGELOG: “Added UV, formatter and linter. Contribution guidelines”); uv as the package manager (new dependencies must be added to both pyproject.toml and uv.lock). For C firmware code: follow the patterns in existing firmware/application/ files; no separate C style guide document is published in the repository as of 2026-06, but the project’s PRs consistently use the nRF5 SDK naming conventions.
4. Use conventional commit message format (recommended, though not enforced by a hard CI gate): feat:, fix:, docs:, refactor:, test:, etc. The CONTRIBUTING.md explicitly recommends “Conventional commits” for clarity. Atomic commits at logical milestones rather than a single squashed commit per PR.
5. Open a PR against main. CI runs automatically — it validates compilation and, as of v2.1.0, a regression test suite (CHANGELOG: “Added regression tests” by @doegox). Unit tests are “highly appreciated” but described as optional. The PR description should explain what the change does and how it was tested, including which physical hardware variants (Ultra vs. Lite, which firmware version) were used if the change is hardware-interaction code.
6. Maintainer review follows. PRs that touch the firmware protocol layer undergo more scrutiny than pure CLI additions, since protocol changes must maintain backward compatibility with existing GUI and CLI clients. Large feature PRs (e.g., PR #254 for HardNested, PR #263 for senested) typically go through multiple review rounds before merge.

Contributor credits are tracked in AUTHORS.md. Significant contributors visible in the v2.0.0 and v2.1.0 CHANGELOGs include @doegox (primary maintainer — the most entries across both releases; FM11RF08S static-encrypted-nonce backdoor disclosure research, eprint.iacr.org/2024/1275), @xianglin1998, @GameTec-live, @Foxushka (author of PR #263), @taichunmin, @augustozanellato, @domints, @spp2000, @FlUxIuS, @iceman1001 (Proxmark3 Iceman maintainer), @gentilkiwi (Benjamin Delpy of Mimikatz fame), @p-l-, @turbocooler, @TeCHiScy, @ca1e, @nemanjan00, @szymex73, and @doegox again as reviewer and integration lead. The full authoritative list is in AUTHORS.md.

9.9 What changes between firmware versions — tracking the changelog

The CHANGELOG.md at the repository root is the authoritative record of every feature addition, behavioral change, bug fix, and breaking protocol modification between releases. It follows the Keep a Changelog format: version headers with ISO 8601 date stamps, bullet-point changes per version, and an “[Unreleased]” section for work merged but not yet tagged. The entries attribute each change to the contributing GitHub handle.

Reading the changelog for field-workflow impact:

Not every changelog entry affects an operator’s field workflow. The entries that matter fall into four categories:

New attack mode or protocol command. Any addition of a hf mf * or lf * command adds a capability absent from earlier firmware. Key additions by version:

• v2.0.0 (2023-09-26): MF1_STATIC_NESTED_ACQUIRE — StaticNested attack, auto-routed within hf mf nested (Vol 4 §6). MIFARE Ultralight reading features. NTAG21x emulation support.
• v2.1.0 (2025-09-02): hf mf senested — FM11RF08S backdoor key recovery via static-encrypted-nonce path (Vol 4 §4.3; PR #263 by @Foxushka). HardNested full implementation via PR #254 (Vol 4 §7; Vol 6 §2.4). HID Prox LF read support. T55xx write support. MIFARE Ultralight (original, C, EV1) and NTAG 213/215/216 proper emulation via @turbocooler.

Protocol or command-name change. Any rename or argument restructure requires updating existing scripts. The v2.0.0 release removed MF1_DETECT_DARKSIDE (replaced with a refactored DarkSide implementation) and altered multiple hw slot and hf mf sim command behaviors. The v2.1.0 release “Changed massively CLI, cf #164 (comment)” — a significant CLI restructure that changes argument forms across many commands. Scripts written against v2.0.0 syntax may not run correctly on v2.1.0; always verify against --help output from the running firmware.

Bug fix in an attack algorithm. The v2.0.0 fix “Fixed Darkside: parity byte-to-array bug made it low probability to succeed” directly changes success rates for the DarkSide attack. If a command was previously unreliable and the changelog notes a fix, re-testing after a firmware update is warranted. Similarly, hf mf elog --decrypt gained “skip already used items” behavior in v2.1.0 — re-running key recovery after a partial result is now safe without re-collecting nonces.

Performance change. The v2.0.0 “uploads/downloads are now 30× faster for MF1 eload/eread operations” shortens dump transfer time significantly relative to v1.0 workflows. The v2.1.0 “Added multithreading on Nested and StaticNested” and “Parallelize mfkey32v2 processes called from CLI” reduce key-recovery wall time on multi-core hosts.

Version-specific caveats known at authoring (2026-06):

• hf 14a sniff bug in v2.1.0-series: A documented issue (GitHub issue #444, referenced in Vol 6 §1.2) where encrypted block responses are captured incorrectly after authentication in the hf 14a sniff path. For key-recovery nonce logging, use the detection-mode path (hf mf econfig --enable-log + hf mf elog --decrypt) rather than hf 14a sniff.
• Toolchain GCC version sensitivity: Only the two confirmed ARM GCC versions (10.3-2021.10 and 12.2.rel1) reliably build the bootloader within the allocated flash partition. The Debian/Ubuntu apt packaged version produces an oversized bootloader.
• CLI version gap between v2.0.0 and v2.1.0: The CLI restructuring in v2.1.0 means some command forms from v2.0.0 documentation no longer work. Confirm CLI syntax against the device’s own hw help or --help output rather than third-party documentation that may predate the running firmware.
• [Unreleased] content: Additional LF protocol families (Jablotron, IDTECK, PAC/Stanley, ioProx) and NFC import functionality had been merged to main but not yet released as a stable tag as of 2026-06. These features may be present in development builds but should not be assumed stable.

The firmware wiki at github.com/RfidResearchGroup/ChameleonUltra/wiki and the CLI’s built-in --help output are the appropriate primary references when a specific command’s current syntax or behavior is in question. The CHANGELOG answers “what changed and when”; the wiki and --help answer “what is the current correct invocation.”