Detection expansion: research and coding handoff for items 1–8¶

Reviewed 2026-09-23, against commit 37c33927a074d22a2a41e53b3ce6d11647a695c3. This is the implementation handoff for roadmap items 1–8. The research itself added no enabled rules or hardware validation. The live baseline remains 67 rules / 19 categories. This independent vendor/standards review does not retroactively verify the historical signature catalogue.

Implementation status (2026-09-23)¶

Items 1–2 and the shared SSID frame-role prerequisite are implemented. Coverage has five help pages reachable from every Scent Book page; Back preserves the page, and help does not affect discoveries, scanning or display idle policy. OUI inference requires a globally administered individual transmitter address. SSID rules require beacon/probe-response frames; payload identifiers and BLE matching remain independent. All 15 host suites and the ESP32 release build pass; host tests use address, undefined-behavior and leak checks. The 67 rules / 19 categories and persistent state formats are unchanged. Installed on the Hosyond on 2026-09-24; the application hash and saved-data preservation were verified, with a successful boot/radio smoke check. Physical UI/SD checks and controlled RF testing remain pending.

The baseline findings below describe the reviewed commit; the implemented sections note the current behavior. Candidate rules in items 3–8 remain research work.

Readiness and recommended order¶

“Documented” means a source describes the field; it does not mean Hound has received it from hardware. No new candidate in this report has a controlled RF capture. Firmware versions are unknown unless explicitly stated. Scores below are proposed Hound policy, not measured accuracy or vendor claims.

Suggested small patches: A: item 1; B: item 2 plus the SSID frame-role guard below; C: item 3 confidence audit; D: item 4 disabled candidates/tests. Prepare item 5 after category design, then items 6–8 as opt-in informational work. Documentation research is complete for this pass; unresolved evidence is an explicit follow-up, not permission to ship guesses.

Constraints discovered at the reviewed commit¶

Shared prerequisite: match an advertised SSID to its sender¶

Implemented in matches(): require Radio::Wifi and subtype 8 (beacon) or 5 (probe response) for Kind::SsidExact and Kind::SsidPrefix. Preserve subtype 4 parsing for future passive request/response correlation. A directed probe request names a network being sought, not a product hosted by the phone. This guard is for SSID product evidence; it must not disable unrelated protocol/behavior detection.

Tests: the same synthetic SSID in a beacon and probe response matches; in a probe request it does not. Exercise both exact and prefix kinds through parse_wifi() and the engine, not only fabricated Observation fields. Update existing direct-observation fixtures to state their subtype. Test leading junk, case changes, embedded NUL, empty SSID, 32-byte boundary, duplicate SSID IEs and truncated frames. Prefix matching intentionally accepts arbitrary suffixes; it is not validation of serial-number syntax and remains spoofable.

1. Explain coverage in the UI¶

The original ESP32 supports 2.4 GHz 802.11b/g/n and Bluetooth including BLE. Hound's implementation uses passive BLE advertisements and selected Wi-Fi management frames; Classic Bluetooth inquiry and arbitrary radio interception are not current features. Hardware capability must not be confused with implemented reception. Espressif datasheet v5.3

Implemented a Coverage entry reachable from the Scent Book, with a short multi-page explanation and Back control. Keep it separate from the 19 discovery categories: viewing help must not create a discovery or alter persistence. Research copy below; the shipped wording is split across five pages to fit both orientations:

• What Hound hears: “Hound listens for recognizable 2.4 GHz Wi-Fi and Bluetooth LE broadcasts. Nearby devices can be missed between scan windows.”
• What a clue means: “A name or manufacturer clue does not prove a camera is recording, who owns it, or that someone is tracking you.”
• What stays unseen: “Silent listeners, wired-only devices and cellular-only equipment may give Hound nothing to hear. It cannot receive 5/6 GHz Wi-Fi or other radio systems.”
• Quiet does not mean clear: “No matching signals observed. This is not a complete device inventory or a safety guarantee.”

Detailed help should name silent PAX-style counters, cellular-only trackers/ALPR, cellular interception equipment, acoustic-only sensors, and optical/IR/radar/RFID/LoRa systems as outside these detectors unless they separately emit a supported identifiable broadcast. Radio frequency overlap alone is insufficient. Travel Watch reports repeated nearby presence; it still has no location/motion proof.

Touch points: UI implementation (components/ui/ui.cpp), UI types/layout (components/ui/include/ui.hpp), field guide (components/ui/include/scent_guide.hpp), simulator navigation only if useful, and the coverage sections in DETECTIONS.md. Check “ALL QUIET. GOOD COMPANY.” and empty-log text in context; keep pet personality, but make the coverage limitation accessible without an alarm.

