OUI-SPY is a palm sized radio sniffer that flashes from a browser tab

The board does not transmit, and that is the whole design

The README is unusually clear about what the current firmware does and does not do. All current firmware is passive and detection-only, nothing transmitted, nothing exploited, just listening, and this is described as the Blue Edition, the defensive and reconnaissance one. A Red Edition with offensive capabilities is stated to be in development and to be released separately. That framing matters more than it might seem, because a radio device that scans can usually also transmit, and the ability to do so is what separates a detector from a jammer or an injector. The hardware is an ESP32-S3 based multi-mode detection system with an integrated buzzer and power management, and the board is described as ready to use with no additional components required, sold through the author's site. The flashing flow assumes a XIAO ESP32-S3, so the board and the firmware are designed as one thing rather than as a general purpose radio module.

Flashing happens from a browser tab, with no toolchain at all

The installation story is the unusual part, and it is the reason the board is approachable. The README says no Python, no PlatformIO, no drivers to install, and gives a web address for the flasher. You plug in the XIAO ESP32-S3 with a USB-C data cable, click Connect and Flash, pick the serial port, and the flasher always ships the latest Unified Blue firmware. The browser support is named too, Chrome, Edge or Opera on desktop. That last detail is worth understanding, because the mechanism relies on the Web Serial API, which is a Chromium family feature, so the browser requirement is not a preference but a constraint of the approach. The benefit is that the first flash of a new board, which is normally the step that sends beginners back to a tutorial, is a single page and one button.

Seven modes behind a boot menu, and no reflashing to switch

The unified firmware is the recommended option, and the point of it is that you flash once and then change mode from the device itself. It combines Detector, Foxhunter, Flock-You, PCAP, BLE Sniff, Sky Spy and AXEOFF into a single firmware with a WiFi-based boot selector, and the documentation says no reflashing is needed to switch modes. The selector runs its own access point, named oui-spy or ouispy123, at 192.168.4.1, and from there you pick a mode, reboot, and go. Holding the BOOT button for two seconds returns you to the selector from any mode, the choice persists across power cycles, and each mode plays a distinct retro boot sound so you know which firmware you are in by ear alone. There is a global buzzer toggle in the selector menu and the access point SSID and password are configurable from the web interface. The unified build also adds features the standalone firmwares do not have, including GPS wardriving in Flock-You mode, session persistence to flash, KML export for Google Earth, and a prior session history tab.

Detection is by signature, and the signature list is specific

The Detector mode is the core of the idea, and it works by matching a set of precise patterns against what it hears. The readme lists six signature classes: an OUI prefix, a full MAC, a Bluetooth SIG company ID, a 16-bit service UUID, a name substring, and composite filters. The composite example given is a Meta and Ray-Ban preset that fires only on a co-located Luxottica company ID together with a Meta UUID, or on a name match, and the documentation notes that this is RPA safe, which matters because randomized private addresses would otherwise defeat a naive filter. On top of the raw signatures there is a built-in OUI database of known surveillance hardware, with one click vendor signatures from the web UI for RING, AXON, FLOCK SAFETY, DJI, PARROT, SKYDIO and META or RAY-BAN. The web configuration portal runs on its own access point, snoopuntothem or astheysnoopuntous, also at 192.168.4.1, and there is an optional NeoPixel LED on the same firmware, breathing pink while scanning and flashing a sequence on a detection, on GPIO4.

The device history and the MQTT bridge are what make it usable daily

Two features turn the board from a toy into something you leave running. The first is persistent device history, up to 100 devices stored in NVS, with custom aliasing so you can label what you are seeing rather than reading a raw MAC. The second is the MQTT and Home Assistant integration with auto-discovery, so a detection publishes a blip straight to your dashboard without you polling anything. There is also a burn-in mode that locks the configuration and boots straight into scanning, which is the setting you want for a fixed deployment such as a device sitting in a room, and MAC randomization on every boot for privacy. The persistence is a natural extension of the same idea, since a detector that forgets what it saw an hour ago is only half a detector. The readme describes the use cases for this mode as targeted device detection, surveillance hardware auditing, security sweeps and asset awareness.

