Figure 1 — The Sky-Spy eagle logo.

Image: colonelpanichacks (GitHub).

9.1 About this Volume

This volume covers the two outer edges of the OUI-SPY ecosystem. The first, Sky-Spy, is squarely within the passive-detection tradition of every volume so far: it listens for drones broadcasting Remote ID and maps them. It is covered in full depth.

The second edge is different in kind. The ecosystem’s author has stated that an offensive “Red Edition” is in development alongside the all-passive “Blue Edition” that ships today. Two public repos represent that side — Remote-ID-Spoofer and Oui-Spy-UniPwn. These are transmitting, offensive tools, and this volume treats them at category level only: what class of tool each is, why the Blue/Red split exists, and where the legal and ethical line falls. There are deliberately no attack procedures, no command sequences, and no reproduced menus for the Red tools anywhere in this dive. That is a hard editorial rule, not an oversight — the detectors are defensive instruments and documenting them fully is useful; the offensive tools are named and situated, and nothing more.

Built from the Sky-Spy and Remote-ID-Spoofer READMEs (colonelpanichacks, fetched 2026-10-16), the ecosystem edition statements, and the shared-core facts of Vols 3–8. Reference voice throughout; no bench work is on record.

9.2 Remote ID — the standard Sky-Spy listens to

Sky-Spy makes no sense without the standard it keys on. Remote ID is, in effect, a “digital licence plate” for drones: a regulatory requirement that most drones broadcast their identity and position so that anyone nearby — regulators, law enforcement, or a curious person with a receiver — can see what is flying and roughly where its operator is standing.

The technical specification is ASTM F3411, implemented in practice by the open-source OpenDroneID project. It defines a small set of message types a drone broadcasts in the clear over two radio links:

Table 1 — drone broadcasts in the clear over two radio links

Message type	Carries	What Sky-Spy extracts
Basic ID	the drone’s unique identifier	`basic_id`
Location	drone position/altitude (and, in spec, speed/heading)	`drone_lat`, `drone_long`, `drone_altitude` (m MSL)
System	operator/pilot location, area info	`pilot_lat`, `pilot_long`
Operator ID	the registered operator identifier	operator ID

The two radio links Remote ID uses are the two radios the XIAO already has:

Wi-Fi RID — broadcast in Wi-Fi beacon / probe frames and in NAN (Neighbor Awareness Networking) action frames carrying vendor-specific information elements, on the Remote-ID standard channel 6.
BLE RID — broadcast in BLE advertisements under service UUID 0xFFFA.

Because it is an open broadcast standard designed to be publicly readable, Remote ID is a perfect passive-detection target: a receiver needs no keys, no association, and no cooperation from the drone. It just has to be listening on the right channel for the right frames — which is exactly what Sky-Spy does.

Callout — Remote ID broadcasts the pilot’s location, not just the drone’s. The System message carries the operator/ground-station position. That is by design — the point of Remote ID is accountability — but it means a passive receiver like Sky-Spy can, from the ground, read both where a drone is and where its pilot is standing. This is a defensible situational-awareness capability, and also a privacy consideration worth stating plainly.

9.2.1 Why Remote ID exists, and why it is a clean detection target

Remote ID was mandated to solve an accountability problem: as consumer and commercial drones proliferated, there was no way for a person on the ground — or an authority — to tell a hobbyist’s quadcopter from one surveilling a property, nor to identify who was flying it. The regulatory answer (FAA 14 CFR Part 89 in the United States, EU Regulation 2019/945 in Europe, with parallels elsewhere) was to require most drones to continuously broadcast a small, standardised, unencrypted identity-and-position message while airborne. It is deliberately a public signal, the airborne analogue of a licence plate.

That public-by-design quality is exactly what makes it an ideal passive-detection target, and why a $7.50 board can do something genuinely useful with it:

 encrypted / proprietary signal Remote ID (ASTM F3411)
 ───────────────────────────── ──────────────────────
 needs keys, pairing, association broadcast in the clear
 receiver must defeat crypto receiver just has to listen
 legally fraught to decode designed to be publicly read
 → hard, often unlawful → trivial, intended use