Acceptance: landscape and portrait; all themes; Back restores the correct page; controls fit; help never interrupts scanning or resets idle timers without user interaction; no new persistent field, connection or category required.

2. Stop manufacturer inference from locally administered Wi-Fi addresses¶

IEEE defines the U/L bit as bit 1 of the first displayed MAC octet. A set bit denotes local administration, not necessarily randomization. The I/G bit is a separate bit 0. A protocol OUI or CID within an information element is not a transmitter address. IEEE EUI/OUI/CID guidelines

Implemented predicate for Kind::Oui: Wi-Fi, (o.address[0] & 0x03) == 0, then existing prefix comparison. This rejects both local administration and group transmitter addresses, with all four bit combinations tested. Do not clear either bit to manufacture a vendor match. Retain the cap defense, but it should no longer be the only protection.

Apply this only to transmitter-MAC manufacturer inference. Local addresses may still carry a valid SSID or protocol signature. Leave BLE address-type handling, BLE company IDs, service UUIDs, payload OUIs/CIDs, Pwnagotchi decoding and behavior rules intact.

Acceptance fixtures:

1. A synthetic globally administered prefix matches its OUI rule; an independently matching locally administered prefix does not. Testing only an address whose bytes no longer match the rule would miss the bug.
2. A local Wi-Fi address with a matching advertised SSID still matches that name rule.
3. The same local address with valid vendor-payload evidence still matches that payload rule, including an identifier whose own first byte has bit 1 set.
4. Existing BLE public/random address fixtures and supported tag ignores remain unchanged.
5. Local OUI alone produces no detection, alert, meal or discovery. Name/protocol evidence retains its own confidence without an OUI bonus.

Primary files: components/sniffer_core/engine.cpp, tests/host/core_tests.cpp; review live local-prefix entries and their provenance rather than silently repurposing them. No change to the radio callbacks or saved-state format is needed.

3. Camera-vendor clues and the existing confidence audit¶

The official IEEE MA-L CSV, MA-L text, MA-M and MA-S endpoints returned HTTP 418 on 2026-09-23. No new allocation is independently verified in this report. Do not substitute an unsourced MAC-lookup page or infer a camera brand from a module supplier.

Before adding an OUI: save registry name, exact allocation and bit length, retrieval date and snapshot hash; record whether it identifies the product vendor, an OEM, a hub or a module supplier. Verify a known unit's radio transmitter during the relevant operating state. An Ethernet-label MAC or app device ID is not automatically the Wi-Fi address. MA-M/MA-S require a real masked-prefix matcher; truncation would attribute other allocations to the vendor.

Existing issue to address: the seven wifi.camera.* OUI entries (00408C, B8A44F, E0A700, 701AD5, C056E3, 4419B6, 2CAA8E) and the fourteen wifi.ring.* OUI entries currently use score 60 / Medium / non-generic. This is an audit inventory, not registry validation. Proposed vendor-only policy: score 30, cap Low, generic=true, labels that identify a vendor clue rather than a proven camera/doorbell. This changes alert behavior and must be reviewed explicitly, including matching provenance fields. Do not quietly preserve Medium just because it shipped previously.

At threshold 50 these proposed OUI clues are quiet; at threshold 20 the user has requested weak alerts. For very broad vendors spanning unrelated products, defer the rule or route it to informational context rather than CAMERA. Two weak vendor/name clues must not be promoted into a product assertion. Regression tests should verify the desired combined score/cap, repeated sightings and manufacturer overlap.

Blink's setup candidate can use CAMERA only with a clear camera-system/hub limitation in the field guide and visible rule label. Suggested initial score 45 / Low until model captures support a more specific interpretation. Hidden SSIDs, a camera already connected to a router, Wi-Fi disabled, and 5 GHz-only traffic are expected coverage gaps. Ordinary data-frame capture remains roadmap item 18, outside this session.

4. Dashcam SSIDs¶

Use a CAMERA rule with a visible model/family label such as “Possible BlackVue dashcam network”; explain “network name match; recording unknown.” Proposed score 60 / Medium for a validated product-specific name. Do not add a separate persisted dashcam category just for these first rules.

XXXX, xx and asterisks above reproduce placeholder notation, not literal matcher bytes or proven suffix alphabets. Prefix rules alone cannot enforce lengths. Do not add case-insensitive matching or a broad brand substring as a shortcut. Modern models/bands are not covered merely because an older manual has a similar brand name.

