Fork-worthiness matrix · research reference implementations · transmitting-vs-non-emitting target classification

10.1 About this volume

This volume surveys every open-source and DIY project worth evaluating for a camera-detector build — with enough depth to make a concrete fork decision. It is the intelligence layer between the three build paths in Vols 7–8 and the research literature in Vol 4: it names what is real, what is production-grade vs. lab-only, what each license permits, how mature the code is, and — most importantly — which camera emission classes a given project can actually address.

The key analytic contribution of this volume is a transmitting-vs-non-emitting classification applied consistently across every project and every research paper surveyed here. This is the split that determines fork selection:

Transmitting-camera projects (LocCams, CamLoPA) operate via 802.11 network signals that require the camera to be on Wi-Fi and actively transmitting. They are completely blind to SD-only cameras and wired cameras. They are excellent for the headline Wi-Fi camera scenario, useless for the hardest case.
EMI-based projects (CamRadar, EM Eye, SpyDir) detect involuntary electromagnetic emanations from camera clock circuitry. They require the camera to be powered but do not require any intentional wireless transmission — meaning a powered SD-only camera without radio hardware is detectable. They do not catch fully-powered-off cameras.
Optical and thermal research (LAPD, HeatDeCam) target specific physical properties — retroreflection and heat — that also require power (heat) or exist regardless of power (optics).
Framework tools (ESP32 Marauder, Nyan Box approach) are the practical fork bases for the Wi-Fi / network detection path — they catch transmitting cameras only.

[FIGURE SLOT — Vol 10, § 1] Screenshot of an ESP32 Marauder station-scan result on an AWOK Dual Touch V3 module, showing MAC addresses with OUI-resolved manufacturer labels. This is the starting point for the camera-vendor filter added in the Vol 8 fork design. Source: Photo Helper search “ESP32 Marauder station scan display OUI” — or AWOK Dynamics / justcallmekoko GitHub Wiki screenshot. Caption when filled: “Figure 10.1 — ESP32 Marauder’s station-scan output showing OUI-resolved manufacturer labels. The camera OUI filter in the Vol 8 fork design operates on these MACs. Photo: File:Name.jpg by . .”

Provenance. Maturity, license, and performance claims in this volume are spec-/survey-sourced pending bench verification, except for the four verified academic paper results (LAPD SenSys’21, CamRadar IMWUT’22, EM Eye NDSS’24, HeatDeCam CCS’22) which are carried over from Vol 4’s web-verified citations. LocCams (DOI 10.1145/3631432) and CamLoPA (arXiv 2409.15169) are web-verified in this authoring pass. SpyDir (arXiv 2602.00411) is web-verified as a preprint.

Volume map. This volume consumes Vol 3 §5 (traffic-rate/motion-correlation — the robust Wi-Fi detection tell underlying LocCams, CamLoPA, and the Vol 7/8 traffic-rate accumulator), Vol 4 (research papers and the non-emitting power-state matrix), and Vols 7–8 (the three build paths this survey feeds). It produces the fork-worthiness matrix (§6), which is consumed by Vol 8 §5 (decision guide) and Vol 14 (comparisons and decision guide).

10.2 ESP32 Marauder

10.2.1 What Marauder is

