The capability surface at category level, the home screen and navigation, the VALHALLA gate and persistent Blue Team mode, the SD loot layout, and the max-power TX table

Figure 1 — A supported CYD running the HaleHound firmware; the home screen carries the mode banner and the touch grid of subsystems. Photo: HaleHound.com.

8.1 About this Volume

HaleHound advertises “40+ attack modules across WiFi, Bluetooth, SubGHz, 2.4GHz and NFC,” plus drone, jam-detect and SIGINT suites, all touch-driven on the CYD. This volume describes what classes of thing the firmware can do, why each exists, and the posture and legal framing around them — deliberately at the level of capability categories, not as an operating manual.

This volume is category-level by policy. It names the classes of capability each radio exposes and their intended purpose. It does not reproduce the firmware’s module menu as an enumerated tree, and it does not give step-by-step procedures for any offensive action — not how to run a specific exploit, replay a particular keyfob, open a given vehicle, or extract keys from a specific device. This matches the posture of the WiFi Pineapple, ESP32 Marauder, and Ducky Script deep dives in this hub. The device’s own on-screen flow, the vendor README, and the VALHALLA disclaimer are the operating references for an authorized owner; the purpose here is to let a reader understand the tool’s shape, its legal weight, and where it fits, without this document itself being a how-to.

The honest summary: HaleHound is a broad offensive toolkit with a real defensive wing. The breadth is the point — it collapses what would otherwise be a bench of single-purpose tools (a Wi-Fi attack board, a sub-GHz replay tool, an NFC cloner, an NRF24 sniffer, a drone-RID scanner) onto one $7–18 touchscreen. That same breadth is why the authorization framing in §4 and Vol 12 is load-bearing rather than boilerplate: most of what the device does is lawful only against hardware the operator owns or has written authorization to test.

8.2 How to read a category-level capability map

A capability category is a class of technique against a protocol, stated by its function and its radio, not by the firmware’s label for a given screen. For example:

Table 1 — A capability category is a class of technique against a protocol, stated by its function and its radio, not by the firmware's label for a given screen. For example

Stated as (category level)	Rather than (operating detail — not here)
“Wi-Fi: targeted disassociation / denial”	which key sequence floods which frame type at a named AP
”Wi-Fi: rogue-AP credential harvest”	the exact portal template and capture steps
”sub-GHz: capture, replay, and code-generation brute force”	how to capture and re-send a specific keyfob
”NFC: scan, read, clone, brute, emulate (MIFARE class)“	the sector-by-sector dump-and-write procedure
”BLE: published-CVE probes against consumer chipsets”	which bytes trigger which CVE on which product
”drone: Remote ID detect and spoof”	how to forge a convincing operator beacon

Everything below stays in the left column. The categories are grouped by the radio that drives them, because on this platform the radio is the real constraint: the ESP32’s built-in Wi-Fi/BLE, and the three external plug-in radios (CC1101 sub-GHz, NRF24L01+PA+LNA 2.4 GHz, PN532 NFC) plus GPS, all detailed electrically in Vol 3.

8.3 The touch UI and the home screen

The entire interface is touch-driven on the resistive XPT2046 panel — no buttons, no companion app, no host required once flashed. The UI scales automatically between the 240×320 (2.8”) and 320×480 (3.5”) panels, so the same layout logic serves every supported board; a 3.5” unit simply shows more at once.

   HOME SCREEN (schematic — layout, not a menu dump)
   ═════════════════════════════════════════════════════════════
   ┌───────────────────────────────────────────────────────────┐
   │  [ MODE BANNER ]   VALHALLA  ·  or  ·  BLUE TEAM            │ ← current mode
   ├───────────────────────────────────────────────────────────┤
   │   ┌────────┐  ┌────────┐  ┌────────┐                       │
   │   │  Wi-Fi │  │  BLE   │  │ 2.4GHz │   touch grid of        │
   │   └────────┘  └────────┘  └────────┘   subsystem groups     │
   │   ┌────────┐  ┌────────┐  ┌────────┐                       │
   │   │ SubGHz │  │  NFC   │  │ Drone  │   tap a group → its    │
   │   └────────┘  └────────┘  └────────┘   capability screens   │
   │   ┌────────┐  ┌────────┐  ┌────────┐                       │
   │   │JamDetect│ │ SIGINT │  │ Tools  │                       │
   │   └────────┘  └────────┘  └────────┘                       │
   ├───────────────────────────────────────────────────────────┤
   │  Settings · About            (heap / board / mode visible)  │
   └───────────────────────────────────────────────────────────┘