BlackVue permits automatic Wi-Fi timeout; Thinkware's cited connection page explicitly says recording is paused while connected. These differences make “dashcam nearby” distinct from “recording you.” BlackVue settings, Thinkware connection guide

Acceptance: positive beacon/probe-response fixtures; a searching phone as negative; router SSID MyBlackVue590XPlus-... must not match; lower-case spelling must not match unless separately documented; harmless AP spoofing the exact name must retain only the name-based confidence. Capture hotspot on/off, renamed SSID, connected/disconnected phone, parking/recording modes, and 2.4/5 GHz separately. Repeats must retain existing cooldown/Ignore/Snooze behavior.

5. O.MG and other Hak5 gear¶

The O.MG creator's quick start directly documents SSID O.MG after flashing, and configurable Wi-Fi settings. Candidate tool.omg.setup: wifi_ssid_exact, value O.MG, proposed 60 / Medium; label “O.MG-style setup network.” This applies to the documented setup/AP state, not every cable/firmware/mode. O.MG-123, O.MG_Cable and My O.MG must not match an exact rule without separate evidence. An ordinary AP can imitate the name. Creator quick start

Key Croc's documented WIFI_SSID is the network it connects to, not proof of a default AP called “Key Croc.” The official configuration page was available through its search index but direct fetch failed. No default Key Croc broadcast signature was established. Other Hak5 devices remain model-by-model research; neither a USB function nor an Ethernet interface establishes an identifying Wi-Fi broadcast. Hak5 configuration

Category dependency: do not put O.MG in PINEAPPLE merely to reuse an animation. Recommended separate follow-up: append a neutral RADIO_TOOL category, with an original dog snack, alert toggle and honest name-only field guide. This is a design recommendation, not an implemented feature. Its coding change must migrate category-sized saved arrays, preserve existing numeric IDs/ignores, and update compiler/schema, export names, UI pagination and simulator lists. If that work is outside the small-change session, keep the O.MG candidate disabled.

Audit existing Pineapple_ separately against an exact model/revision; this research does not newly validate the existing management-name rule or justify expanding it to all Hak5 gear. No association, network access, attack execution or probing is required for a name detector.

6. Fleet and retail infrastructure¶

Choose neutral informational presentation before adding these clues. Proposed score/cap 19 and no pop-ups, sound, screen wake, Travel Watch escalation, meals, XP or discovery-based outfit unlocks. Do not map any of them to AXON, ALPR or another security-device category. A new bounded “Radio clues” view/category needs its own resource and persistence plan; until then defer these rules.

A silent receiver has no required detectable advertisement. Dense venues are mandatory negative controls. A single router with several BSSIDs is not a count of police vehicles or retail tracking systems. Keep raw addresses out of saved research/export evidence; preserve the existing keyed-identity policy.

7. Low-cost camera setup networks¶

No model-specific primary-source/capture pair was established for the proposed HDWiFiCam, V380, Yoosee, LookCam, IPC-, HIPC or A9 strings. App names, packaging names and actual broadcast SSIDs are different fields. Searches surfaced reseller/manual aggregators, but those are not adopted as verified manufacturer signatures here. Do not fill these gaps with guessed prefixes.

If generic setup context is implemented later, share one informational candidate between items 7 and 8. The compiler prohibits duplicate evidence-kind/value pairs; do not classify the same ESP_ name once as camera and once as skimmer. Require a specific additional product signature for a camera label. Signal strength, repetition or being in a rental property is not that signature.

Capture checklist: actual model/FCC label if present, firmware, factory setup, AP mode, normal client mode, Ethernet mode where available, Wi-Fi disabled, and several non-camera smart plugs/bulbs/relays using the same IoT platform. A negative sweep must never say the room is camera-free.

8. Generic module clues for skimmer investigations¶

The HC-08 manufacturer manual specifies software V3.1, hardware V2.0, dated 2017-07-07; its command table and name section document default HC-08 and configurable names. It describes BLE and a default service FFE0. Candidate module.hc08: ble_name_exact / HC-08, informational 19, only after proving that the name is in an advertisement Hound receives passively. Manufacturer manual, printed pp.4–6

The manufacturer-authored HM Bluetooth module manual V545 (2017-01), mirrored by Cornell, documents default HMSoft, not the hardware model string HM-10, in its name command section (PDF p.29 / printed p.41). Candidate module.hmsoft: ble_name_exact / HMSoft, informational 19, with the same capture prerequisite. A mirrored manual is evidence for that revision, not every clone or current firmware. Datasheet