There is a civil-liberties symmetry worth naming. The same community energy that produced the DeFlock mapping of Flock ALPR cameras (Vol 2) — citizens documenting the surveillance infrastructure pointed at them — also drives drone-awareness tooling: a person who wants to know whether a drone overhead is watching them, and who is flying it, is making the same move. Sky-Spy is the drone-facing instance of the ecosystem’s recurring theme: reading the public signals that watching devices emit, to even the informational asymmetry. The drone broadcasts to be accountable; Sky-Spy is a tool for holding it to that account from the ground.

9.3 Sky-Spy — passive drone detection

Sky-Spy is the official OUI-SPY firmware for detecting Remote-ID-broadcasting drones over both Wi-Fi and BLE. Its own README is unambiguous about its posture: “This device is a passive receiver only” and “Does not transmit or interfere with drone operations.” It is receive-only — the clean counterpart to the Red tools in §6, and the reason the Blue/Red line is meaningful.

9.3.1 The dual-radio decoder

Sky-Spy runs the two radios on the two cores of the ESP32-S3 so Wi-Fi and BLE reception proceed in parallel rather than time-sliced:

 ┌─────────── Core 0: Wi-Fi RID ───────────┐ ┌──────── Core 1: BLE RID ────────┐
 │ promiscuous mode, locked on channel 6 │ │ active scan, 100 ms interval, │
 │ (Wi-Fi Remote-ID standard channel) │ │ 1 s scan duration │
 │ capture beacon + probe-request frames │ │ service UUID 0xFFFA (RemoteID) │
 │ parse OpenDroneID NAN action frames │ │ monitor ASTM F3411 adverts │
 │ extract vendor-specific IEs │ │ │
 └────────────────────┬────────────────────┘ └───────────────┬─────────────────┘
 └──────────────┬─────────────────────────┘
 ▼
 decode ASTM F3411 message types
 (Basic ID / Location / System / Operator ID)
 ▼
 JSON over USB serial @ 115200 baud
 ▼
 mesh-mapper.py (§4)

The decoded fields emitted over serial are mac, rssi, drone_lat, drone_long, drone_altitude (metres above mean sea level), pilot_lat, pilot_long, and basic_id.

Caveat — the README’s feature list over-claims. The features section lists speed and heading extraction, but neither appears in the documented serial fields or the sample JSON. Treat drone speed/heading output as — the Location message carries them in the ASTM spec, but the firmware’s published field set stops at position and altitude.

Running the two radios on separate cores is a meaningful architectural choice. Every dual-domain detector in the family (Vol 7) time-slices one radio because it must share a single front end between Wi-Fi scanning and BLE scanning on the same hop schedule. Sky-Spy instead dedicates Core 0 to the Wi-Fi RID path (locked on channel 6 — it never hops, because Remote ID has a fixed Wi-Fi channel) and Core 1 to the BLE RID path. Because the Wi-Fi side does not hop, the two paths do not contend the way a hopping detector’s do, and both links can be watched continuously and in parallel. The cost is that a Sky-Spy build is single-purpose: it is listening for one protocol on known channels, not sweeping for arbitrary signatures.

9.3.2 Audio and the auto-stop contradiction

Sky-Spy keeps the family’s audio vocabulary: a detection plays 3 beeps at 1000 Hz, 150 ms each; a heartbeat plays a double beep at 600 Hz, 100 ms each, every 5000 ms; a status message prints every 60 s.

Caveat — the README contradicts itself on auto-stop. The Features section says the heartbeat “stops after 7 seconds with no drone detected”; the Audio Alert Behavior section says it stops “after 30 seconds of no detection.” The two numbers are not reconciled in the document. State both; do not pick one as fact. The practical effect is minor (how long the heartbeat keeps ticking after the last drone leaves), but it is a real inconsistency.

9.3.3 Resource footprint and boards

The README reports a modest footprint — RAM 21.0% (68,928 / 327,680 bytes), flash 42.9% (1,433,678 / 3,342,336 bytes), with per-task stacks of BLE 10 KB, Wi-Fi 10 KB, printer 10 KB, buzzer 4 KB — which is why the same firmware runs on the small XIAO parts. Boards:

Table 2 — small XIAO parts. Boards