The two load-bearing facts about the home screen:

The mode banner is always visible. It reads VALHALLA (offensive tools unlocked) or BLUE TEAM (defensive/passive only). The operator can tell at a glance which posture the device is in — there is no silent armed state.
Grouping is by subsystem. Tapping a group opens that radio’s capability screens. Several screens render live visualisations — spectrum bars, packet-rate graphs, equalizer-style activity meters — which double as the feedback that a radio is actually working after a build (the Radio Test tool, §8, exists for exactly this verification).

Two more UI facts matter for a reference reader. First, the interface is self-contained — no serial console, no companion phone app, no cloud account. Everything, including the on-device wiring diagrams in Radio Test and the per-setting help text referenced from the tuning panels, lives in the firmware and renders on the panel. Second, an About / armed-module screen reports the firmware build and which modules are currently available given the mode — a quick way to confirm, at a glance, whether the device is in a locked-down Blue Team state or has the offensive surface unlocked. Combined with the always-on mode banner (§4), this means the device never hides its posture from whoever is holding it.

   NAVIGATION MODEL
   ─────────────────────────────────────────────
   home (grid) ──tap group──▶ subsystem screens ──tap──▶ capability screen
       ▲                           │                         │
       └────────── back ───────────┴──────── back ───────────┘
   (flat, two-to-three taps deep; live views update in place)

8.4 VALHALLA gating and Blue Team mode

The firmware’s single most important design feature for a reference reader is not any one module — it is the VALHALLA protocol, the gate every offensive capability sits behind.

   VALHALLA GATE (first offensive use)
   ═══════════════════════════════════════════════════════
            power on / open an offensive subsystem
                           │
                 ┌─────────▼──────────┐
                 │  LIABILITY         │
                 │  DISCLAIMER shown  │
                 └─────────┬──────────┘
            ACCEPT ────────┤──────── DECLINE
               │           │            │
      ┌────────▼───────┐   │   ┌────────▼─────────────┐
      │ VALHALLA mode  │   │   │ BLUE TEAM mode       │
      │ offensive tools│   │   │ defensive + passive  │
      │ unlocked       │   │   │ modules ONLY         │
      └────────────────┘   │   └──────────┬───────────┘
                           │              │
                           │   persists across reboots
                           │   (banner shows BLUE TEAM)
                           ▼
                  mode banner reflects the choice on the home screen

Table 2 — 4. VALHALLA gating and Blue Team mode

Mode	Reached by	What runs	Persists?
VALHALLA	Accepting the liability disclaimer	The full offensive surface plus defensive tools	Until changed
Blue Team	Declining the disclaimer	Defensive and passive modules only — detection, monitoring, recon-of-self	Yes, across reboots

What this means in practice: a HaleHound can be deliberately kept as a defensive instrument. Declining VALHALLA leaves a persistent, reboot-surviving Blue Team device that can detect jamming, spot deauth floods, scan for surveillance infrastructure, and survey RF — with the transmit-capable offensive categories locked out. The banner makes the posture auditable. For an owner who wants the jam-detect and detection suites without carrying a live attack tool, Blue Team mode is the supported configuration, and it is the configuration this hub treats as the baseline for any carry-everywhere use (see Vol 9’s OPSEC section).

Warning — VALHALLA is a liability gate, not an authorization. Accepting it unlocks capabilities; it does not make any particular use lawful. Transmitting on licensed or protected bands, interfering with communications, accessing cards or devices you do not own, or spoofing identifiers can be illegal regardless of what the device will technically do. The authorization rule for everything in VALHALLA mode is: own the target hardware, or hold written authorization to test it. The full envelope is in Vol 12 and ../_shared/legal_ethics.md.

A separate 4-digit boot PIN (Settings) adds a casual-access lock on top of the mode system. As noted in Vol 7 §9, a PIN is a deterrent, not data-at-rest protection — a full flash erase resets it — so it guards against a glance, not against someone with a USB cable.

