Releases: ReconGrunt/FlipDeFlock
Release list
Nightly (7723578)
Untested build from main. This is not a release.
Built from 7723578. Use it to test a fix before it is tagged,
or as a fallback when the newest tag has a problem. For normal use
take the latest release instead.
Install is identical to a tagged build: take the .fap matching
your firmware from the table in the README.
The companion firmware is not rebuilt here. Flash the
.bin from the newest tagged release. If the app and the
companion ever disagree on the protocol, the app says so on the
scan screen rather than misreporting.
Since v0.76
- Update README to include AXON cameras in description
- Net Guardian: triage an attack, log it, and say what to do
v0.76
Full Changelog: v0.75...v0.76
v0.75
If you are on v0.74, update — and reflash the companion
v0.74 shipped a filter that could never open. On that build the OUI + probe
request path — the one that finds most fielded cameras — was dead.
Flash flipdeflock_companion_esp32wroom.bin from this release as well as the
.fap. The fix is companion-side; updating only the app changes nothing.
What went wrong
v0.74 required 3 probe requests from one transmitter inside 2000 ms before a Flock
OUI plus probe behaviour could score Likely. That was not strict, it was
impossible:
- the companion watches any one channel for 300 ms out of every 3900 ms
- a camera probing every ~125 ms can place at most 2 probes in one window
- consecutive windows are 3900 ms apart, so they never overlap
Nothing could satisfy it. The threshold came from reasoning about camera cadence
without checking it against the radio's own duty cycle.
The gate is removed rather than retuned. Behaviour returns to what upstream runs
and field tested at 11 of 12 cameras with 2 false positives.
The T-Mobile false positive stays fixed. Its cause was never cadence — it was
48:27:ea (Samsung Electronics) and a4:cf:12 (Espressif) sitting in the
built-in OUI table. Those remain demoted to the seed file.
The per-transmitter probe counter survives as an observation on the wire
(pr=<n>), never a confidence input, so a future threshold can come from
measurement instead of reasoning.
The bench rig had never worked
Finding this meant fixing tools/flock_emitter, which had three separate faults —
none visible to CI, because it compiles perfectly either way:
en_sys_seq = falsemade the IDF refuse every beacon injection. No Wi-Fi
frame reached the air at all.- Probe identities held 3 s and fired a single scan, so they were usually off the
air whenever the detector was listening. esp_wifi_set_mac()was called on a started interface and with the address
already assigned to the AP, which the ESP32 rejects asESP_ERR_WIFI_MAC. The
return code was never read, so probe identities transmitted from the factory
Espressif MAC while the log announced a Flock OUI.
The tell from that last one is worth remembering: beacons detect, probes never
do. A beacon's source address is a field in a hand-built frame and was always
correct; only the interface-level spoof was broken. The rig now reads the return
code and warns loudly if it fails again.
Verified against a radio
| Identity | Expected | Observed |
|---|---|---|
Flock-A1B2C3 |
CONFIRMED | CONFIRMED |
test_flck |
CONFIRMED | CONFIRMED |
Flock-Guest |
Likely, never CONFIRMED | Likely |
| Flock OUI + wildcard probe | Likely | Likely, Method: OUI + probe req |
The last row is the point of this release: dead under v0.74, and never once
checked on the air before now. Flock-Guest is the v0.46 over-claim, also
confirmed against a transmitter rather than argued from a unit test.
Verify your download
sha256sum --ignore-missing -c SHA256SUMS.txtFull Changelog: v0.74...v0.75
v0.74
Warning
Superseded by v0.75 — use that instead.
The sustained-probe-rate gate described below could never open. The companion
watches one channel for 300 ms out of every 3900 ms, so the 3-probes-in-2000 ms
threshold was unsatisfiable by anything, including a real camera. On this build
the OUI + probe request detection path is dead — the path that finds most
fielded cameras.
v0.75 removes the gate and keeps the OUI demotion, which is what actually fixed
the reported T-Mobile false positive. Reflash the companion too, not just
the .fap.
Update the companion firmware too, not just the .fap
Both fixes below live partly on the ESP32. Flash
flipdeflock_companion_esp32wroom.bin from this release alongside your .fap, or
the false positive stays exactly as it was.
The app deliberately trusts the companion for every confidence rung below
Confirmed, because those depend on probe behaviour it cannot re-derive on its
own. A board on older firmware keeps reporting a prefix the app has already
dropped.
A T-Mobile hotspot was being reported as a Likely ALPR camera
Reported from the field. Two causes.
The built-in OUI list is mostly chip vendors, not Flock. Checked
prefix-by-prefix against the IEEE registry, 21 entries belong to Liteon and
only b4:1e:52 to Flock Safety itself. Two were worse: 48:27:ea is registered
to Samsung Electronics and a4:cf:12 to Espressif, and upstream rates
both "low confidence, WiGLE crowdsource" — its weakest tier. Both are demoted to
docs/signatures.seed.json, where you can opt back in. They are not retracted:
nothing says they are wrong, only that nobody corroborated them.
The ladder was the deeper cause. Flock OUI + wildcard probe request scored
Likely, and a wildcard probe is the single most ordinary frame a Wi-Fi client
emits — it is what scanning for a network looks like. So a Samsung-based hotspot
doing nothing unusual was flagged as a likely surveillance camera.
The companion now requires a sustained probe rate first. A fielded Flock
camera runs in station mode and probes roughly every 125 ms; a phone emits a
short burst and goes quiet for tens of seconds. Same frame type, very different
cadence — and cadence is what separates them.
Net Guardian can guard one network
Press Right on the Guardian screen and pick an access point. Only deauths
aimed at that BSSID and evil twins of that SSID feed the score; the bottom line
names the network instead of the OK=sus hint, and the choice persists across
restarts.
Untargeted, the Guardian answers "is anything around me under attack?" — which
in a flat or an office is mostly somebody else's traffic, and an alert you learn
to ignore. Flock detections, BLE trackers, a nearby Flipper and attack-tool
signatures still contribute whatever is targeted: those are about you, not the
network.
If no networks are listed yet, a Scan for networks row runs one and the list
fills in place.
RogueMaster gets its own artifact
RogueMaster names the app deflock.fap, so installing there meant renaming the
Unleashed file by hand. It now builds as a fourth target and ships under that
name. Contributed by @h00die in #21.
What was verified on hardware, and what was not
Run on a Flipper Zero (Momentum mntm-dev, API 87.1) with the ESP32 companion
attached and reflashed to this build.
Confirmed on a real device: Net Guardian targeting end to end, including the
in-place scan and persistence; the Axon device class rendering with its AX tag
and body/in-car kit label; and the v0.70 Detail-round-trip fix, verified on
hardware for the first time — a tagged tracker survived Back while the device
table grew 25 → 28 rather than resetting.
Not confirmed: the probe-rate gate's thresholds. No Flock hardware was present
to exercise a true positive. The gate is known to stop the reported false
positive and is not known to pass a real camera. Those thresholds remain
unmeasured, and the code comments say so.
A selection bug was also caught by that hardware run and fixed before release: the
network picker rebuilt its list as scan results arrived, which reset the cursor, so
the highlighted row and the selected row could diverge — it guarded the wrong
network silently. The cursor is now carried across the rebuild.
Verify your download
sha256sum --ignore-missing -c SHA256SUMS.txtFull Changelog: v0.73...v0.74
Contributors
Assets 10
v0.73
v0.72
Update if you are on v0.67–v0.71
Those builds report an unrelated consumer device as a "Likely" ALPR camera.
This release removes the cause.
What happened
The Wi-Fi OUI prefix f8:a2:d6 was withdrawn upstream — "low confidence; hit on a
Sony Media Player" — and FlipDeFlock dropped it in v0.44. A later commit
(93beede) reflowed the two OUI tables and silently put it back. It shipped in
v0.67, v0.68, v0.69, v0.70 and v0.71.
It was not inert while it was there. A device scores Likely on a Flock OUI plus
a wildcard probe request, and every Wi-Fi client sends wildcard probes while looking
for networks — so anything on that prefix was flagged as a likely surveillance camera
for behaving completely normally. A false positive is worse than a missed detection,
and that is doubly true for a tool people use to decide whether they are being watched.
Why nothing caught it
The CI parity gate compared the Flipper's OUI table against the ESP32 companion's and
nothing else. That commit changed both files identically, so the gate passed at
32-vs-32 for five releases while both files' own comments still said 31. Content
parity cannot see a mistake made the same way in both copies.
The gate now also fails on:
- a count comment that disagrees with its own array, and
- any upstream-retracted prefix reappearing —
f8:a2:d6,6c:cd:d6,94:2a:6f,
f4:e2:c6,cc:cc:cc,00:0c:e7— each stored with its retraction reason so it
cannot be "rediscovered" from the older flat OUI list.
The host tests assert the same denylist through the matcher and pin the table size.
Both guards were verified against the failing case: the regression was re-seeded in a
throwaway copy and each guard was confirmed to fail on its own, including with the
count comments edited to hide the first one.
Also fixed
docs/signatures.example.json shipped "ssid_confirmed": ["flock-"], and the docs
tell you to copy that template and edit it. User SSID patterns match as unanchored
substrings, so that value marks Flock-Guest, Flock-Freight-WiFi and similar
benign networks CONFIRMED — the exact over-claim the built-in Flock- rule was
anchored to prevent in v0.47, reached through a supported path instead. Both example
values are inert placeholders now, and docs/signatures.md explains that
ssid_confirmed is the one key where a user file can manufacture a false CONFIRMED.
Changed, with no effect on scoring
docs/signatures.md gains a provenance table for the built-in OUI list. It describes
itself as prefixes observed in fielded deployments, which is true of most but not
all of it: four are contract-manufacturer prefixes (Liteon/USI) that also ship
unrelated consumer hardware, four are inherited from a superseded flat list with no
status in the curated source, and three are rated weak upstream. An OUI-only match
still caps at Possible regardless — this only stops the table's claim reading as
stronger than the evidence behind it.
Signature sources were re-checked against upstream: no new Flock or SoundThinking
prefixes exist that this app lacks. BLE tells are unchanged and current — XUNTONG
company id 0x09C8, Raven GATT 0x3100–0x3500, Penguin- / FS Ext naming.
Verification
Host tests (4,177 checks), the OUI parity gate, ufbt, and both Arduino sketches all
build green, and the fix was confirmed present in the shipped binaries themselves.
Not validated on hardware. As with everything since v0.20, this is verified by
tests and compilers, not against a radio. Nothing here should be read as field-proven.
What's Changed
Full Changelog: v0.71...v0.72
Contributors
Assets 9
v0.71
Nightly builds, so a fix can be tested before it is frozen into a tag.
No app behaviour changes in this release. It is release plumbing and docs, and the
.fap behaves exactly as v0.70 did.
Added
A nightly channel. main is now built and published daily to a rolling
nightly prerelease whenever something has changed,
carrying the same three .fap files under the same names as a tagged build.
This exists because v0.69 shipped a fix that did not hold. Between it and the
correction in v0.70, the only published build was the broken one, and "wait for the
next tag" was the only advice available. A nightly also runs the other way, letting
whoever reported a bug confirm the fix before it is tagged.
| Channel | Where | What it is |
|---|---|---|
| Stable | latest release | A tagged, released build. This is the one to use. |
| Nightly | nightly |
A rolling build of main. Untested. |
Nightlies are marked as prereleases, so /releases/latest still resolves to the
newest tag and nothing about the normal install path changes. The companion firmware
is not rebuilt for a nightly, so pair it with the .bin from the newest tag; the
proto handshake reports a genuine mismatch on the scan screen rather than
misbehaving quietly. A day when main has not moved is skipped, so a nightly's
publish date always means something changed.
Fixed
Superseded CI runs are cancelled instead of queued. A second push to a branch
left the first ESP32 run sitting behind its own replacement, and one on #18 sat
there for 25 hours on a result nobody was waiting for. Tag builds are exempt:
a cancelled tag run is a release missing its companion firmware with nothing red to
show for it.
Changed
CONTRIBUTING.mdandSECURITY.mdmoved into.github/, where GitHub surfaces
them in the PR and advisory flows. Every link to them was updated.- The asset pack download link and filename were corrected.
- @nickk02 is credited in
CONTRIBUTORS.md for the v0.70 release-engineering work.
Take the .fap matching your firmware — see the table in the
README. Verify your download against SHA256SUMS.txt:
sha256sum --ignore-missing -c SHA256SUMS.txtv0.70
What's Changed
- Ship a .fap per firmware, not just for OFW by @nickk02 in #8
- Read the API version from the right CSV column by @nickk02 in #10
- Wait for both companion images before hashing by @nickk02 in #11
- Bound label formatting so it builds on newer SDKs by @nickk02 in #9
New Contributors
Full Changelog: v0.69...v0.70