Board	SoC / radio	Build / variant	Notes
Seeed XIAO ESP32-S3	ESP32-S3, 8 MB flash / 8 MB PSRAM	primary	reference target; see Vol 3
Seeed XIAO ESP32-C6	ESP32-C6, Wi-Fi 6, BLE 5.3	alternative	newer radio
Seeed XIAO ESP32-C5	ESP32-C5, dual-band 2.4 + 5 GHz	`xiao-c5-5g/`	README describes the variant dir only; hardware section does not list the C5 —
Official OUI-SPY board	ESP32-S3 + integrated PWM buzzer	—	colonelpanic.tech

The C5 dual-band variant is the interesting one for drones specifically, because some Remote-ID Wi-Fi traffic and drone control links use 5 GHz — a 2.4 GHz-only receiver can miss them. Treat the C5 build as present-but-underdocumented until confirmed.

[FIGURE SLOT — Vol 9 §3.3] Photo of a Sky-Spy build (XIAO ESP32-S3/C6/C5) and/or a screenshot of the decoded serial JSON for a captured Remote-ID frame.

9.4 mesh-mapper — turning detections into a live map

Sky-Spy’s serial JSON is consumed by mesh-mapper.py, a host-side Flask + Socket.IO web application that plots detected drones and their operators on a live map. This is where the capability becomes situational awareness rather than a beep: a moving marker for each drone with its altitude and a separate marker for the pilot position decoded from the System message.

9.4.1 Architecture

 Sky-Spy (XIAO) ──USB serial JSON──► mesh-mapper.py (Flask + Socket.IO,:5000)
 │
 ├─ live web map (browser)
 │ Leaflet 1.9.4 / MapLibre GL
 │ Leaflet.draw, Socket.IO
 │ (all vendored under static/)
 │
 └─ offline basemaps via MBTiles
 tiles/ (empty on fresh clone)
 tools/cache_tiles.py pre-caches

The web app runs on port 5000 (--web-port N to change it). First run presents a port-selection screen at /select_ports, saved to selected_ports.json.
The frontend is fully vendored (Leaflet 1.9.4, MapLibre GL, Leaflet.draw, Socket.IO under static/), so it works without a CDN — appropriate for a tool meant to run in the field, offline.
Basemaps are MBTiles. A fresh clone ships an empty tiles/ directory, so you must cache basemaps before field use with tools/cache_tiles.py (bounding boxes, presets, resumable downloads). The README explicitly warns that OSM’s main tile server forbids bulk download — cache from a permitted source.

Callout — this is a mapping tool; the map is only as good as its cache. The “empty tiles/ on fresh clone” detail is a genuine field gotcha: a Sky-Spy rig that was never pre-cached will plot drones onto a blank grey map in an area with no connectivity. Pre-caching the operating area’s MBTiles is part of field prep, not an afterthought.

The result is the ecosystem’s most spatial Blue tool. Where Foxhunter (Vol 8) localises one emitter by walking a gradient, mesh-mapper localises many drones at once by reading the positions the drones broadcast about themselves — no walking, because Remote ID hands over GPS coordinates directly.

9.4.2 Defensive and situational-awareness uses

Framed as a defensive instrument, Sky-Spy answers a small set of concrete questions, all from pure reception:

Table 3 — questions, all from pure reception

Question	What Sky-Spy reads
Is there a Remote-ID drone near me right now?	detection beep + live marker
How high / how far is it?	`drone_altitude` (m MSL), position vs my location
Where is the operator standing?	`pilot_lat` / `pilot_long` from the System message
Which drone is it (identity)?	`basic_id`, Operator ID
Was a drone here earlier?	mesh-mapper track history on the map

Those are legitimate counter-surveillance and safety interests — knowing whether a drone is observing a property, a protest, or a private event, and being able to say which one and whose. The limits are equally concrete: Sky-Spy sees only drones that broadcast Remote ID, so a non-compliant or deliberately non-broadcasting drone is invisible to it (its silence is itself a datum — a drone with no Remote ID is either very old, home-built, or evading the rule). It also cannot do anything about a drone; it reads, maps, and beeps. Acting on a drone — jamming, spoofing, taking it over — is both a different technical problem and, in nearly every jurisdiction, illegal, which is precisely the line §5–7 draw.

9.5 The Blue / Red line