The other modes answer different questions with different radios

The rest of the modes each narrow the problem. Foxhunter is a precision proximity tracker for radio direction finding, tracking a single target MAC with real-time RSSI analysis and variable proximity beeping that speeds up as the target gets closer, and it is described as optimized for directional antenna use and triangulation, which makes sense for finding a lost asset or a device on a property. Flock-You is a Flock Cam detector built on a passive 2.4 GHz promiscuous receiver with no AP and no transmit, and it uses a tiered confidence model where an information element fingerprint, a wildcard probe signature and OUI matches are separate tiers, each with its own distinct audio so you know by ear which method fired. It hops channels downward, 11, 6 then 1, with a 250 millisecond dwell, to catch the target's ascending probe cycle quickly, and it persists sessions to on-device SPIFFS with CRC validation so you can review a previous sweep later. It also has a Flask companion dashboard in an api directory with a live GPS-tagged feed and JSON, CSV and KML export.

AXEOFF is the mode with no interface at all

Mode 7 is the most stripped-down of the set and the most interesting design. AXEOFF is described as a headless Axon detector with no WiFi, no portal and no config, just beeps, and it detects Axon body cams, Tasers and Fleet units. The design goal is stated as zero interface by design: power it on, hear four ascending beeps, and it is already scanning, with no access point, no web server and nothing to configure. It matches seven signatures across both radios, the Bluetooth SIG company ID 0x034D, service UUIDs 0xFC81, 0xFE6B and 0xFE6C, and the IEEE OUI 00:25:DF, on BLE and on WiFi probe or beacon traffic. The four sounds are the entire user experience, a boot jingle, an 8-bit detection arpeggio, a heartbeat that accelerates as the target closes in, and a descending pair when the target is gone. It stays passive throughout, a passive BLE scan that never sends a SCAN_REQ, plus promiscuous listen-only WiFi, and it randomizes its MAC on every boot.

Where OUI-SPY is the wrong choice

The first wrong case is any task that needs the device to talk. The current firmware is passive, and the documentation says a Red Edition with offensive capabilities is still in development, so a project that needs to probe, jam or inject is looking at something that does not exist yet. The second is a project that needs a rigorous, publishable detection method, because what the board offers is a curated list of vendor signatures, OUI prefixes and company identifiers, which is a set of heuristics that a defender uses, not a measurement that a researcher can cite. The third is a fixed site with no interest in a portable device, since the audio feedback and the boot sound cues are tuned for someone carrying it around. The fourth is a jurisdiction where operating any radio scanner has legal weight, since the repository points to a legal note for its wider tool set, and local radio regulations are the right thing to check before carrying a scanner anywhere. The fifth is a user who wants the detection logic in their own software, because the signatures and the decision rules live in the firmware repositories, and the board is a complete product rather than a library you can call.

Editorial conclusion

People who want to know what kind of radio hardware is around them, in a form that fits in a pocket and needs no laptop to configure, are the people OUI-SPY is for, and the browser flasher is what makes the board usable by someone who does not already have an embedded toolchain. It is the wrong tool if you need to transmit or to test your own devices, since the current firmware is passive and detection-only, and it is the wrong tool for a project that needs a documented, reproducible detection methodology rather than a set of heuristics. Check three things before you buy or build one: that the USB-C port on your board is wired for data, since the flashing flow depends on it, that the mode you actually want is in the unified Blue build rather than a standalone firmware, and that the detection signatures match the hardware you are hunting for, since the vendor lists, the OUI prefixes and the company IDs in the documentation are specific values rather than a general capability. The documentation also carries a note that a Red Edition with offensive capabilities is in development, so the current firmware should be read as the defensive half of a planned set.

Frequently asked questions

Official sources

1. colonelpanichacks/oui-spy on GitHub
2. Issues
3. README