8.5 The capability map by subsystem

The table below is the capability surface at category level: each subsystem, the radio behind it, the classes of capability, and whether the class is offensive (VALHALLA-gated) or defensive/passive (available in Blue Team mode). It intentionally states functions, not module names or procedures.

Table 3 — 5. The capability map by subsystem

Subsystem	Radio	Capability categories (what class of thing)	Posture
Wi-Fi	ESP32 built-in	Frame monitoring/capture; targeted disassociation & flooding; rogue-AP / evil-twin credential harvest; handshake & PMKID capture	Offensive (monitoring is passive)
Bluetooth (BLE)	ESP32 built-in	Advertising/pairing spam; GATT recon + honeypot; tracker detect & spoof (Find-My-class ecosystems); published-CVE probes against consumer chipsets	Offensive (tracker detect is passive)
2.4 GHz	NRF24L01+PA+LNA	Band scan & spectrum view; promiscuous packet sniffing; broadband carrier output; wireless-HID keystroke-injection class	Offensive (scan/spectrum passive)
Sub-GHz	CC1101 (300–439 MHz)	OOK capture, replay, and code-generation brute force; spectrum analysis; saved-/.sub-file playback	Offensive (spectrum passive)
NFC / RFID	PN532 V3 (SPI); Chameleon Ultra over BLE; ST25R3916 (stub)	Card scan, read, clone, key brute force, emulate (MIFARE class); NTAG read/write/lock suite	Offensive (scan passive)
Drone	NRF24 + ESP32 (dual)	Remote ID detect & fingerprint; Remote ID spoof; broadband carrier; targeted control-link disassociation	Mixed (detect passive)
Jam Detect	All, by band	Detect deauth floods, sub-GHz carrier jamming, broadband 2.4 GHz jamming, or all bands at once	Defensive
SIGINT	Wi-Fi + GPS	Handshake/PMKID capture; probe auto-response; GPS-tagged wardriving; LAN recon; surveillance-infrastructure detection; unified loot browser	Mixed (wardriving/detection passive)
Tools	—	Serial passthrough, OTA update, touch calibrate, live GPS view, radio hardware self-test	Neutral
Settings / About	—	Display, timeout, colour mode, rotation, device info, PIN, CC1101-module select; firmware/armed-module status	Neutral

The split that matters for carry posture:

   OFFENSIVE vs DEFENSIVE/PASSIVE (what Blue Team keeps)
   ─────────────────────────────────────────────────────────
   VALHALLA-only (transmit/attack classes)   │ Blue Team keeps (RX / detect)
   ──────────────────────────────────────────┼──────────────────────────────
   Wi-Fi deauth / flood / rogue-AP / harvest  │ Wi-Fi monitor / scan
   BLE spam / honeypot / CVE probes / spoof   │ BLE + tracker DETECT
   2.4 GHz carrier / HID injection            │ 2.4 GHz scan / spectrum
   sub-GHz replay / brute / carrier           │ sub-GHz spectrum (RX)
   NFC clone / brute / emulate                │ NFC scan / identify
   drone RID spoof / carrier / deauth         │ drone + RID DETECT
   —                                          │ ALL Jam-Detect
   SIGINT handshake capture / probe-respond   │ wardriving / infra detection

8.6 Radio-level categories in detail

Each subsystem below is described by what class of work it does and why, with the posture called out. No operating steps are given.

8.6.1 Wi-Fi (ESP32 built-in)

All Wi-Fi work uses the ESP32’s own radio — no external hardware — in a concurrent AP+STA mode so the device can scan on one side and inject on the other. The capability classes are the standard offensive-Wi-Fi set: passive frame monitoring and capture (defensive-usable), targeted disassociation and flooding (denial of a link), rogue-AP / evil-twin credential harvest (a fake access point with a captive portal), and handshake / PMKID capture (collecting the material used offline to test WPA key strength). The live packet-rate and activity-meter screens are feedback, not a separate capability. Max Wi-Fi TX is +20.5 dBm (§9).

8.6.2 Bluetooth / BLE (ESP32 built-in)