Everything through §4 of this volume — and every volume before it — is Blue Edition: passive detection, mapping, and direction finding. The author has stated that an offensive Red Edition is in development. Understanding why the project draws that line is the point of the rest of this volume.

 ┌──────────────────── BLUE EDITION (shipping) ────────────────────┐
 │ POSTURE: receive / detect / map / direction-find │
 │ flock-you · Detector · axeoff · PCAP · BLE-Sniff · Foxhunter · │
 │ Sky-Spy · Unified Blue │
 │ RF behaviour: listen-only (Wi-Fi) + active BLE scan on some │
 │ modes (the "passive" asterisk) — but NEVER forges/injects │
 └─────────────────────────────────────────────────────────────────┘
 ═══════ the line ═══════
 ┌──────────────── RED EDITION (stated, in development) ───────────┐
 │ POSTURE: transmit / spoof / exploit │
 │ Remote-ID-Spoofer · Oui-Spy-UniPwn │
 │ RF behaviour: actively transmits crafted frames / exploits │
 │ → CATEGORY LEVEL ONLY in this dive. No procedures. │
 └─────────────────────────────────────────────────────────────────┘

The line is not about which radio or which board — the Red tools run on the same XIAO-class hardware. It is about posture: does the firmware listen to the RF environment, or does it inject into it? A detector that only receives cannot, by construction, interfere with a drone, forge a licence plate, or disrupt a device. A tool that transmits crafted frames can. That difference is the whole reason the project separates the editions and ships only Blue by default.

There is a neat symmetry that makes the split easy to reason about: several Red tools are the active inverse of a Blue tool that already exists. Sky-Spy receives Remote ID; Remote-ID-Spoofer transmits it. The same decode logic that lets Sky-Spy read an OpenDroneID frame is, run backwards, the encode logic a transmitter needs — which is why the two live in the same ecosystem and why the author can frame the offensive side as the “Red” counterpart of the defensive “Blue” side rather than an unrelated project. The editions are two directions of the same knowledge: one reads the RF environment, the other writes to it.

Table 4 — 5 The Blue / Red line

Blue (reads)	Red counterpart (writes)
Sky-Spy — receives/decodes Remote ID	Remote-ID-Spoofer — transmits Remote-ID-format frames
detectors — observe device signatures	Oui-Spy-UniPwn — acts on a specific device class

9.6 The Red Edition at category level

The two offensive repos, described only as classes of tool — what they are, and nothing about how to operate them.

9.6.1 Remote-ID-Spoofer

Class: a Remote-ID transmitter — the active inverse of Sky-Spy. Where Sky-Spy passively receives and decodes the Remote-ID broadcasts drones emit, Remote-ID-Spoofer generates and broadcasts Remote-ID-format signals over the air (Wi-Fi NAN action frames and AP-beacon vendor IEs). In plain terms: Sky-Spy reads the digital licence plates; this tool is a device that can emit fabricated ones.

Why it is separate: it transmits. A passive receiver and a frame transmitter are categorically different tools with categorically different legal footing (§7). It is MIT-licensed and its README carries a prominent legal warning that it is for “educational, research, and authorized security testing purposes only,” noting that transmitting spoofed Remote-ID signals is illegal in many jurisdictions and citing FAA 14 CFR Part 89 and EU Regulation 2019/945 as examples, with a warning not to operate near active airspace or airports.

No operation, configuration, frame construction, or command detail appears in this dive. The entry stops at “it is a Remote-ID transmitter, and here is the law.”

9.6.2 Oui-Spy-UniPwn

Class: an ESP32 port of a published exploit (Bin4ry’s “UniPwn”) targeting Unitree robots. It is an exploitation tool, not a detector or a spoofer — its subject is a specific vendor’s robotic platforms rather than the RF environment at large.

Why it is separate: it is offensive by definition — it exists to exploit a target device, not to observe one. That places it firmly on the Red side of the line, and it is the clearest example in the ecosystem of a tool whose legitimate use is confined to the owner of the target hardware or an explicitly authorised assessment.

No exploit mechanism, payload, target-interaction, or command detail appears in this dive — consistent with the hard editorial rule stated in §1. The entry records only that the repo exists, what class of tool it is, and that its legitimate use is bounded by authorisation (§7).

