Chameleon Ultra · Volume 7

Chameleon Ultra — Slot Management and Card Organization

The 8+8 slot architecture; naming, ordering, and exporting slots; managing a multi-credential field inventory

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

7.1 The 8+8 slot architecture in practice

Explains the 8+8 slot model as a dual-bank system: 8 HF slots (13.56 MHz / ISO 14443A) and 8 LF slots (125 kHz) operate in parallel, each independently configured; the active slot in each bank can be different. Explains how this translates to the operational reality of carrying a full pre-engagement credential inventory in a single sub-credit-card device.

7.1.1 HF and LF banks are independent

Clarifies that the 8 HF slots and 8 LF slots do not share capacity — a device with 8 HF slots loaded still has 8 LF slots available; total credential capacity is 16, not 8.

7.1.2 Active slot concept

Explains that each bank has one “active” slot at any time — the one presented to a reader when the Chameleon Ultra is powered and proximate. Switching the active slot changes what the device presents without affecting other slots.

7.1.3 Capacity planning for an engagement

Brief guidance on planning a 16-slot loadout: suggests reserving at least one HF and one LF slot per target building/reader type; notes that most field engagements involve fewer than 8 distinct credentials per band.

7.2 HF slot inventory — configuring and naming 8 HF slots

Covers the HF slot management workflow in ChameleonUltraGUI: per-slot card type selection, UID entry or dump load, slot naming, and reviewing the full 8-slot inventory at a glance.

7.2.1 Per-slot card type configuration

Step-by-step: select an HF slot, choose the card type (MIFARE Classic 1K/4K, Ultralight, NTAG variant, DESFire, etc.), and enter or import the dump. [VERIFY: current ChameleonUltraGUI slot-config flow]

7.2.2 Naming HF slots

Explains how to assign a human-readable label to each slot (e.g. “Lobby badge — MC1K”, “Parking — NTAG216”); describes label length limits and how names appear in the GUI and during slot switching. [VERIFY: label length limit and display behavior in current firmware]

7.2.3 Reviewing the HF slot inventory

Describes the 8-slot overview screen in ChameleonUltraGUI: card type, slot name, UID, fill status (empty vs loaded).

7.3 LF slot inventory — configuring and naming 8 LF slots

Mirrors §2 for LF: per-slot protocol type selection (EM410x, HID Prox, T5577, Indala, etc.), credential value entry, slot naming, and the LF 8-slot inventory view in ChameleonUltraGUI.

7.3.1 Per-slot LF protocol configuration

Step-by-step: select an LF slot, choose the protocol, enter the credential value. [VERIFY: current ChameleonUltraGUI LF slot-config flow]

7.3.2 Naming LF slots

Same naming guidance as HF slots; notes any differences in LF slot label handling. [VERIFY]

7.3.3 Reviewing the LF slot inventory

Describes the LF slot overview screen.

7.4 Switching between slots — button behavior and BLE app interface

Describes the two slot-switching mechanisms: (1) the physical button on the device (cycles active slot sequentially in a fixed order when BLE is not connected); (2) the BLE app interface (direct slot selection by number or name from the ChameleonUltraGUI slot dashboard).

7.4.1 Button-only slot cycling

Explains the button’s behavior: a short press advances the active HF or LF slot (behavior depends on current mode); notes the cycle order and how to determine which slot is active from the RGB LED. [VERIFY: exact button behavior — does the button cycle HF slots, LF slots, or interleaved? Confirm against current firmware]

7.4.2 BLE app direct slot selection

Describes the direct slot selection flow in ChameleonUltraGUI: tap a slot in the grid to activate it instantly; explains why this is preferred over button cycling for multi-slot field sessions.

7.4.3 Slot switching without a phone

Notes the standalone button-only workflow: useful when phone use is restricted; the button is the only local control surface for slot switching; acknowledges the limitation (sequential-only, no labels visible on-device).

7.5 Exporting and importing slot data — dump files, formats

Covers the round-trip data management workflow for slot dumps: exporting a slot’s dump from the Chameleon Ultra to a host file, the dump file format and naming conventions, importing a previously saved dump back into a slot, and bulk management of a pre-engagement credential library.

7.5.1 Exporting a slot dump

Step-by-step: select slot, tap Export in ChameleonUltraGUI, confirm file destination on phone or desktop. [VERIFY: current export flow — file format produced by ChameleonUltraGUI]

7.5.2 Dump file formats and naming

Describes the file format(s) used (binary dump, JSON, or ChameleonUltraGUI proprietary format); notes naming conventions that preserve card type and slot metadata. [VERIFY: file format detail — confirm .bin vs JSON vs other]

7.5.3 Importing a dump into a slot

Step-by-step: select target slot, tap Import, locate dump file, confirm card type match. [VERIFY: current import flow]

7.5.4 Building a credential library

Explains the operational practice of maintaining a folder of named dump files on the operator’s host — organized by engagement, location, or card type — for rapid pre-engagement slot population.

7.6 Building a pre-engagement slot set

Practical guidance for preparing the Chameleon Ultra before a physical-pentest engagement: planning the 8+8 slot loadout, loading the relevant credentials (captured during a recon pass or imported from previous engagements), verifying each slot, confirming slot labels, and testing emulation on a known reader before going live.

7.6.1 Pre-engagement checklist

A concise checklist: verify firmware version, check battery charge, confirm all target slot types are loaded and tested, confirm slot labels match engagement documentation, confirm BLE app is connected and sees all 16 slots. [VERIFY: any firmware-version-specific caveats]

7.6.2 Slot assignment strategy

Recommends a slot assignment convention for multi-target engagements (e.g. HF slots 1–4 for primary building access, 5–8 for secondary targets; LF slots mirroring the same).

7.6.3 Testing before going live

Explains the importance of validating each loaded slot against a known-good lab reader before entering the field; identifies the class of failures (ATQA/SAK mismatch, incomplete dump) that only manifest at the reader.

7.7 RGB LED slot indicators

Describes how the RGB LED communicates slot state: current active slot number, HF vs LF band, any error or low-battery states. Maps the LED color/blink patterns to device states. [VERIFY: current LED behavior per firmware version — LED scheme has changed across firmware releases; confirm against latest stable firmware]

7.7.1 LED color scheme

Table: LED color/pattern → device state (idle, active HF slot N, active LF slot N, BLE connected, charging, low battery, error). [VERIFY: exact current color mapping]

7.7.2 Interpreting LED during slot switching

Explains what the LED shows during button-press slot cycling so the operator can confirm the correct slot is active without opening the BLE app.

7.8 Slot management gotchas and firmware-version considerations

Documents the non-obvious slot management behaviors and known firmware-version gotchas that have caused field failures; flags areas where firmware evolution has changed slot behavior.

7.8.1 Slot state after firmware update

Notes whether slot dumps and configuration persist across firmware updates or are cleared; explains the recommended pre-update backup procedure. [VERIFY: persistence behavior across firmware versions — some early firmware versions cleared slots on update]

7.8.2 Slot type mismatch on import

Explains the failure mode where a dump intended for MIFARE Classic 1K is imported into a slot configured for 4K (or vice versa); how the GUI handles this and how to detect/fix it.

7.8.3 Empty slot behavior

Describes what happens when the active slot is empty and the Chameleon is presented to a reader (no response, reader sees silence); notes that this is not a device failure.

7.8.4 Firmware-version-specific slot behaviors

Placeholder for known per-version slot management changes; to be populated from the RfidResearchGroup/ChameleonUltra changelog once the device is acquired and firmware version is confirmed. [VERIFY: changelog entries relevant to slot management]