← AK-mee™ · Case study · Internal R&D · Field-tested
Project Flipper
RF tinkering, fleet-style — Flipper Zero on the bridge, four hosts scanning in parallel, one API that cares.
I picked this up because, you know, it had a little dolphin on it. Then I plugged it in and it turns out the thing answers a lot of the questions we get on customer site visits — what's that 433 MHz remote, is there a rogue BLE device, are these badges cloneable, can we map the WiFi from where we're standing. So we wired it into the fleet and started using it.
Why a Flipper
AK-mee does a fair amount of physical-security and field work, and a surprising number of customer questions are radio questions. Is this gate opener trivially clonable. Are the badges in this office still legacy 125 kHz. What's actually transmitting in this warehouse on a slow afternoon. You can answer those with a software-defined radio rig, a laptop, and an afternoon of GNU Radio — or you can put a Flipper Zero in your backpack pocket and have an answer in five minutes. We bought the Flipper for the five-minute answer.
The build
The Flipper attaches to box over USB CDC ACM. It exposes a text CLI on /dev/ttyACM0 — send a carriage return, get a >: prompt; type device_info, get a parseable response. The CDC ACM driver hangs on close when the Flipper is in a sleep state, which means a naive serial.Serial(...) from Python takes the whole process down on exit. We moved the read out of Python: the health check shells out to bash, runs the whole pipeline inside a new process group, and SIGKILLs the group if it exceeds a watchdog. From plug-in to confirmed identity (firmware commit, hardware UID, BLE MAC) takes under ten seconds.
The fleet side is the multiplier. Four members carry WiFi radios — box (Realtek), dart (Cortex-A53), jetson (AGX Orin), and octo (a Pi 4). Each has passwordless sudo for iw dev <iface> scan and an SSH key in box's authorized list. The orchestrator on box fans out parallel SSH calls, parses the iw output, and merges per-BSSID across hosts so each network appears once with an array of vantage readings. The Flipper sits on the bridge as the sub-GHz, BLE, and NFC end of the same instrument.
Six endpoints on box:8080: POST /api/scan triggers a parallel WiFi scan, GET /api/status returns the result set plus the known-device registry, GET /api/alerts is an SSE stream of new-BSSID events, and /api/ble/{status,scan} exposes the Flipper's BLE radio in the same shape. New-device events get reposted to the fleet broadcast channel — same overlay that carries fleet status carries the alert.
What we actually use it for
We treat the Flipper as a portable yes/no instrument. Four lanes get most of the use:
WiFi site survey
Flipper plus the official WiFi devboard, walked around the customer site as a quick AP enumeration pass — SSIDs, BSSIDs, channels, signal strength at known points. Pairs naturally with the four-host fleet scan: handheld coverage from the survey, fixed-point gradient from the rack. Output ends up in the customer report as a coverage map plus a list of unexpected SSIDs.
Sub-GHz audit — doorbells, gate openers, remotes
Most consumer 433 MHz / 315 MHz wireless — doorbells, retrofit garage openers, cheap retrofit alarm sensors — uses fixed codes or weak rolling codes. We use the Flipper to capture and analyse for a paying customer scoped audit, then hand back a one-page note: replay-vulnerable yes/no, recommended replacement. We do not transmit on RF without a written authorisation referencing the site and frequency. Read for analysis, transmit only inside scope.
BLE proximity sweep
A five-minute BLE sit at a customer venue produces a baseline of broadcasting peripherals — phones, watches, earbuds, point-of-sale beacons, the building's own BLE asset tags. The interesting hits are unnamed devices with rotating MACs that shouldn't be there, and named devices with manufacturer strings that shouldn't be there. Same flow finds lost-and-found hardware on a fleet site: the Flipper points you, you walk toward stronger signal.
NFC / RFID badge audit
With the customer's written go-ahead and a volunteer cardholder, we read employee badges to validate the physical-security posture. 125 kHz EM4100 reads trivially and is the failure mode we still find most often; modern HID iCLASS and DESFire don't dump like that, which is the news the customer wants. The deliverable is a yes/no per badge type, plus a remediation note when legacy stock is still in circulation.
System architecture
Field workflow
On a customer engagement, the Flipper itself is the smaller half of the workflow. The larger half is the chain that turns a five-minute capture into a one-page note the customer can act on.
Lessons
- Pick the smallest tool that proves the point. The Flipper is a $169 Tamagotchi with a radio. It is not the right tool for a long capture, a wide spectrum sweep, or a serious site survey. It is the perfect tool for a yes/no question — does this 433 MHz remote use rolling codes, can my badge be cloned, is there a stray BLE peripheral in the supply closet. Five-minute answer, not a multi-day rig.
- Pin the device path, not the device number. /dev/ttyACM0 is whatever ACM device enumerated first this boot. The stable handle is /dev/serial/by-id/usb-Flipper_Devices_Inc._Flipper_*-if00. We log the hardware UID, BLE MAC, and firmware commit at intake — so when a second RF device joins the bridge, nothing on the software side guesses which one it's talking to.
- RF capture is a legal artefact, not just a binary. Every sub-GHz or NFC capture lands in the customer engagement folder with a timestamp, a device target, and a written authorisation reference. If we don't have written go-ahead for a specific frequency at a specific site, we don't transmit. Reading is one thing; replaying is the line you don't cross.
- BLE is noisier than you think and quieter than you hope. A typical room has two dozen BLE peripherals broadcasting — earbuds, watches, fridges, the building's HVAC. Most of it is named useful things. The interesting ones are the unnamed devices with rotating MACs, and the named devices that shouldn't be there. The Flipper's BLE scan plus a five-minute sit produces a usable baseline.
- The fleet is the multiplier, not the Flipper. One Flipper on a desk is a curiosity. One Flipper plus four owned hosts running iw scans on demand is a sensor network. The Flipper is the sub-GHz / BLE / NFC end of the same instrument. We wired it into the same SSE channel that already carries fleet messages — no new transport, no new dashboard, the alert just shows up.
What's next
The instrument layer is stable. Next up is the geolocation reduction — turning per-host RSSI vectors into a useful constraint over a known floor plan, fed by the same /api/status we already trust. On the Flipper side, the 433 MHz capture path is still under-used; long-form sub-GHz logging on a fleet customer site is the natural next experiment, scope and authorisation permitting.
— Donny