ESP32 Marauder (justcallmekoko, github.com/justcallmekoko/ESP32Marauder) is a production-grade 802.11 + BLE pentest firmware for the ESP32 and ESP32-S3 microcontrollers. It is the highest-traffic, most actively maintained open-source Wi-Fi audit firmware in the ESP32 ecosystem — hundreds of GitHub stars, a large community of contributors, and ported builds for every major ESP32 pentest module including the AWOK Dual Touch V3 and Ruckus Game Over units that tjscientist owns.^[ESP32 Marauder GitHub: https://github.com/justcallmekoko/ESP32Marauder. Full firmware architecture, build system, and feature-set coverage is in the ESP32 Marauder Firmware deep dive.]

License: MIT (confirmed via GitHub LICENSE file, web-verified 2026-06-26). The MIT license is maximally permissive: fork, modify, redistribute, and ship proprietary derivatives with no copyleft obligation. Attribution to justcallmekoko is required in copies. There is no GPL restriction on derivative builds.

Supported hardware: ESP32 (WROOM/WROVER), ESP32-S3 (WROOM-1 series, including the ESP32-S3-WROOM-1-N8R8 used in the Vol 7 from-scratch design), AWOK Dual Touch V3, Ruckus Game Over, Flipper Zero Wi-Fi Devboard, and several third-party pentest boards. Marauder’s AWOK and Game Over ports are actively maintained by community contributors and ship release binaries on the GitHub releases page.

Maturity: Production. Active development since 2020. Build system: PlatformIO with a published platformio.ini. Per-release changelogs; active issue tracker; community wiki covering every build target. Codebase is C++, ESP-IDF v5.x compatible, well-structured with per-feature source files.

Activity: High. Multiple firmware releases per year; pull requests from community contributors add capture modes, display adaptations, and hardware ports. The firmware is not going away.

10.2.2 Camera-detection capability out of the box

Marauder has no dedicated camera-detection mode. The features it provides that are useful as a camera-detection foundation:

Table 1 — 2.2 Camera-detection capability out of the box

Marauder feature	Camera-detection relevance
`scanap` — beacon capture with SSID, BSSID, channel, RSSI, OUI lookup	First-pass network enumeration: camera APs and the host network the camera has joined both appear here
`scansta` — station enumeration from data-frame source MACs	The raw MAC list that the camera OUI filter operates on
Promiscuous callback (`esp_wifi_set_promiscuous_rx_cb()`)	The tap point for a traffic-rate accumulator; every captured frame arrives with RSSI, channel, frame size, and timestamp
`setchannel N` — explicit channel lock	Required before starting an RSSI walk on a confirmed target; stops the channel hopper
OUI lookup in AP scan	Manufacturer resolution in the AP scan display — not camera-specific, but the OUI infrastructure is already present
SD card PCAP logging	Captures traffic for offline traffic-rate analysis even if real-time display is not yet implemented
`scanble` — BLE station enumeration	Catches BLE-advertising cameras (rare but real — see Vol 1 §4.4) with zero additional code
RSSI display in station list	Per-client signal-strength field; the raw data for the RSSI-walk EMA filter and walk-mode UI added in the fork

The OUI lookup in Marauder resolves AP manufacturer from the BSSID in the AP scan — it is not a per-station field in the station list. The station list shows MAC addresses. The camera OUI filter described in Vol 8 §2.4 operates on those station MACs in software: Marauder is the starting point, not a camera fingerprinter.

Callout — what Marauder does NOT provide out of the box: (1) A camera-vendor OUI filter on the station list — without it all devices are equally weighted and camera candidates are invisible in the noise. (2) A traffic-rate accumulator — the robust tell from Vol 3 §5 is absent from stock Marauder. (3) A confidence scorer combining OUI match with traffic-rate history. (4) A dedicated RSSI-walk display mode. The fork in Vol 8 §2 supplies all four. This is a precise gap list, not a criticism of Marauder: it is a Wi-Fi pentest tool, not a camera finder — which is exactly why it is the ideal foundation. Everything below those four layers is already built, tested, and running on owned hardware.

10.2.3 The camera-layer gap

The four layers the fork must add sit cleanly on top of Marauder’s existing architecture, each building on the layer below:

┌──────────────────────────────────────────────────────────────────┐
│               MARAUDER FORK — CAMERA-LAYER STACK                 │
├──────────────────────────────────────────────────────────────────┤
│  LAYER 4 — RSSI-walk UI (fork adds)                             │
│    Full-screen EMA-smoothed needle/bar gauge                     │
│    250 ms update; numeric dBm; trend arrow; channel-lock confirm │
├──────────────────────────────────────────────────────────────────┤
│  LAYER 3 — Confidence scorer (fork adds)                        │
│    OUI match weight + traffic-rate spike weight                  │
│    Sustained spike over N intervals → HIGH / MED / LOW rating   │
├──────────────────────────────────────────────────────────────────┤
│  LAYER 2 — Traffic-rate accumulator (fork adds)                 │
│    Per-client frame-size ring buffer in promiscuous callback     │
│    500 ms tick: compute rolling average; set motion-corr flag   │
├──────────────────────────────────────────────────────────────────┤
│  LAYER 1 — Camera OUI filter (fork adds)                        │
│    Embedded camera-vendor OUI table (~50 prefixes, 3 bytes each)│
│    Applied to station MAC list → camera candidate list           │
├──────────────────────────────────────────────────────────────────┤
│  MARAUDER BASE (existing — no changes)                           │
│    scanap / scansta / promiscuous callback / OUI DB              │
│    Channel hop and lock / SD PCAP / BLE scan / display UI       │
└──────────────────────────────────────────────────────────────────┘

Layer 1 (OUI filter) is a small embedded data table plus a prefix comparison in the scan loop — a few KB of flash. Layer 2 (traffic-rate) requires per-client ring buffers and a background tick timer — the largest structural addition. Layers 3 and 4 are display-side logic that rides on the existing Marauder UI framework. The complete fork design, including pseudo-code for each layer, is in Vol 8 §2.

10.2.4 Fork-worthiness assessment

Table 2 — 2.4 Fork-worthiness assessment

Criterion	Assessment
License	MIT — permissive; no copyleft; fork freely, ship proprietary if needed; attribution required in copies
Maturity	Production; 4+ years active development; large community; no abandonment risk
Build system	PlatformIO — same toolchain as the from-scratch Vol 7 design; no new dependencies
Target hardware	Runs on owned AWOK Dual Touch V3 and Ruckus Game Over — zero hardware cost to start; AWOK also has the dual-display advantage for a RSSI-walk gauge
Camera-detection gap	Four well-defined layers to add (§2.3); each is small and orthogonal; full fork design in Vol 8 §2
Emission class coverage	2.4 GHz Wi-Fi and BLE only; no 5 GHz; no analog-cam RF sweep; no optical lens-finder add-on in stock form
Risk	Lowest fork risk of the three build paths — extending proven, community-tested code rather than writing a Wi-Fi stack from scratch
Overall	HIGH — recommended fast path when AWOK Dual Touch V3 or Ruckus Game Over is in hand

10.2.5 Clone and build sketch

The starting-point sequence for a Marauder fork targeting the AWOK Dual Touch V3 (owned hardware). This opens the fork session described in Vol 8 §2.

# Clone the Marauder repository
git clone https://github.com/justcallmekoko/ESP32Marauder.git
cd ESP32Marauder

# Install PlatformIO once if not present
pip install platformio

# List available build environments to find the AWOK target
grep "^\[env:" platformio.ini

# Build and flash for AWOK Dual Touch V3
# (env name varies by version — check the repo wiki; commonly "awok_dual_touch_v3")
pio run -e awok_dual_touch_v3 -t upload --upload-port /dev/ttyUSB0

# Verify flash succeeded: the device should boot into Marauder's main menu
# Then create a fork branch for the camera-detection layer
git checkout -b camera-detect

After verifying the stock build flashes and runs, add the camera-detection layer per Vol 8 §2. The fork source lives in projects/camera_marauder/ in the CameraDetection project directory.

10.3 Nyan Box fingerprint DB

10.3.1 Native camera detection

The Nyan Box (Nyan Devices) is a multi-radio educational handheld (ESP32-WROOM-32U + 3× NRF24L01+ + OLED + 2500 mAh) with a native Camera Detector feature — one of its two standout capabilities that nothing else in the Hack Tools lineup covers natively. The hidden-camera detection is factory firmware, not a fork or add-on. See the Nyan Box deep dive for the full hardware platform, firmware architecture, and 12-volume treatment.

What the native camera detection does, from Nyan Devices product documentation and community reports:

Scans for Wi-Fi access points and associated client stations using the ESP32’s built-in radio in promiscuous / scanning mode.
Applies a multi-brand OUI fingerprint database (20+ camera brands documented in Nyan Devices marketing and community teardowns) against detected MACs to identify known camera-vendor OUI prefixes across Hikvision, Dahua, Wyze, Reolink, Amcrest, Tapo/TP-Link, Eufy/Anker, Blink/Amazon, and additional brands.
Computes a confidence score from multiple heuristics: OUI match weight, detection of mDNS/SSDP camera-specific service announcements, and signal-strength behavior consistent with a streaming device.
Displays a real-time RSSI-walk meter — a bar UI that updates as the user moves toward the detected camera candidate — enabling physical localization.
Distinguishes camera-like devices from generic Wi-Fi clients with enough specificity to reduce false positives compared to a raw OUI lookup.

The Nyan Box is the closest available off-the-shelf approximation of the detector built in Vols 7–8. Vol 11 covers using the Nyan Box as-is for a room sweep.

10.3.2 The fingerprint DB as a fork seed

The Nyan Box camera fingerprint database is the most directly relevant existing dataset for any DIY Wi-Fi camera finder. It is a curated, camera-specific subset of the IEEE OUI database, augmented with per-brand heuristics developed by Nyan Devices through real-world testing across documented camera brands.

Table 3 — 3.2 The fingerprint DB as a fork seed

Brand category	Coverage notes
Budget Chinese OEM (Hikvision, Dahua, HiLook, Tiandy, white-labels)	Broad — these brands dominate the surveillance market; their OUI prefixes are well-documented in the IEEE OUI DB
US consumer brands (Wyze, Reolink, Amcrest, Eufy/Anker)	Confirmed coverage — these are the brands most commonly found in vacation-rental surveillance incidents
Amazon ecosystem (Blink, Ring)	Ring uses specific Sidewalk-adjacent OUIs; Blink has distinct prefixes under Amazon’s registered OUI space
Smart-home platforms (Tapo/TP-Link, Arlo, Nest/Google)	Present in the DB but complex — TP-Link shares OUI space across routers and cameras, requiring secondary service-type filtering to avoid false positives
Industrial / pro (Axis, Hanwha, Bosch Security)	Partial — these are lower priority for the vacation-rental sweep scenario but relevant for corporate/institutional sweeps

Reconstructing the DB from public sources. Since the Nyan Box firmware source is closed (see §3.3), the fingerprint database must be reconstructed using the IEEE OUI database and known camera-vendor OUI prefixes. The pipeline:

Download the IEEE OUI database: curl -O https://standards-oui.ieee.org/oui/oui.txt
Filter for camera-vendor registrants by company name (search “Hikvision”, “Dahua Technology”, “Wyze Labs”, “Reolink”, “Amcrest Technologies”, “Anker Innovations”, etc.)
Extract the 24-bit OUI prefixes for each matched organization
Supplement with known camera-specific service fingerprints: mDNS _rtsp._tcp, ONVIF WS-Discovery response, RTSP port 554 open, ONVIF port 8899 open
Encode the OUI prefix table as a compact embedded structure (see Vol 7 §5 build_oui_db.py design)

The Vol 7 OUI fingerprint DB build (§5) performs this exact pipeline. Reference OUI prefixes for the major brands include: Hikvision 00:24:C8, 44:19:B6, 48:EA:23, BC:AD:28; Dahua 90:02:A9, 9C:D3:E5, 3C:E8:24; Wyze 2C:AA:8E, D0:3F:27, 34:CE:00; Reolink 10:62:EB, DC:DA:80; Amcrest 9C:8E:CD; Eufy 18:EC:E7, 04:D4:C4. TP-Link/Tapo prefixes (50:C7:BF, C4:E9:84, 7C:2E:BD) are shared with non-camera TP-Link products and require secondary filtering by service announcement.

10.3.3 Closed-source caveat

Callout — Nyan Box firmware is closed-source. The Nyan Box camera fingerprint database and detection firmware are not publicly available as source code. Nyan Devices publishes pre-compiled firmware binaries; the implementation is proprietary. The database contents — brand coverage, exact OUI prefixes beyond what is reconstructible from the IEEE OUI DB, confidence-scoring algorithm weights — are not directly forkable. What is forkable is the approach: a multi-heuristic camera-vendor fingerprint system combining OUI match, service-type identification, and RSSI-walk localization. The implementation must be built from scratch using the public IEEE OUI database pipeline in §3.2 and the detection framework in Vol 7 §5.

The Nyan Box is an aspirational tool (not in tjscientist’s possession as of 2026-06-26). All detection-capability claims are spec-sourced from Nyan Devices product documentation and community reports pending bench verification once the device is acquired.

10.3.4 Fork-worthiness assessment

Table 4 — 3.4 Fork-worthiness assessment

Criterion	Assessment
License	Proprietary / closed-source — not directly forkable as code
DB brand coverage	20+ camera brands; the most camera-specific OUI reference dataset available for reconstruction
Approach fork-worthiness	HIGH — the multi-heuristic OUI + service-type + confidence scoring architecture is the right design; must be reimplemented from public sources using the §3.2 pipeline
Code fork-worthiness	Not applicable — no source available
Hardware as a build target	The Nyan Box ESP32-WROOM-32U + OLED is a capable platform; however the Vol 7 ESP32-S3-WROOM-1-N8R8 design is more capable for a purpose-built detector (more RAM, faster CPU, larger flash, better display options)
Practical action	Reconstruct the DB using §3.2; build detection firmware per Vol 7 or Vol 8; use the Nyan Box (once acquired) as the reference behavior target for comparison testing

10.4 GitHub detector repos

10.4.1 Open-project landscape overview

The open-source camera-detection space divides cleanly into four project categories, each attacking the Wi-Fi detection problem from a different angle. No single project covers all emission classes; the landscape is a collection of components, not a turnkey solution.

┌──────────────────────────────────────────────────────────────────────────┐
│               OPEN-SOURCE CAMERA-DETECTION LANDSCAPE MAP                 │
├─────────────────────────────────┬────────────────────────────────────────┤
│  NETWORK-SCANNER FINDERS        │  TRAFFIC-ANALYSIS SCRIPTS              │
│  ────────────────────           │  ──────────────────────                │
│  Kismet (Wi-Fi monitor daemon)  │  scapy-based flow monitors             │
│  nmap NSE RTSP/ONVIF scripts    │  tshark + display filter pipelines     │
│  avahi-browse + wsdd ONVIF      │  aircrack-ng / airodump-ng             │
│  ONVIF WS-Discovery probes      │  tcpdump + post-process Python         │
├─────────────────────────────────┼────────────────────────────────────────┤
│  RASPBERRY PI SNIFFER BUILDS    │  HOBBY ESP32/ARDUINO BUILDS            │
│  ─────────────────────          │  ──────────────────────                │
│  cam_sniff.py-style pipelines   │  Marauder forks + camera OUI filter    │
│  Kismet + custom REST parsers   │  ESP8266 AP-scanner camera variants    │
│  Motion-correlation dashboards  │  Arduino + CC1101 RF scanner hybrids   │
│  Flask/FastAPI browser UIs      │  M5Stack BLE camera-scan apps          │
└─────────────────────────────────┴────────────────────────────────────────┘

  ALL FOUR CATEGORIES: TRANSMITTING Wi-Fi/IP CAMERAS ONLY
  SD-only / wired cameras → Vol 4 methods; not addressable by any tool here

Callout — transmitting cameras only, all four categories. Every tool in §4 targets cameras that are actively transmitting on a Wi-Fi network. SD-only cameras (no radio hardware) and wired cameras (PoE/coax to DVR/NVR) are completely invisible to every tool in this section. This is constraint #1 from Vol 1 §7.1 — repeated here because open-source repositories rarely state this limitation explicitly. A user who runs these tools against a room containing a wired or SD-only camera, gets a clean result, and concludes the room is safe has received false assurance. For non-emitting cameras, see Vol 4’s power-state matrix and the research implementations in §5 of this volume that address the powered-but-non-transmitting case. The third running constraint: analog 1.2/2.4/5.8 GHz cameras need a HackRF/RTL-SDR spectrum sweep (Vol 6); cellular/4G cameras need IMSI-adjacent methods (Vol 4) — neither is a Wi-Fi tool’s job, and neither §4 tool addresses them.

10.4.2 Network-scanner-based camera finders

Kismet (github.com/kismetwireless/kismet). License: GPL-2.0. Maturity: production (originally 2001; active development by Mike Kershaw / dragorn; major releases annually).

Kismet is not a camera-specific tool but is the most capable open platform for building one. Relevant capabilities:

Passive 802.11 monitor-mode capture across all channels (automatic channel hopping with configurable per-channel dwell)
Per-device OUI resolution (pluggable OUI database)
SSID and device tracking with persistent logging to SQLite (kismet.db)
REST API at http://localhost:2501/ for real-time device list access — the integration point for a camera-detection overlay
Alert system (ADHOC, PROBENOJOIN, NESTEDSSID, custom matchers) extensible via Python plugins

A camera-finding overlay on Kismet:

Poll the REST API /devices/views/all/devices.json for the current device list
Filter by camera-vendor OUIs (Vol 7 §5 table)
Flag devices advertising _rtsp._tcp or responding to ONVIF WS-Discovery probes
Watch per-device data-rate time series (Kismet logs signal_dbm and packet counts per device) and flag motion-correlated uplink bitrate spikes (Vol 3 §5)

Kismet is best suited to the Raspberry Pi sniffer path (Vol 8 §4) — it is too heavy for the ESP32 handheld path and requires a host running as a daemon.

nmap NSE camera scripts. The nmap NSE library includes scripts for RTSP discovery (rtsp-url-brute, rtsp-methods) and ONVIF probe (community onvif-probe.nse variants). Running:

nmap -p 554,8899,80,8080,443 --script rtsp-methods,http-title <subnet>

surfaces IP cameras on-network that have RTSP port 554 or ONVIF port 8899 open. Applicable only to cameras on the same network as the scanning host — does not work in monitor mode against off-network cameras.

avahi-browse + ONVIF WS-Discovery. On Linux, avahi-browse -at displays all mDNS/DNS-SD service advertisements on the local network; a camera announcing _rtsp._tcp or _onvif._tcp appears immediately. An ONVIF WS-Discovery probe (multicast SOAP to 239.255.255.250:3702) elicits Hello responses from ONVIF-compliant cameras even when they are not advertising via mDNS.

10.4.3 Wi-Fi traffic-analysis scripts

The traffic-rate / motion-correlation technique (Vol 3 §5) is the most robust Wi-Fi camera-detection method — it works even when OUI fingerprinting fails due to MAC randomization or generic module OUIs. The open-source building blocks for implementing it:

tshark / Wireshark-based flow capture. A streaming camera produces a sustained uplink data rate whose bitrate envelope tracks motion in front of the lens. Capturing this:

# Put Wi-Fi adapter into monitor mode (Linux)
sudo ip link set wlan1 down
sudo iw dev wlan1 set type monitor
sudo ip link set wlan1 up
sudo iw dev wlan1 set channel 6

# Capture data frames and log per-frame timestamp, source MAC, and size
tshark -i wlan1 \
  -f "type data" \
  -e frame.time_relative -e wlan.sa -e frame.len \
  -T fields -E separator=, \
  2>/dev/null > /tmp/cam_flow.csv

# Compute 5-second rolling average uplink rate per source MAC in Python
python3 - << 'PYEOF'
import csv, collections, itertools

data = []
with open('/tmp/cam_flow.csv') as f:
    for row in csv.reader(f):
        try:
            t, mac, sz = float(row[0]), row[1].strip(), int(row[2])
            if mac:
                data.append((t, mac, sz))
        except (ValueError, IndexError):
            continue

WINDOW = 5.0
by_mac = collections.defaultdict(list)
for t, mac, sz in data:
    by_mac[mac].append((t, sz))

for mac, frames in sorted(by_mac.items()):
    frames.sort()
    peak_bps = 0
    for i, (t0, _) in enumerate(frames):
        window_bytes = sum(sz for (t, sz) in frames if t0 <= t < t0 + WINDOW)
        bps = window_bytes * 8 / WINDOW
        if bps > peak_bps:
            peak_bps = bps
    print(f"{mac}  peak {peak_bps:>10.0f} bps in {WINDOW}-s window")
PYEOF

The output is a ranked list of source MACs by peak uplink bitrate. A camera streaming 1080p H.264 at VBR produces 1–8 Mbps depending on scene motion. A phone checking email produces short bursts of <100 kbps. The distributions are distinguishable without decryption — only the outer envelope of the encrypted frames is needed.

scapy-based monitor-mode sniffer (Python sketch). Scapy (GPL-2.0) provides Python-native 802.11 frame capture. The design pattern for a camera-detection filter:

from scapy.all import sniff, Dot11, Dot11QoS, RadioTap
from collections import defaultdict
import time, threading

# Camera-vendor OUI prefix table (24-bit prefixes, uppercase, colon-delimited)
CAMERA_OUIS = {
    "00:24:C8": "Hikvision", "44:19:B6": "Hikvision",
    "48:EA:23": "Hikvision", "BC:AD:28": "Hikvision",
    "90:02:A9": "Dahua",     "9C:D3:E5": "Dahua",
    "3C:E8:24": "Dahua",     "2C:AA:8E": "Wyze",
    "D0:3F:27": "Wyze",      "34:CE:00": "Wyze",
    "10:62:EB": "Reolink",   "DC:DA:80": "Reolink",
    "9C:8E:CD": "Amcrest",   "18:EC:E7": "Eufy",
    "04:D4:C4": "Eufy",
    # ... extend with full Vol 7 §5 table
}

flow = defaultdict(lambda: {"bytes": 0, "frames": 0, "last_t": time.time()})

def pkt_handler(pkt):
    if not pkt.haslayer(Dot11):
        return
    mac = pkt[Dot11].addr2
    if not mac:
        return
    oui = mac[:8].upper()
    brand = CAMERA_OUIS.get(oui)
    n = len(pkt)
    flow[mac]["bytes"] += n
    flow[mac]["frames"] += 1
    if brand:
        print(f"  [CAMERA CANDIDATE] {brand} {mac}  {n} B")

sniff(iface="wlan1mon", prn=pkt_handler, store=0)

This is a design sketch; the full cam_sniff.py implementation — including the rolling-window motion-correlation scorer, confidence tier output, and channel-hopping scheduler — is in Vol 8 §4.4.

10.4.4 Raspberry Pi monitor-mode sniffer builds

The Raspberry Pi monitor-mode path (Vol 8 §4) is the highest-capability DIY option for the Wi-Fi camera-detection problem. The generic community pattern:

Table 5 — The Raspberry Pi monitor-mode path (Vol 8 §4) is the highest-capability DIY option for the Wi-Fi camera-detection problem. The generic community pattern

Component	Typical choice	Notes
Pi model	Pi 3B+ or Pi 4 (4 GB)	Pi 4 preferred for RAM headroom when running Flask UI alongside scapy/Kismet
Monitor-mode adapter	Alfa AWUS036AXML (Wi-Fi 6, AX1800) or AWUS036ACH (AC1200)	Alfa adapters have driver-level monitor mode on Linux; reliable across kernel versions
Built-in chip option	Pi 3B+ BCM43455 with nexmon patch	Community-maintained nexmon provides monitor mode on the onboard chip; 5 GHz support varies by nexmon version
Capture framework	scapy (MIT), Kismet (GPL-2.0), or airodump-ng (GPL-2.0)	Kismet is highest-maturity; scapy most flexible for custom processing pipelines
Flow analysis	Python pandas rolling windows or custom per-MAC ring buffers	The Vol 3 §5 algorithm maps directly to a pandas `rolling(window).mean()` on a per-MAC byte time series
UI	Flask or FastAPI + browser dashboard, or terminal curses	Browser UI makes the walk-to-camera display ergonomic; curses is lower overhead

The build sequence for monitor-mode setup (this is the preamble to any Pi-based camera-detection session):

# Raspberry Pi OS Bookworm, Python 3.11+, Alfa AWUS036ACH on USB

# Bring up monitor mode on the external adapter
sudo ip link set wlan1 down
sudo iw dev wlan1 set type monitor
sudo ip link set wlan1 up
sudo iw dev wlan1 set channel 6      # lock to target channel; hop in software

# Verify monitor mode is active
iw dev wlan1 info | grep type        # should print "monitor"

# Install scapy and Flask (once)
pip install scapy flask

# Run the minimal cam_sniff sketch in monitor mode (expand per Vol 8 §4.4)
sudo python3 cam_sniff.py --iface wlan1 --channel 6 --web-ui

The --channel N argument locks the adapter to a specific channel for the RSSI walk. In a full sweep, the sniffer hops across 1, 6, 11 (and 5 GHz channels if the adapter supports them) on a configurable dwell schedule and locks when a camera candidate is confirmed.

5 GHz note. Many modern IP cameras connect on 5 GHz to avoid 2.4 GHz congestion. The Alfa AWUS036AXML (AX1800 Wi-Fi 6) supports 5 GHz monitor mode. The Pi’s onboard BCM43455 with nexmon supports 5 GHz in principle but patch-version compatibility must be verified before deployment. A scanner that covers only 2.4 GHz misses any camera on 5 GHz.

10.4.5 Hobby ESP32 and Arduino builds

A category of hobby projects applies the camera-detection approach on microcontroller hardware. Named specific repos are omitted here where web-verification is uncertain; the categories are real and the pattern is well-established.

Table 6 — 4.5 Hobby ESP32 and Arduino builds

Category	Description	Typical license	Maturity
Marauder-derived camera forks	Forks of ESP32 Marauder adding a camera-vendor OUI filter and a dedicated scan output mode; most add only Layer 1 of the four-layer stack (§2.3); few add traffic-rate or RSSI-walk	MIT (inherits Marauder base)	Hobby; variable maintenance; rarely surpass stock Marauder as a base
ESP8266 AP-scanner camera finders	Standalone AP-beacon scanners that match SSID patterns (camera brand names) and OUIs; simpler than Marauder forks; cannot do station-level traffic capture (limited to AP discovery, not client enumeration)	MIT or GPL-3.0 typically	Hobby; mostly dormant; less capable than Marauder
Arduino + CC1101 hybrid builds	ESP32 or Arduino MCU + CC1101 sub-GHz transceiver; targets 433/868 MHz OOK/FSK cameras alongside Wi-Fi; rare; covers only the analog-FM or FSK camera sub-population on those frequencies	Variable	Prototype-grade
M5Stack / Cardputer BLE scan apps	BLE-advertising camera finders on M5StickC, Cardputer, or similar ESP32-S3 hardware; scan BLE advertisers; match camera-vendor BLE device-name prefixes	MIT typically	Prototype-grade

Assessment. The hobby category provides useful component code — OUI table structures, RSSI display widgets, BLE device-name matchers. None has reached the maturity or test coverage of the Marauder base. Fork-worthiness as a base: LOW (use Marauder instead). Fork-worthiness for components: moderate — extract what you need and integrate into the Marauder or Pi path.

10.4.6 Category survey: license and maturity

Table 7 — 4.6 Category survey: license and maturity

Project / category	License	Maturity	Wi-Fi cam detection	Non-emitting cam detection	Fork-worthiness
ESP32 Marauder (justcallmekoko)	MIT	Production	Partial (OUI infrastructure; no camera mode)	❌	HIGH — add the 4-layer camera stack per Vol 8 §2
Kismet (dragorn)	GPL-2.0	Production	Strong (monitor + REST API + per-device data-rate)	❌	MEDIUM — Pi-sniffer path; copyleft if you ship derivatives
scapy (secdev)	GPL-2.0	Production	Strong (raw frame access; OUI match; flow analysis)	❌	HIGH as library — the Pi sniffer’s capture layer
airodump-ng / aircrack-ng	GPL-2.0	Production	Strong (station enumeration; RSSI; PCAP)	❌	LOW as fork base (binary tool; not a library)
nmap NSE camera scripts	NPSL / GPL	Production	On-network only (RTSP/ONVIF; no monitor mode)	❌	LOW standalone; useful as one step in a layered sweep
avahi-browse + wsdd	LGPL / GPL	Production	mDNS / WS-Discovery only (on-network)	❌	LOW standalone; complement to the Pi sniffer
Hobby Marauder forks	MIT (inherited)	Hobby / variable	Partial	❌	LOW as base; extract OUI tables or display code only
Pi sniffer builds (generic category)	Variable	Prototype	Strong (scapy/Kismet based)	❌	HIGH if built per Vol 8 §4 design

10.5 Research reference implementations

10.5.1 The transmitting-vs-non-emitting classification

Callout — research systems are proof-of-concept, not products. Every system surveyed in §5 is a research proof-of-concept demonstrated in controlled academic conditions. None is a shipping commercial product or a turnkey tool a user can deploy in a hotel room without significant SDR, ML, or specialized hardware infrastructure. They are cited because they define the state of the art, their detection techniques underpin the Vol 7/8 detection algorithms, and several have public code or datasets that serve as implementation references. Treat them as design inputs and physical-channel validation, not as deployable tools.

The classification axis that matters most for engineering decisions in this volume:

Table 8 — The classification axis that matters most for engineering decisions in this volume

Research system	Publication	Target camera class	Camera must be transmitting?	Approach
LAPD	ACM SenSys 2021	Any camera with a lens (any emission class, any power state)	No — lens is passive	Smartphone ToF sensor + deep learning on retroreflective signature
CamRadar	ACM IMWUT 2022	Powered cameras (any emission class)	No — detects clock EMI	Scene-modulated AM clock emanation via SDR
EM Eye	NDSS 2024	Powered cameras (any emission class)	No — detects image-sensor EMI	Video reconstruction from involuntary EM leakage via SDR
HeatDeCam	ACM CCS 2022	Powered / warm cameras (any emission class)	No — detects heat	FLIR ONE thermal camera + ML classification
LocCams	ACM IMWUT 2023	Wi-Fi cameras only	YES — requires 802.11 traffic	802.11 CSI + packet timing via commodity device
CamLoPA	IEEE S&P 2025	Wi-Fi cameras only	YES — requires 802.11 traffic	First Fresnel Zone signal-propagation path analysis
SpyDir	arXiv 2026	Powered cameras — any emission class	No — detects clock EMI	AoA of involuntary clock EMI via switching-antenna array

┌─────────────────────────────────────────────────────────────────────────────┐
│         TRANSMITTING vs NON-EMITTING TARGET SPLIT                           │
├────────────────────────────────────┬────────────────────────────────────────┤
│  TRANSMITTING (Wi-Fi) CAMERAS ONLY │  POWERED CAMERAS (any emission class)  │
│  LocCams (IMWUT 2023)              │  CamRadar (IMWUT 2022) — clock EMI      │
│  CamLoPA (IEEE S&P 2025)           │  EM Eye (NDSS 2024)   — image EMI recon │
│                                    │  HeatDeCam (CCS 2022) — thermal         │
│                                    │  SpyDir (arXiv 2026)  — clock EMI AoA   │
│                                    │                                          │
│                                    │  ANY POWER STATE (incl. fully OFF)      │
│                                    │  LAPD (SenSys 2021)   — optical lens    │
├────────────────────────────────────┼────────────────────────────────────────┤
│  SD-only / wired cam visible?      │  SD-only / wired cam visible?           │
│  ❌ NO — completely blind          │  ⚠ EMI/thermal: powered only            │
│                                    │  ✅ LAPD: yes, even fully off           │
└────────────────────────────────────┴────────────────────────────────────────┘

Callout — LocCams and CamLoPA are Wi-Fi tools only. LocCams and CamLoPA both operate by analyzing 802.11 signals emitted by the camera. They are explicitly not applicable to SD-only cameras or wired cameras, which produce no Wi-Fi signal. A surveillance scenario where the attacker chose a non-transmitting camera renders both systems completely blind. The spec initially grouped SpyDir with LocCams and CamLoPA as “transmitting only” — however SpyDir’s published paper (arXiv 2602.00411) explicitly states it works “with or without wireless communication architectures” via clock EMI detection, placing it in the powered-camera EMI column alongside CamRadar and EM Eye, not in the Wi-Fi-only column.

10.5.2 LAPD: optical, SenSys 2021

Full treatment in Vol 4 §5.3. Summary here for the open-source survey context.

Citation (web-verified): Sami, Tan, Sun, Han — “LAPD: Hidden Spy Camera Detection using Smartphone Time-of-Flight Sensors” — ACM SenSys 2021. DOI: 10.1145/3485730.3485941.^[Verified against ACM Digital Library and Semantic Scholar entries. SenSys 2021 = 19th ACM Conference on Embedded Networked Sensor Systems.]

Mechanism. Uses the Sony IMX516 iToF depth sensor present on Samsung Galaxy S20+ / S20 Ultra 5G / Note 10+ to detect the retroreflective signature of hidden camera lenses. The ToF sensor emits an IR pulse and LAPD applies a deep learning classifier to the phase-delay return pattern to identify lens-consistent retroreflection.

Performance (web-verified). 88.9% detection rate / 16.7% false positive rate in real-world evaluation with 379 participants across diverse hiding locations.

Target cameras. Any camera with a physical lens — SD-only, wired, Wi-Fi, analog. The lens is a passive optical element; LAPD works regardless of whether electronics are active, making it one of only three methods in the landscape that catches a fully powered-off camera (alongside NLJD and X-ray — see Vol 4 §4).

Code availability. No public GitHub repository confirmed at authoring time. The ToF sensor detection API is Samsung-proprietary and not available through standard Android camera APIs on other devices.

Fork-worthiness. LOW for code (no source; hardware-locked). HIGH for approach: LAPD validates that commodity smartphone sensors can detect camera lenses via retroreflection. Any future Android device exposing a comparable ToF API could re-implement it. The physical principle is already commercialized in the SpyFinder Pro product category.

10.5.3 CamRadar: EMI scene-detection, IMWUT 2022

Full treatment in Vol 4 §8.2. Summary for the open-source survey context.

Citation (web-verified): Liu, Lin, Wang, Shen, Ba, Lu, Xu, Ren — ACM IMWUT 6(4), 2022. DOI: 10.1145/3569505.^[Verified against ACM DL and Semantic Scholar. Presented at UbiComp/IMWUT 2022.]

Mechanism. A camera’s image-sensor readout circuit runs a periodic clock; the clock load varies with scene brightness (high photocurrent in a bright scene vs. low in a dark scene). This variation amplitude-modulates the camera’s unintentional EM emanation in the 1–3 GHz band. CamRadar transmits a controlled flickering light stimulus at the scene and correlates the resulting AM modulation in the camera’s clock emanation band with the stimulus, detected by an SDR receiver.

Performance (web-verified). 93.23% detection rate / 3.95% false positive rate in laboratory conditions.

Target cameras. Any powered camera with a running image sensor (SD-only, wired, Wi-Fi, analog). Requires the camera to be powered and operating; standby may produce weak clock emanation; fully off produces nothing. Does not require any intentional wireless transmission.

Code availability. No public GitHub repository confirmed at authoring time. The signal processing pipeline (AM demodulation at the clock frequency; scene-stimulus correlation) is described in sufficient detail in the paper for reconstruction.

SDR requirement. The receiver is an SDR covering the camera’s clock emanation band (approximately 1–3 GHz). A USRP B210 is the paper’s instrument. A tuned RTL-SDR or HackRF One (in receive-only mode) could serve as a lower-cost experiment platform; noise figure and dynamic range limitations will reduce effective range. Indoor experimental range in the paper was approximately 1–2 m from the camera — dominated by the SNR of the camera’s unintentional emission, not receiver bandwidth.

Fork-worthiness. LOW for direct code (no source). MEDIUM for approach: a CamRadar experiment using a HackRF One and GNU Radio is feasible. The signal-chain is reconstructible from the paper: receive at the clock frequency band, demodulate AM envelope, correlate with the known stimulus timing. The HackRF One in the toolkit is the starting platform; see Vol 11 §5.

10.5.4 EM Eye: EMI video reconstruction, NDSS 2024

Full treatment in Vol 4 §8.3. Summary for the open-source survey context.

Citation: Long, Jiang, Yan, Alam, Ji, Xu, Fu — NDSS 2024 (Network and Distributed System Security Symposium).

Mechanism. A camera’s image sensor reads out pixel rows sequentially; this readout process amplitude-modulates the camera’s involuntary EM emission in a way that encodes the video signal. EM Eye receives this emanation with a wideband SDR and applies signal processing and neural reconstruction to extract a recognizable video image from the unintentional EM signal — without intercepting any intended wireless transmission.

Performance. Demonstrated video reconstruction from camera EM leakage at ranges from approximately 30 cm to several meters, depending on camera design and SDR receiver sensitivity (spec-sourced from published paper summaries; precise performance is image-content and camera-model dependent).

Target cameras. Powered cameras of any emission class. Requires power-on for the image-sensor readout EMI; fully-off cameras emit nothing.

Code availability. EM Eye’s NDSS 2024 paper cites an artifact repository — web-verified search confirms the project has a public GitHub repository (search “EM Eye NDSS 2024 GitHub artifact”). Current maintenance status and commit recency are spec-sourced; verify against the paper’s supplemental material for the canonical artifact link.

SDR requirement. USRP B210 for the research system. RTL-SDR experimentation at very short range may produce detectable signal from the strongest camera emitters; fidelity drops sharply with lower SDR dynamic range and sensitivity.

Fork-worthiness. LOW for camera detection (EM Eye is a video-reconstruction demonstration, not a binary detection classifier). MEDIUM as SDR experiment infrastructure: the EM Eye artifact provides a physical-channel characterization platform. A simplified “camera-present / camera-absent” binary classifier on the same EMI signal is an engineering step from EM Eye’s more ambitious reconstruction goal, and would use the same hardware.

10.5.5 HeatDeCam: thermal classification, CCS 2022

Full treatment in Vol 4 §9.1. Summary for the open-source survey context.

Citation: Yu, Li, Chang, Fong, Liu, Zhang — ACM CCS 2022 (ACM Conference on Computer and Communications Security).

Mechanism. Hidden cameras are powered electronics producing waste heat. HeatDeCam attaches a FLIR ONE thermal camera to a smartphone, captures thermal images of the room, and applies an ML classifier trained on a large labeled thermal dataset to distinguish camera-module thermal signatures from other warm electronics (lamp transformers, USB chargers, Wi-Fi routers, power strips, occupant body heat).

Performance (web-verified from CCS 2022 abstract and proceedings summary). >95% detection rate in the paper’s evaluation. The paper also released a public labeled thermal-camera dataset of hidden-camera thermal signatures — the most fork-accessible artifact of the seven research systems surveyed here.

Target cameras. Powered cameras that are warmed up (image sensor, voltage regulator, and processor all contribute heat). Detection degrades for: cameras insulated by thick housing material, cameras in low-power standby, ambient room temperature close to the camera’s operating temperature, and dense clusters of warm electronics creating thermal clutter.

Code and dataset availability. The HeatDeCam paper cites a public thermal dataset through the CCS 2022 artifact evaluation process. A reference classifier implementation accompanies the dataset. The FLIR ONE hardware attachment is commercially available (~~$150–400 depending on generation); the FLIR Lepton 3.5 breakout module (~~$200) is a more hardware-accessible alternative for custom builds.

Fork-worthiness. MEDIUM. The dataset is the key fork asset — it enables training or fine-tuning a classifier for any FLIR-compatible thermal camera hardware. The main engineering barrier is thermal camera hardware, not the ML model. A HeatDeCam-inspired build integrating a FLIR Lepton 3.5 with the Vol 7/8 ESP32-S3 platform would fill the thermal triage capability gap in the handheld design. (Full thermal sweep is still limited by the FLIR ONE / pro price point — see Vol 9 §6.)

10.5.6 LocCams: Wi-Fi localization, IMWUT 2023

Citation (web-verified): “LocCams: An Efficient and Robust Approach for Detecting and Localizing Hidden Wireless Cameras via Commodity Devices” — Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies (IMWUT), Vol. 7, No. 4, December 2023. DOI: 10.1145/3631432.^[Web-verified against ACM Digital Library (doi.org/10.1145/3631432), ResearchGate listing, and the WHU datasec lab page (datasec.whu.edu.cn) which hosts the paper PDF. LocCams is indexed under UbiComp/IMWUT 2024 proceedings (December 2023 publication date).]

Mechanism. LocCams combines two techniques:

Detection — analyzes 802.11 packet inter-arrival time patterns and packet size distributions to identify traffic behavior consistent with a streaming video source. This is a structured extension of the traffic-rate / motion-correlation approach (Vol 3 §5), adding CSI-based analysis for greater robustness against MAC randomization.
Localization — after identifying a camera candidate by MAC address, applies a convolutional neural network to channel state information (CSI) subcarrier distributions to classify whether the propagation path is Line-of-Sight or non-Line-of-Sight, enabling coarse positional localization from a single measurement position.

Performance (web-verified). 95.12% overall detection and localization accuracy within 30 seconds of analysis, using a commodity device.

Target cameras. Wi-Fi cameras only. The detection mechanism operates entirely on 802.11 data frames from the camera. Completely blind to SD-only and wired cameras — there are no frames to analyze.

Code availability. No public repository confirmed at authoring time. The paper PDF is available from the WHU datasec lab page. Check the ACM DL artifact appendix for the canonical code link.

Hardware note. The CSI-based localization requires CSI data access, which is not available on standard retail 802.11 adapters. Options: Intel 5300 or Intel 9560 cards with the Linux CSI Tool (github.com/dhalperi/linux-80211n-csitool), or the Nexmon CSI patch for Broadcom chips (BCM4358/4339). The Raspberry Pi’s BCM43455 chip supports the Nexmon CSI patch with community-maintained support.

Fork-worthiness. MEDIUM. The traffic-rate detection component (Vol 3 §5) is already in the Vol 7/8 designs. The CSI-based localization offers a meaningful improvement in positional accuracy over RSSI-walk, but requires CSI-capable hardware not present in the ESP32 platform. Best implemented as an enhancement to the Pi sniffer path (Vol 8 §4).

10.5.7 CamLoPA: Wi-Fi propagation path, IEEE SP 2025

Citation (web-verified): “CamLoPA: A Hidden Wireless Camera Localization Framework via Signal Propagation Path Analysis” — IEEE Symposium on Security and Privacy (IEEE S&P) 2025. arXiv preprint 2409.15169.^[Web-verified against arXiv entry 2409.15169 (abs/2409.15169), ResearchGate listing, and the IEEE S&P 2025 program. Published at IEEE S&P 2025, the top-tier IEEE security venue; also available as full PDF at tianweiz07.github.io/Papers/25-sp-2.pdf.]

Mechanism. CamLoPA is training-free — no prior dataset collection is required. Detection relies on 802.11 packet transmission rate analysis (the Vol 3 §5 baseline). Localization uses the geometry of the First Fresnel Zone (FFZ): as a user moves through a room, the ratio of time spent crossing the First Fresnel Zone between themselves and the camera produces a characteristic signal-strength variation signature. By analyzing signal-level variation along the user’s movement path, CamLoPA estimates the camera’s azimuth angle and refines it to a quadrant without requiring CSI hardware or training data.

Performance (web-verified from arXiv and ResearchGate abstract). 95.37% snooping camera detection accuracy; average localization azimuth error of 17.23 degrees. Implementation platform: Raspberry Pi with standard 802.11 monitor-mode adapter — no specialized hardware.

Target cameras. Wi-Fi cameras only. Detection and localization depend entirely on 802.11 signals from the transmitting camera. Completely blind to SD-only and wired cameras.

Code availability. Implementation runs on a Raspberry Pi. No public GitHub repository was confirmed at authoring time through the IEEE S&P 2025 proceedings page; check the paper’s supplemental for a code artifact link.

Fork-worthiness. MEDIUM-HIGH. The FFZ-based localization is the strongest localization technique in this survey for an accessible hardware platform (Raspberry Pi + standard monitor-mode adapter):

No training data required — this is a major advantage over LocCams’ CSI-trained classifier for a one-off deployment in a hotel room
Hardware accessible — standard Raspberry Pi + any decent monitor-mode adapter; no custom silicon
17.23° azimuth error is sufficient for room-scale localization (walking toward the camera bearing reduces the search area from a full sphere to a 34° cone)
The detection phase maps directly to the Vol 3 §5 traffic-rate technique already in the Vol 7/8 designs

A CamLoPA-inspired localization refinement would be a high-value addition to the Vol 8 §4 Raspberry Pi sniffer design.

10.5.8 SpyDir: EMI direction finding, arXiv 2026

Citation (web-verified): “SpyDir: Spy Device Localization Through Accurate Direction Finding” — arXiv preprint 2602.00411 (February 2026).^[Web-verified against arXiv entry 2602.00411. As of authoring date (2026-06-26) this is a preprint without confirmed peer-reviewed conference or journal placement. Performance figures are from the preprint and should be treated as preliminary until peer review.]

Mechanism. SpyDir uses a portable switching-antenna array to estimate the angle of arrival (AoA) of involuntary electromagnetic emanations from spy device clock circuitry. CPUs and memory modules in IoT devices (including cameras) drive internal clock signals that produce spectrum-spread EM emissions that leak through PCB traces and interconnects. SpyDir captures these unintentional emissions, performs protocol-agnostic spectrum analysis (it does not decode any intended signal and does not depend on the device having any wireless interface), and applies direction-finding algorithms to localize the emitter in 2D.

Performance (web-verified from arXiv preprint). Average AoA error of 6.30°; 2D localization position error of 19.86 cm in real indoor environments; over 10–15× localization accuracy improvement vs. MUSIC and SpotFi baselines.

Target cameras. Any powered camera with a running clock/CPU — including SD-only cameras with no radio hardware. The paper explicitly states it works “with or without wireless communication architectures,” confirming that Wi-Fi is not required. The limiting condition is that the camera must be powered (the clock must be running to produce the EMI); a fully powered-off camera emits nothing. SpyDir is correctly classified in the powered-EMI column alongside CamRadar and EM Eye, not in the Wi-Fi-only column alongside LocCams and CamLoPA.

Code availability. arXiv preprint only at authoring time. No public code repository confirmed. The switching-antenna array is a custom hardware component; construction details are in the preprint.

Fork-worthiness. LOW for direct code fork (no code; custom switching-antenna hardware required). HIGH conceptually: SpyDir closes the gap that LocCams and CamLoPA leave open — it addresses powered cameras without Wi-Fi, including the SD-only camera that OUI fingerprinting completely misses. A simplified AoA experiment using two antennas and a phase-difference SDR implementation (no switching array) is a feasible starting point; the HackRF One is the candidate instrument.

10.5.9 Code availability and fork-ability summary

Table 9 — 5.9 Code availability and fork-ability summary

Research system	Public code?	Key fork asset	Prerequisite hardware	Practical fork path
LAPD	Not confirmed	Retroreflection physics validation; basis for SpyFinder Pro product class	Samsung Galaxy S20+ / S20 Ultra / Note 10+ (Sony IMX516 iToF)	Re-implement if Samsung iToF API access is secured; otherwise use SpyFinder Pro as the product equivalent
CamRadar	Not confirmed	Scene-stimulus AM correlation protocol; SDR methodology	SDR covering 1–3 GHz (RTL-SDR experiment; USRP B210 for paper-grade)	GNU Radio flowgraph experiment; reconstruct from paper signal-chain description
EM Eye	Artifact (NDSS 2024; verify URL in paper supplemental)	Full signal-chain reference; physical channel characterization	USRP B210 (paper); RTL-SDR / HackRF One (lower fidelity experiment)	Use artifact as SDR experiment starting point; build binary detector from reconstruction model
HeatDeCam	Public dataset (CCS 2022 artifact)	Labeled thermal camera dataset; reference ML classifier	FLIR ONE ($150–400) or FLIR Lepton 3.5 (~$200 module)	Retrain classifier on available FLIR hardware; integrate as sweep triage tool
LocCams	Not confirmed	CSI-based LOS/NLOS localization; traffic-rate detection component	CSI-capable Wi-Fi card (Intel 5300/9560 + Linux CSI Tool, or Nexmon on Pi BCM)	Implement per paper algorithm on Pi sniffer with CSI-capable adapter
CamLoPA	Not confirmed	Training-free FFZ localization; Raspberry Pi compatible	Raspberry Pi + monitor-mode Wi-Fi adapter (no CSI needed)	Implement per paper; no custom hardware; strongest candidate for Pi sniffer enhancement
SpyDir	Not confirmed	AoA of involuntary EMI; protocol-agnostic; SD-only capable	Switching-antenna array + wideband SDR	SDR experiment with HackRF One + two-antenna phase-difference AoA; no switching array initially

10.6 Fork-worthiness matrix

The load-bearing table for this volume. Rows ordered from highest to lowest overall fork-worthiness as a build starting point. “Fork-worthiness” means: is this project worth starting your build from, extracting components from, or implementing based on? Each row gets a single verdict.

Table 10 — 6. Fork-worthiness matrix

Project	What it does	License	Maturity	Covers non-emitting cams?	Fork-worthiness	Verdict rationale
ESP32 Marauder	802.11 + BLE scan firmware; Wi-Fi station enumeration; OUI lookup; PCAP logging; RSSI display	MIT	Production — 4+ yr, active, large community	❌ Wi-Fi and BLE only	HIGH	Best fast-path base for owned AWOK/Game Over hardware; four well-defined camera layers to add per Vol 8 §2; MIT license is unencumbered; active maintenance reduces risk
scapy	Python 802.11 frame capture and dissection library	GPL-2.0	Production — 15+ yr, active	❌ Wi-Fi only	HIGH (as library)	The standard building block for the Pi sniffer’s capture layer; mature API; copyleft requires source disclosure if you distribute scapy-derived code
Nyan Box approach (reconstruct)	Multi-heuristic OUI + service-type camera fingerprinting; 20+ brands; confidence score; RSSI walk	Proprietary firmware; IEEE OUI DB is public	Production (closed product)	❌ Wi-Fi only	MEDIUM-HIGH (approach)	Reconstruct from IEEE OUI DB + §3.2 pipeline; the most camera-specific reference fingerprint available; implement detection firmware per Vol 7 §5 / Vol 8 §3
CamLoPA (research)	Training-free FFZ-based Wi-Fi camera localization; 95.37% accuracy; Raspberry Pi	Research / not OSS yet	Conference paper (IEEE S&P 2025)	❌ Wi-Fi only	MEDIUM-HIGH (approach)	Training-free is a major portability advantage; Pi-compatible; implement per paper; strongest candidate for Pi sniffer localization enhancement
Kismet	Full-spectrum Wi-Fi / BT monitoring daemon; REST API; per-device data-rate; extensible via Python	GPL-2.0	Production — 20+ yr, active	❌ (SDR integration possible for some EMI)	MEDIUM	Best for Pi sniffer orchestration; too heavy for ESP32; copyleft; use as data-source daemon, not as embedded code
HeatDeCam (research)	Thermal camera + ML hidden-camera classifier; public dataset; >95% accuracy	Research; dataset public (CCS 2022)	Proof-of-concept	⚠ Powered/warm only — not fully off	MEDIUM	The public dataset is the practical fork asset; addresses non-Wi-Fi powered cameras; retrain classifier for FLIR hardware; adds a genuine non-RF modality to the sweep toolkit
LocCams (research)	CSI + packet timing for Wi-Fi camera detection + coarse localization; 95.12% accuracy	Research / not OSS yet	Conference paper (IMWUT 2023)	❌ Wi-Fi only	MEDIUM (approach)	CSI hardware requirement (Intel 5300/9560 or Nexmon) limits portability; the traffic-rate detection component is already in Vol 3 §5; implement on Pi if CSI adapter is available
SpyDir (research)	EMI AoA direction finding; protocol-agnostic; works on SD-only cameras; 19.86 cm position error	arXiv preprint / not OSS	Preprint (2026)	⚠ Powered only — not fully off	LOW (code) / HIGH (concept)	Only surveyed tool addressing powered SD-only cameras via EMI; no code; custom switching-antenna hardware; preprint-grade results; SDR experiment feasible with HackRF One
CamRadar (research)	Scene-modulated clock EMI detection; 93.23% accuracy; works on SD-only cameras	Research / no public code	Proof-of-concept (IMWUT 2022)	⚠ Powered only — not fully off	LOW (code fork)	No public code; reconstruct from paper; SDR experiment with HackRF One in receive mode; addresses non-transmitting powered cameras
EM Eye (research)	EMI video reconstruction from camera EM leakage; public artifact	Research / artifact repo (NDSS 2024)	Proof-of-concept	⚠ Powered only — not fully off	LOW (for detection)	High SDR barrier (USRP B210 for full fidelity); primary value is channel characterization; a binary detector built on the same physical channel is a narrower engineering goal
LAPD (research)	Smartphone ToF optical lens detection; 88.9% accuracy; power-state agnostic	Research / no public code	Proof-of-concept (SenSys 2021)	✅ Any power state — even fully off	LOW (code)	Samsung IMX516 hardware required; the physical approach (retroreflection) is already productized as SpyFinder Pro (~$100); LAPD validates the physics but is not directly forkable
airodump-ng / aircrack-ng	Classic monitor-mode 802.11 capture; station enumeration; RSSI; PCAP	GPL-2.0	Production	❌ Wi-Fi only	LOW (as fork base)	Binary tool; useful as a data-source or in scripts; not a library for embedded or Python integration; use scapy instead for code-level integration
nmap NSE camera scripts	On-network RTSP/ONVIF discovery; port scanning	NPSL / GPL	Production	❌ On-network only; no monitor mode	LOW (standalone)	Useful as one step in a layered on-network sweep; not a standalone camera detector; no monitor-mode capability
Hobby Marauder forks / ESP8266 scanners	Ad-hoc OUI filtering on ESP32/8266 hardware	MIT typically	Hobby / variable	❌ Wi-Fi only	LOW as base	Use Marauder itself as the base; extract component code (OUI tables, display widgets) if useful; do not build on an unmaintained fork

License summary across the surveyed landscape:

Table 11 — License summary across the surveyed landscape:

License	Projects in this survey	Fork constraints
MIT	ESP32 Marauder, most hobby builds	None — most permissive; fork, modify, ship proprietary; attribution required in copies
GPL-2.0	Kismet, scapy, airodump-ng	Copyleft (GPL-2.0 only, not “any later version”); distributed derivatives must publish source under GPL-2.0
NPSL (based on GPL-2.0, additional commercial terms)	nmap	Nmap Public Source License — adds commercial-use restrictions on top of a GPL-2.0 base; free for personal/open-source use; requires a commercial license for inclusion in proprietary products
GPL-3.0	Some ESP8266 hobby builds	Copyleft + stronger patent protections + anti-tivoization clauses vs. GPL-2.0
Proprietary	Nyan Box firmware	Not forkable as source; reconstruct approach from public data per §3.2
Research / no declared OSS license	LAPD, CamRadar, EM Eye, HeatDeCam, LocCams, CamLoPA, SpyDir	No open-source license confirmed; use code as reference only; do not redistribute without explicit permission from authors

10.7 Resources

10.7.1 Academic papers (web-verified citations)

Table 12 — Academic papers (web-verified citations)

System	Authors	Venue	Year	DOI / identifier
LAPD	Sami, Tan, Sun, Han	ACM SenSys	2021	DOI 10.1145/3485730.3485941
CamRadar	Liu, Lin, Wang, Shen, Ba, Lu, Xu, Ren	ACM IMWUT	2022	DOI 10.1145/3569505
EM Eye	Long, Jiang, Yan, Alam, Ji, Xu, Fu	NDSS	2024	NDSS 2024 proceedings
HeatDeCam	Yu, Li, Chang, Fong, Liu, Zhang	ACM CCS	2022	ACM CCS 2022 proceedings + public dataset
LocCams	WHU datasec lab	ACM IMWUT Vol 7 No 4	2023	DOI 10.1145/3631432
CamLoPA	Zhang et al.	IEEE S&P	2025	arXiv 2409.15169
SpyDir	—	arXiv (preprint)	2026	arXiv 2602.00411

10.7.2 Open-source repositories and tools

Table 13 — Open-source repositories and tools

Project	Repository	License
ESP32 Marauder	`github.com/justcallmekoko/ESP32Marauder`	MIT
Kismet	`github.com/kismetwireless/kismet`	GPL-2.0
scapy	`github.com/secdev/scapy`	GPL-2.0
aircrack-ng	`github.com/aircrack-ng/aircrack-ng`	GPL-2.0
avahi (mDNS/DNS-SD browser)	`github.com/avahi/avahi`	LGPL-2.1
wsdd (WS-Discovery daemon)	`github.com/christgau/wsdd`	MIT
IEEE OUI database	`https://standards-oui.ieee.org/oui/oui.txt`	Public data
Linux 802.11n CSI Tool	`github.com/dhalperi/linux-80211n-csitool`	GPL-2.0
nexmon CSI patch	`github.com/seemoo-lab/nexmon_csi`	GPL-2.0

10.7.3 Hub cross-references

Vol 3 §5 — traffic-rate / motion-correlation (the physics basis for LocCams, CamLoPA, and the traffic-rate accumulator in the Vol 7/8 builds)
Vol 4 §5.3 — LAPD full treatment (optical retroreflection via smartphone ToF)
Vol 4 §8.2 — CamRadar full treatment (scene-modulated EMI detection)
Vol 4 §8.3 — EM Eye full treatment (EMI video reconstruction)
Vol 4 §9.1 — HeatDeCam full treatment (thermal ML classification)
Vol 7 §5 — OUI fingerprint DB build pipeline (the IEEE OUI DB → embedded camera-vendor table)
Vol 8 §2 — ESP32 Marauder fork design (the four-layer camera stack built on Marauder)
Vol 8 §3 — Nyan Box fork design (reconstructing the multi-heuristic fingerprint approach)
Vol 8 §4 — Raspberry Pi monitor-mode sniffer design (the Pi-based traffic-rate + CamLoPA-class localization path)
Vol 9 — Commercial detector survey (the buyable complement to this open-source survey; what each commercial class actually catches)
Vol 14 — Comparisons and decision guide (buy-vs-build synthesis drawing on Vol 9 and this volume)
The ESP32 Marauder Firmware deep dive — full firmware architecture, build system, feature set, and the fork landscape (mainline vs. Ghost ESP vs. Bruce)
The Nyan Box deep dive — native camera detection feature, fingerprint DB details, triple-NRF24 hardware, and the firmware architecture to extend

CameraDetection Volume 10 — DIY & Open-Source: The Survey