← AK-mee™ · Case study · Internal R&D · Field-tested

Project Flipper icon — four fleet sensors triangulating an RF target

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.

Flipper ZeroSub-GHz · 433/868/915 MHzBLENFC / RFIDWiFi devboardPython · pyserialiw / wireless-tools

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

Project Flipper system architecture The Flipper Zero attaches to box via USB CDC ACM. Box runs a parallel WiFi scan orchestrator, fanning out SSH calls to dart, jetson, and octo. Per-host RSSI is aggregated through a single REST + SSE API, and new-device alerts ride the fleet broadcast channel. Flipper Zero USB CDC ACM · 0483:5740 Sub-GHz · BLE · NFC · IR Unleashed firmware UID + BLE MAC logged Bridge node — box Linux x86 · 192.168.88.12 wifi-scan/server.py :8080 parallel SSH fan-out RSSI aggregator + registry SSE /api/alerts box_health_check.py pyserial · flipperzero-protobuf wlp2s0 (Realtek) · rfkill unblock USB · CLI dart ARM Cortex-A53 · wlan0 iw dev wlan0 scan jetson AGX Orin · wlP1p1s0 iw dev wlP1p1s0 scan octo Raspberry Pi 4 · wlan0 iw dev wlan0 scan SSH · iw scan · parallel REST + SSE API · :8080 POST /api/scan GET /api/status GET /api/alerts (SSE) GET /api/alerts/history GET /api/ble/status POST /api/ble/scan {bssid, ssid, [hosts]→rssi} known-device registry · diff aggregate · merge per BSSID Fleet broadcast POST /api/message SSE /api/message-stream all displays · in-frame overlay same transport as fleet status new-device → broadcast AK-mee™ · Project Flipper · fleet-as-positioning-network

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.

Project Flipper field workflow From customer site authorisation, to Flipper capture, to AK-mee analysis on the fleet, to a written customer report — five steps, left to right. 1. Authorisation written scope site · frequencies badge holders read vs transmit 2. Field capture Flipper Zero SD card · USB timestamped sub-GHz · BLE · NFC 3. Bench analysis URH · GQRX Wireshark BLE box · jetson classify · annotate 4. Cross-check fleet WiFi scan known-device list corroborate or flag /api/status 5. Customer note one page findings · risk · fix signed PDF chad@akmee.net cc AK-mee™ · field workflow · authorisation → capture → analysis → note

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

Operations Watch · AK-mee™ · 2026-05-03

← Back to AK-mee™