The new informational path must show “Generic radio module — purpose unknown,” remain quiet even at threshold 20, and avoid discovery/game rewards. A module might be a sensor, toy or legitimate serial adapter. Hound has no ATM/pump/location context and must not manufacture an intent score from RSSI. Review the existing SKIMMER field-guide/labels and advertised coverage before extending this category. Do not enable Classic inquiry, active BLE scanning or GATT access as part of this roadmap block.

Coding checklist and release gates¶

Evidence record for each candidate¶

Keep research candidates in documentation until approved for a disabled experimental rule. Do not drop a draft JSON file into data/signatures/: the compiler loads every *.yaml there. For a promoted rule, update catalogue (data/signatures/catalog.yaml) and provenance (data/provenance.yaml) together, using the compiler's exact schema. experimental=true must have enabled_by_default=false; “disabled” is not a substitute for the source record.

Record these fields before enablement:

Public fixtures must remain synthetic or carefully minimized/anonymized, consistent with fixture policy. A synthesized O.MG beacon demonstrates parser behavior, not that a particular cable emits it. Do not upload surrounding devices' addresses, network names, credentials or private captures as part of this work.

Implementation and test map¶

For engine/catalogue changes, run the existing host checks described in host test guide and BUILDING.md. Commands are:

cmake -S . -B build-host -G Ninja -DSNIFFER_HOST=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build-host
ctest --test-dir build-host --output-on-failure

Keep sanitizers enabled as configured by the project. Compiler/provenance checks must pass and generated output must be deterministic. Include regression coverage for these user-visible behaviors:

• Monitor/detector toggles, alert thresholds 20/50/80, Snooze, sound mute and per-device Ignore; queued alerts cannot bypass a newly added Ignore.
• Samsung continuity and AirTag/Find My identity handling; a new camera/vendor clue must not change tag deduplication or Travel Watch eligibility.
• Repeat sightings do not increase confidence, repeatedly feed the dog or inflate physical-device claims. Informational-only additions do not create outfit discoveries through Companion::observe().
• Screen dim/saver/off policy remains unchanged; quiet clues do not keep the screen awake. Demo observations remain isolated from saved stats/ignores.
• Stronger product evidence can supersede a vendor clue for the same existing identity without double-counting, while separate same-brand devices remain separate.

Before enabling a new hardware rule, test on the Hosyond with SD logging: record free heap, minimum heap, largest free block, radio queue drops, SD writes/backlog and UI responsiveness through BLE/Wi-Fi windows. Compare against a same-build baseline with that rule disabled, not an invented universal heap target. Do not resize caches/queues or add allocations merely to hold candidate names. A synthetic test pass is necessary but does not close the RF-validation gate.

Open evidence work, in priority order¶

1. Capture a documented BlackVue or Thinkware model in 2.4 GHz AP mode and a phone probing for its remembered SSID. Record firmware and negatives; these are the clearest first dashcam candidates.
2. Reacquire the 70mai manuals from a working official endpoint, then capture exact named models. Obtain exact Viofo/Garmin/Nextbase model patterns before adding those families.
3. Verify O.MG from an identified cable/firmware in setup mode, once its category is designed. No Key Croc default AP claim until primary evidence exists.
4. Obtain a current IEEE allocation snapshot for all item 3 vendors; separately capture Blink setup and at least one non-camera hub. Audit the existing seven camera and fourteen Ring prefixes against that snapshot.
5. Capture HC-08 and HMSoft in genuinely passive mode with no nearby active scanner, then with a separate scanner to distinguish scan-response-only names. Include benign UART devices and connected/sleeping states.
6. Identify exact low-cost camera models and neutral fleet/retail examples. Avoid enabling the broad rejected patterns while waiting for evidence.

The research did not change the enabled 67-rule pack. The items 1–2 application was subsequently installed on the Hosyond on 2026-09-24 after SD eject confirmation; see the hardware receipt. Controlled RF acceptance remains separate from the successful boot smoke check.

Sources and access notes¶

All sources were reviewed on 2026-09-23. Live support pages without an explicit revision should be treated as mutable; pin a revision or record a snapshot hash in the rule evidence when promoting a candidate. Search-index-only/manual-access failures are called out in the relevant row rather than presented as a successful full-document read. The IEEE allocation failures are a verification blocker, not evidence that a vendor has no allocation. The original author of the HM manual is the primary source; Cornell hosts a copy. No third-party detector implementation was used for this report.