BLE also uses the built-in radio, with the firmware handling the Wi-Fi↔BLE radio teardown so the two do not collide. The categories: advertising / pairing spam (nuisance and denial against BLE device UIs), GATT recon and honeypot (enumerating a device’s services, then presenting a cloned connectable server), tracker detection and spoofing across the Find-My-class item-tracker ecosystems (the detection half is defensive and is the relevant one for counter-surveillance — compare the SquachWatch and AirTags deep dives), and published-CVE probes against consumer Bluetooth chipsets. On that last class: the firmware packages probes tied to publicly disclosed CVEs in consumer audio and fast-pair ecosystems. At category level the point is that these are known, patched-or-patchable vulnerabilities being exercised; the specific trigger details are out of scope here and are covered by the CVE disclosures themselves. BLE TX is +9 dBm.

8.6.3 2.4 GHz (external NRF24L01+PA+LNA)

The NRF24 radio covers the raw 2.4 GHz ISM band beneath Wi-Fi/BLE framing. Categories: band scanning and spectrum visualisation (passive, and genuinely useful for RF survey), promiscuous packet sniffing of the simple 2.4 GHz protocols used by wireless keyboards, mice and some drones, broadband carrier output (a denial class affecting Wi-Fi, BLE, Zigbee and peripherals alike), and the wireless-HID keystroke-injection class against vulnerable proprietary keyboard/mouse dongles. A dedicated tuning panel exposes SPI clock, power, data rate, dwell and channel parameters as live controls, with the settings saved to SD — this is what lets the same radio serve both the survey and the attack categories. With the PA module the NRF24 transmits at +20 dBm.

8.6.4 Sub-GHz (external CC1101, 300–439 MHz)

The CC1101 covers the sub-GHz OOK/ASK bands where garage doors, gate remotes, simple sensors and legacy keyfobs live. The store lists the module as “300–928 MHz,” but the firmware scopes its features to 300–439 MHz — treat 300–439 MHz as the real operating window. Categories: capture, replay and code-generation brute force (the classic fixed-code OOK workflow, with de-Bruijn-sequence generation for common encoders), a spectrum analyser (passive, with peak-hold and noise-floor calibration), and saved-signal and Flipper-.sub-file playback from the SD card. Stock TX is +12 dBm; the optional E07-433M20S PA module raises that to +20 dBm (and requires the independent 3.3 V buck — Vol 3). This subsystem is where the authorization line is sharpest: replaying or brute-forcing access-control RF against anything you do not own is where “capability” becomes “crime,” and the vendor’s inclusion of vehicle- and gate-oriented demonstrations does not change that.

8.6.5 NFC / RFID (PN532, Chameleon Ultra, ST25R3916 stub)

The NFC subsystem opens a backend picker, then runs a card suite. The PN532 V3 in SPI mode is the default backend and runs the full suite: scan/identify, read, clone, key brute force, and emulate, centred on the MIFARE Classic family, plus a separate NTAG read/write/lock suite for NTAG213/215/216-class tags. A Chameleon Ultra can be driven over BLE as an alternate backend for NTAG work and key recovery (this is the integration documented in the Chameleon Ultra deep dive — HaleHound is the one that drives it). A third backend, ST25R3916, is present as a wired-up stub with the driver still in development. All of the clone/brute/emulate categories are offensive in the sense that matters legally: they target physical access credentials, which are almost never yours to duplicate without authorization.

8.6.6 Drone / Remote ID (dual-radio)

The drone suite runs two radios at once — the NRF24 sniffing for BLE drone presence while the ESP32 sweeps Wi-Fi in promiscuous mode — on separate cores so neither blocks the other. Categories: passive Remote ID detection and fingerprinting (flagging drones by ASTM F3411 RID plus SSID/BLE signatures — this is the defensive, situational-awareness half), Remote ID spoofing (broadcasting a forged RID beacon over Wi-Fi and BLE), broadband carrier output, and targeted control-link disassociation. The detect half is legitimate airspace awareness; the spoof and carrier halves transmit on bands and in ways that are heavily regulated, and interfering with an aircraft’s control link is categorically out of bounds outside a licensed, authorized test range.

   DUAL-RADIO CONCURRENCY (drone detect / full-spectrum jam-detect)
   ───────────────────────────────────────────────────────────────
     Core 0 ── ESP32 Wi-Fi promiscuous sweep ─┐
                                              ├─▶ fused detection view
     Core 1 ── NRF24 2.4 GHz / BLE presence ──┘
     (passive RX on both; no transmit in the detect classes)