Callout — why name them at all? Completeness and honesty. A reference that silently omitted the Red repos would misrepresent the ecosystem, which publicly includes them. Naming and situating them — while refusing to document their operation — is the correct posture for a defensive-tooling reference: the reader learns the ecosystem has an offensive edge, understands why it is fenced off, and is pointed at the law rather than at a how-to.

9.7 The legal and ethical line

The Blue/Red distinction maps almost exactly onto the legal distinction that runs through all of surveillance-detection tooling: receiving is broadly permissible; transmitting and exploiting are heavily regulated.

Table 5 — 7 The legal and ethical line

	Blue (detectors / Sky-Spy)	Red (spoofer / UniPwn)
RF action	receive (+ active BLE scan on some modes)	transmit / exploit
Typical legal footing	generally lawful to receive public broadcasts; local rules on decoding vary	transmitting forged Remote ID and exploiting others’ devices is restricted or illegal in most jurisdictions
Example regimes	—	FAA 14 CFR Part 89; EU Reg. 2019/945; computer-misuse / unauthorised-access statutes
Legitimate use	situational awareness, privacy auditing, research	owner’s own hardware or explicit written authorisation only
Posture in this dive	documented in depth	category level only

Three principles the whole hub applies, stated here because the Red edge makes them sharp:

Receiving a public broadcast is not the same act as transmitting one. Remote ID is designed to be read; reading it (Sky-Spy) is the intended use of a public signal. Forging it (Remote-ID-Spoofer) injects false information into a safety system and is treated very differently by aviation regulators.
Exploitation is lawful only against hardware you own or are authorised to test. Oui-Spy-UniPwn’s only defensible use is against Unitree robots the operator owns, or under an explicit, written authorisation. There is no “curiosity” exemption in computer-misuse law.
The project ships Blue by default, and so should the operator’s posture. The firmware that comes off the web flasher is passive. Keeping it that way — and treating any move to the Red side as a deliberate, authorised, documented act — is the posture the edition split is designed to encourage. Vol 10 develops this into the “passive by default” operating stance and the local-RF-law checklist.

The ethical summary is simple: the detectors in this ecosystem exist to let a person know when they are being surveilled, which is a legitimate counter-surveillance and privacy interest. The Red tools exist to act on other systems, which is legitimate only within ownership or authorisation. This dive documents the first in full and fences off the second deliberately.

A final practical point on why the fence matters even for a lawful researcher: the Red tools transmit, and transmitting leaves a far larger footprint than listening. A passive detector is, to the outside world, indistinguishable from any other quiet 2.4 GHz device; a Remote-ID transmitter is announcing fabricated aircraft into a safety system, and a device exploit is reaching into someone else’s hardware. Both are the kind of act that is logged, attributable, and prosecutable where unauthorised. The posture the edition split encourages — Blue by default, Red only as a deliberate, authorised, documented step — is as much self-protection for the operator as it is respect for the law and for the people and systems around them.

9.8 Where this leaves the ecosystem

With this volume the full OUI-SPY map is on the table:

A flagship Flock detector with a forensic, firmware-dump-sourced, tier-graded signature engine (Vols 4–6).
A module family spanning a configurable general detector, a single-vendor headless detector, and two raw-capture instruments (Vol 7).
A direction finder that walks you to a single emitter by RSSI (Vol 8).
A drone Remote-ID detector and mapper that reads the digital licence plates drones broadcast and plots them, pilots included (this volume, §2–4).
A fenced-off offensive edge — a Remote-ID transmitter and a robot-exploit port — named, situated, and deliberately left undocumented (§5–7).

The through-line is posture. Seven of the nine Blue tools are receive-oriented; two (the Detector and Foxhunter) carry the active-BLE-scan asterisk; the two Red tools transmit or exploit and are out of scope by rule. That gradient — from pure listening, through brief solicitation, to active injection — is the single most important thing to understand about the whole ecosystem, and it is what Vol 10 turns into an operating doctrine, alongside the build/flash paths, the first-run AP-credential map, and the head-to-head comparison against SquachWatch, Nyan Box and HaleHound.

OUI-SPY Volume 9 — Drones & the Red Edge