8.7 The defensive and passive suites

These are the categories that survive into Blue Team mode and make HaleHound usable as a defensive instrument.

Table 4 — 7. The defensive and passive suites

Suite	Class	What it watches for
Jam Detect — Wi-Fi	Defensive	Deauthentication / disassociation flood detection
Jam Detect — Sub-GHz	Defensive	Carrier / continuous-wave jamming on sub-GHz
Jam Detect — 2.4 GHz	Defensive	Broadband 2.4 GHz disruption
Jam Detect — Full Spectrum	Defensive	All bands monitored concurrently (dual-radio)
SIGINT — Wardriving	Passive	GPS-tagged AP logging to SD (survey, mapping)
SIGINT — Surveillance-infra detection	Passive	BLE fingerprinting of ALPR-camera / sensor infrastructure, GPS-tagged
SIGINT — Loot browser	Neutral	On-device review of captured data across categories
Tracker / drone detect	Passive	Find-My-class item trackers; Remote ID presence

The jam-detect suite is the clearest defensive story: it is a portable spectrum-health monitor that flags the three jamming modalities most likely to precede or accompany an attack (deauth floods before an evil-twin, sub-GHz carrier against an alarm, broadband 2.4 GHz against everything). The surveillance-infrastructure detection and tracker-detect categories overlap directly with the counter-surveillance mission of the SquachWatch and AirTags deep dives — the same CYD platform, aimed at detection rather than attack. An owner who only wants this wing should run the device in Blue Team mode.

8.8 Tools and Settings

Two neutral menus support everything above and are worth knowing for build bring-up and day-to-day use.

Tools — a serial-passthrough terminal (UART bridge); the OTA firmware updater (reads /firmware/ from SD — Vol 7 §8); the 4-corner touch calibration tool; a live GPS/NMEA satellite view; and Radio Test, a hardware self-test that verifies each external radio is wired and responding and carries 4-page visual wiring diagrams built into the firmware. Radio Test is the first stop after any Classic or Fire Weasel build (Vols 5–6) — it is how a builder confirms the CC1101, NRF24, PN532 and GPS came up before trusting any capability screen.

Settings — backlight brightness (PWM 10–255); screen timeout (30 s to Never); BGR↔RGB colour swap and display-invert toggles (the fixes for a panel that comes up with wrong colours, Vol 7 §7); a colour mode with Default / Colorblind / High-Contrast options; display rotation; device info (heap, CPU, flash, board name); the 4-digit boot PIN; and the CC1101 module selector that switches the firmware between the standard HW-863 module and the E07 PA module (the setting that must be flipped when the amplified sub-GHz module is installed — Vol 3).

Table 5 — 8. Tools and Settings

Setting	Range / options	Why it matters
Brightness	PWM 10–255	Battery life vs daylight legibility
Screen timeout	30 s / 1 m / 2 m / 5 m / 10 m / Never	Power saving; “Never” for bench monitoring
Swap Colors	BGR ↔ RGB	Panel-variant colour fix (Vol 7)
Invert Display	on/off	Normally-black vs normally-white panel fix
Color Mode	Default / Colorblind / High-Contrast	Accessibility, not a panel fix
Rotation	0° / 90° CW / 90° CCW / 180°	Match enclosure orientation
Set PIN	4-digit	Casual-access deterrent (resets on erase)
CC1101 Module	HW-863 / E07 PA	Must match the installed sub-GHz module

The CC1101-module selector is the one setting that is not cosmetic or convenience: selecting E07 when the amplified module and its independent 3.3 V buck are installed is what enables the +20 dBm sub-GHz path and the module’s TX/RX-enable control lines. Leaving it on HW-863 with an E07 fitted, or vice versa, is a common reason a correctly wired PA module does not perform — the firmware is not driving the enable lines the module needs (Vol 3).

8.9 Transmit power and what “max everywhere” means

The firmware’s stated policy is that every attack radio runs at maximum power — “no training wheels.” For a reference reader the table matters as much for the legal/RF-safety reading as for the range one.

Table 6 — 9. Transmit power and what "max everywhere" means

Radio	Max TX power	Notes
Wi-Fi (ESP32)	+20.5 dBm	Built-in radio, no external hardware
NRF24 + PA + LNA	+20 dBm	Requires the PA module + independent 3.3 V buck (Vol 3)
CC1101	+12 dBm stock / +20 dBm with E07 PA	PA module needs the independent buck; enable in Settings
BLE (ESP32)	+9 dBm	Built-in radio

   TX POWER AT A GLANCE (dBm)
   ───────────────────────────────────────────────
   Wi-Fi        ████████████████████▌  +20.5
   NRF24+PA     ████████████████████   +20
   CC1101+E07   ████████████████████   +20
   CC1101 stock ████████████           +12
   BLE          █████████              +9
   ───────────────────────────────────────────────

Warning — “Max power everywhere” is a deliberate design stance, not a licence. +20 dBm (100 mW) into a gain antenna on sub-GHz or 2.4 GHz can exceed the unlicensed-operation limits of most jurisdictions, and continuous-carrier / jamming classes are illegal to transmit in nearly all of them regardless of power. The power table is a capability ceiling; the lawful operating envelope is set by local regulation and the own-hardware-or-written-authorization rule, not by what the radio can push. Antenna choice and band matter — see Vol 3 for the RF front end and Vol 12 for the legal envelope.

8.10 The SD loot layout

A FAT32 MicroSD is optional for running but is where everything the device captures or logs is written. Every folder is created or tolerated-missing gracefully; nothing on the card is required to boot. The layout is also the data-exposure surface — the card, not the firmware, is where sensitive captured material lives.

   SD CARD LAYOUT (FAT32)
   ──────────────────────────────────────────────────────────────
   /sd/
   ├── subghz/        .sub files + raw OOK dumps for sub-GHz playback
   ├── eapol/         WPA handshake / PMKID captures (hashcat format)
   ├── wardriving/    GPS-tagged AP logs (CSV)
   ├── wp_loot/       tracker / credential / infra-detection loot
   ├── loot/          BLE recon + honeypot capture
   ├── creds.txt      (optional) custom credential list for LAN recon
   ├── iot_recon.txt  LAN recon reports
   └── firmware/      OTA update .bin files (Vol 7 §8)

Table 7 — 10. The SD loot layout

Folder	Produced by (category)	Sensitivity
`subghz/`	sub-GHz capture/playback	Medium — captured RF of others’ devices
`eapol/`	Wi-Fi handshake/PMKID capture	High — key material for offline cracking
`wardriving/`	GPS-tagged AP survey	Medium — location + network inventory
`wp_loot/`, `loot/`	BLE recon / tracker / infra loot	High — can include credentials/PII
`creds.txt`, `iot_recon.txt`	LAN recon	High — credentials, internal network data
`firmware/`	OTA images (input, not loot)	Low

Note — Because a flash erase resets the PIN (Vol 7 §9), the SD card is the real place sensitive capture lives. Treat the card as the controlled artefact: encrypt the host copy, wipe between engagements, and keep nothing on it that an engagement’s authorization does not cover. OPSEC for the loot card is in Vol 9.

8.11 Cross-references

Vol 3 (radios) — the electrical reality behind every category here: CC1101/NRF24/PN532/GPS wiring, the independent buck for PA modules, the CC1101-module setting, and why TX power is what it is.
Vol 7 (flashing) — the home screen, Settings/Tools, and the VALHALLA/Blue-Team state all live after first boot; a full erase resets the mode and PIN.
Vol 9 (use cases) — where each category is the right (and authorized) tool, with field workflow and loot-card OPSEC.
Vol 11 (comparison) — how this capability surface stacks against the ESP32 Marauder (Wi-Fi/BLE firmware), Flipper Zero (sub-GHz/NFC), a Proxmark (NFC depth), a HackRF (true SDR) and the Chameleon Ultra it drives.
Vol 12 (cheatsheet/legal) — the authorization envelope that governs everything in VALHALLA mode, and ../_shared/legal_ethics.md.
Sibling dives — SquachWatch and AirTags for the detection/counter-surveillance mission that overlaps HaleHound’s defensive wing on the same CYD platform.

HaleHound Volume 8 — Capabilities and the Touch UI