Flock Camera Detection Arms Race: What Changed in 2026

If your Flock-You detector has gone quiet on a route that used to catch cameras every time, you are not imagining it, and your hardware probably is not broken. Flock Safety’s camera hardware and firmware have changed at least twice in the last year in ways that broke the community’s detection methods, and open-source researchers have had to reverse-engineer a new signature each time.

This is a fast-moving story. The detection method and OUI list below reflect the colonelpanichacks/flock-you main branch as of September 2026. Check the GitHub repository before assuming your device is defective.

The video above, from Valleytech Custom Solutions, documents exactly the symptom this article explains: a routine war drive that suddenly returns zero detections across multiple firmware builds, on a route where cameras were reliably detected before, in a county where several previously-flagged cameras had physically disappeared.

A War Drive That Suddenly Turned Up Nothing #

The pattern shows up the same way for almost everyone who reports it. A driver runs a route they have driven dozens of times. Their detector, running current firmware, has caught the same cameras before. Then, on one drive, it catches nothing. Not a single beep, not a single log entry, across every custom firmware build they try.

The Valleytech video above describes exactly this: a daily route to the post office that always registered at least one Flock camera stopped registering any, and a second route past Micro Center that used to flag five cameras now shows only one still active, with the other four physically uprooted from their poles.

Two things were happening on the same timeline, and it is easy to confuse them:

• Cameras are being physically removed or relocated in some areas, which genuinely reduces the number of devices there are to detect.
• The wireless signature the cameras broadcast has changed, which means even a camera still sitting on its pole will not trigger detection hardware running outdated firmware.

Two separate GitHub issues on the colonelpanichacks/flock-you repository, filed months apart, document the second problem in detail. Reading them in order tells the story of how the community’s detection method has had to evolve twice already.

Issue #20: The Management AP Went Dark #

Issue #20 , opened in January 2026, started with a familiar complaint: a user tested their device next to a known Flock camera, documented on DeFlock, and got nothing. Over the following weeks, more users piled on with the same result, from Florida to Indiana to Atlanta to the Midwest, using different hardware and different antennas.

One commenter asked the question that turns out to matter most: had Flock changed something on their end, in a way that broke detection for everyone at roughly the same time?

The project maintainer, colonelpanichacks, eventually confirmed exactly that. Around December 2025, Flock deactivated the management access point their cameras used to broadcast. That AP was the original basis for wireless detection. When it disappeared, the community pivoted to Bluetooth Low Energy (BLE) signals as a substitute. That substitute also stopped working reliably by spring 2026.

Every custom firmware built around the old AP or BLE detection paths is now looking for a signal the cameras stopped sending. That is why a device that used to work goes completely silent without anything being wrong with the hardware.

The Replacement Method: Wildcard Probes and Frame Fingerprinting #

The current flock-you firmware runs in dedicated 802.11 promiscuous mode. The radio never transmits and never joins a network. It only listens, hopping WiFi channels 11, 6, and 1 at a 250-millisecond dwell time to keep pace with how often the cameras themselves change channel.

A detection now requires all of the following to line up before the firmware alerts:

1. The frame is an 802.11 Management Probe Request (type 0, subtype 4).
2. The SSID Information Element is present with length 0, meaning it is a wildcard probe rather than one asking for a specific network.
3. The transmitter address (addr2) matches one of the known Flock OUI prefixes.
4. The rest of the frame’s Information Elements match the fingerprint pattern the DeFlockJoplin community documented, based on Pintor and Atzori’s 2022 research on WiFi probe request IE fingerprinting .

This method is named wifi_wildcard_probe_ie_sig in the firmware. Field testing by the DeFlockJoplin community caught 11 of 12 known cameras with only 2 false positives along their test route, the same field-verified baseline cited in the project’s own hardware guide . The 12th camera used an OUI that has since been added to the list below.

The Current OUI List #

The wildcard-probe fingerprint above only fires after the transmitter’s MAC address matches one of the OUI prefixes the community has confirmed against real Flock hardware. The list is maintained primarily by researcher @NitekryDPaul, with the 31st entry contributed by the DeFlockJoplin community after it caught a camera the original 30-entry list missed.

70:c9:4e  3c:91:80  d8:f3:bc  80:30:49  b8:35:32
14:5a:fc  74:4c:a1  08:3a:88  9c:2f:9d  c0:35:32
94:08:53  e4:aa:ea  f4:6a:dd  f8:a2:d6  24:b2:b9
00:f4:8d  d0:39:57  e8:d0:fc  e0:4f:43  b8:1e:a4
70:08:94  58:8e:81  ec:1b:bd  3c:71:bf  58:00:e3
90:35:ea  5c:93:a2  64:6e:69  48:27:ea  a4:cf:12
82:6b:f2

This list is not static. The upstream research notes several prefixes that were tested and then demoted (one turned out to be a Sony media player, another an early placeholder that never matched anything). Two entries are flagged as low-confidence and one, 82:6b:f2, is deliberately kept even though it is a locally-administered address, because filtering it out would have silently dropped a real, confirmed DeFlockJoplin detection.

One entry now has independent hardware confirmation from a camera in municipal service. The Flock unit whose filesystem images were published in September 2026 carried the MAC address f4:6a:dd:57:46:fb, and f4:6a:dd sits on this list at position 13. This unit was not a lab device or a purchased sample. It was mounted on a pole in Wauwatosa, Wisconsin, photographing traffic, which makes it the strongest single confirmation any prefix here has received.

If you maintain your own firmware fork, pull the OUI list from the upstream datasets/ folder rather than hardcoding a copy. The list changes as the research does, and a stale copy is a slow, silent way to start missing cameras again.

Ranking the Detection Signals #

OUI matching is the method the current firmware leans on, and it is the weakest of the five available signals. The detection community at WiFi Mothership ranks them by confidence, drawing on GainSec’s firmware research.

The bottom row is the one the current firmware depends on most, and this is the central problem with OUI-first detection.

Why the OUI List Is So Noisy #

The 31 prefixes in the list above are not 31 Flock identifiers. WiFi Mothership tracks a parallel set of 26 prefixes and classifies every one by its actual owner, which makes the composition visible.

Twenty-five of those 26 prefixes belong to component vendors, and those parts ship in enormous volumes of unrelated hardware. A Silicon Labs battery-pack prefix or a Liteon camera-module prefix appears in products with no connection to Flock Safety, and Raspberry Pi boards are everywhere.

A match on any of them is a hint, not an identification. This is why the wildcard-probe signature carries so much weight in the current firmware. Pairing an OUI match with an empty-SSID probe request raises confidence from a guess to 62 on the project’s own scale.

Only B4:1E:52 answers the question “is this a Flock device” by itself. Treat the other 30 prefixes as supporting evidence.

How Many Cameras Expose a Hotspot at All #

Wardriving data gives a floor for the population. WiFi Mothership counted 900 or more Flock access points on WiGLE during 2025, where a Flock AP means a device broadcasting a default Flock-XXXX hotspot SSID.

This figure describes devices exposing a provisioning hotspot, not the installed base. Flock claims tens of thousands of deployments, and most of those cameras never broadcast anything a passing wardriver records. The map is a sample, and a small one.

Issue #43: New SSID Pattern, 5GHz, and MAC Anti-Fingerprinting #

Three months after Issue #20 closed, a second report arrived that describes what looks like a deliberate anti-detection countermeasure rather than an incidental firmware change. Issue #43 , filed in May 2026, is built on WiGLE wardriving data captured against a camera already confirmed on DeFlock, and it documents three findings none of the existing tooling accounted for.

Finding 1: A Different SSID Format #

The documented Flock hotspot SSID has always followed the pattern Flock-XXXXXX. The camera in this report broadcast Flock Camera net. instead, a completely different naming convention. Anyone searching WiGLE for the Flock-* wildcard, as several researchers had been doing, would get zero results for this camera even though it was actively broadcasting.

Finding 2: A Confirmed 5GHz Hotspot #

The same camera broadcast simultaneously on 2.4GHz channel 1 and 5GHz channel 157, using sequential MAC addresses on each band (...9f:a2:de and ...9f:a2:df), which points to a single dual-band WiFi module assigning adjacent addresses to each radio rather than two unrelated devices. A separate, independent report from researcher nsm_barii had already logged a Flock probe request on 5GHz channel 149, so this is now two data points confirming 5GHz operation is real and not a one-off misconfiguration.

Every detection method described earlier in this article, including the current wildcard-probe firmware, only listens on 2.4GHz. A camera broadcasting exclusively (or primarily) on 5GHz is invisible to that hardware regardless of OUI list accuracy.

Finding 3: Locally Administered MAC Addresses on the Hotspot #

Both captured MAC addresses have the locally administered bit set, meaning they were not assigned from Flock’s real IEEE-registered OUI block. The standard flock-you detection logic deliberately skips locally administered addresses, because that is the standard way to filter out MAC-randomizing phones and laptops.

That filter, which exists specifically to reduce false positives, means a Flock camera using a locally administered MAC on its hotspot interface gets filtered out by the exact same logic meant to clean up noise. The sequential last bytes on the two captured addresses rule out random generation, which is what makes this look like intentional, structured address assignment rather than coincidence.

SSID-based matching is the one method in this table that keeps working regardless of which band the camera uses or how its MAC address is assigned. That is the practical argument for adding broader SSID pattern support rather than relying on OUI matching alone.

Is Flock Deliberately Evading Detection? #

Neither GitHub issue proves intent, and it is worth being precise about that. Issue #43’s own author raised it as an open question rather than a conclusion: is this consistent across Flock’s deployments, or specific to one firmware version on one camera?

But look at the pattern across both issues together. A detection surface goes dark. The community finds a replacement. The replacement’s blind spots (2.4GHz-only scanning, OUI-based matching, filtering out locally administered MACs) line up closely with exactly the properties a new SSID format, a 5GHz radio, and a locally administered MAC address would exploit. That could be coincidence produced by an unrelated firmware upgrade cycle, or it could be a vendor tightening its own wireless footprint in ways that happen to break third-party detection as a side effect, intentional or not.

The most useful stance is not to argue which one it is. It is to build detection that does not depend on any single assumption holding forever, because on this project’s own two-year track record, none of them have.

Visual Confirmation: Powered On, Broadcasting Nothing #

A third Valleytech Custom Solutions short closes the loop on the “maybe the camera was removed” explanation.

The creator returned to the same camera from the first video, at night, and visually confirmed its IR LEDs were still firing, meaning the unit was powered on and actively illuminating for night capture. At the same time, every custom firmware they tested logged zero legitimate hits against that camera. One alert did fire, but it was a confirmed false positive rather than a real detection. Nothing from the camera was reaching the wireless side at all.

This separates the two competing explanations cleanly. A camera that has been uprooted or relocated cannot explain a unit that is visibly powered on and illuminating at night. A camera that is live, illuminating, and still silent on every WiFi detection method is evidence the wireless signature itself has gone dark, not that the hardware disappeared.

The creator also reported, after talking with other developers working on the same problem, that this was not an isolated result. Multiple people observed the same pattern at roughly the same time, which points toward a coordinated, nationwide change on Flock’s side rather than a local fluke at one camera. That claim is anecdotal, based on informal conversation rather than a published dataset, but it lines up with the same December 2025 and spring 2026 windows described in Issue #20, and it is the kind of report that belongs in a new GitHub issue rather than staying as a comment thread.

What This Means for Your Detection Hardware #

If your device has gone quiet, work through this checklist before assuming it is broken:

1. Update your firmware first. If you are running anything older than the current main branch, you are likely still looking for the deactivated management AP or dead BLE beacons. Pull the latest firmware and reflash.
2. Confirm the camera is still there. Some of the “zero detections” reports turned out to be genuinely uprooted or relocated hardware, not a detection failure. Cross-reference against Flock Finder or DeFlock before troubleshooting your device.
3. Slow down at intersections. The 250ms channel-hop dwell means a fast pass carries you past a camera’s detection window before your radio lands on the right channel. A 30-60 second stop catches far more cameras than a fast drive-by with a bigger antenna.
4. Report what you see. A confirmed zero-detection result next to a visually verified camera is exactly the kind of data point that turned into Issues #20 and #43. Open a new issue rather than assuming someone else already reported it.
5. Know the current limits. WiFi-only, 2.4GHz-only firmware will not see a camera that has moved to 5GHz or gone quiet on the bands it scans. That is a real gap right now, not a bug in your specific build.

None of this makes the hardware pointless. The OUI list and wildcard-probe fingerprint still catch the overwhelming majority of deployed cameras today. It means treating any detector, DIY or purchased, as a snapshot of the current arms race rather than a permanent solution.

Shop Now — Save up to 20% Today Code: SIMEONONSECURITY

A Parallel Approach: Detecting the Infrared Flash Instead of the WiFi Signal #

Wireless detection is not the only front in this arms race. A separate follow-up video from the same creator, Valleytech Custom Solutions, describes an entirely different approach: instead of listening for a radio signature, watch for the camera’s infrared illuminator.

Most ALPR cameras, Flock’s included, use infrared illumination to capture readable plates at night, the same reason ordinary security cameras work in the dark. That IR light is invisible to the human eye but visible to an image sensor that has not had its infrared-cut filter installed. That single hardware detail, a missing IR-cut filter, is what turns an ordinary camera module into a Flock detector.

What the Prototype Looks Like #

The approach documented in the video went through several iterations before landing on a workable combination:

• First attempt: dedicated IR photodiode receivers. Technically workable, but the parts were too expensive to be a practical DIY option.
• Second attempt: a Jetson Nano paired with a Raspberry Pi camera module. This proved the concept worked, but the hardware cost and power draw made it impractical for a handheld or vehicle-mounted build.
• Current build: an ESP32-based camera module without an IR-cut lens. The creator tested an ESP32-CAM and an M5Stack S3 Cam before settling on the Seeed Studio XIAO ESP32S3 Sense, paired with a Seeed XIAO GNSS module built on the Quectel L76K chip for GPS-tagging detections, the same GPS-wardriving pattern the WiFi-based flock-you dashboard already uses.

The Camera’s Blink Pattern #

The premise depends on the illuminator flashing in a detectable, repeating pattern rather than staying continuously lit. The creator reported a self-measured timing of roughly 20 milliseconds on and 80 milliseconds off, a 100-millisecond period, which works out to a 20% duty cycle at 10Hz, and was explicit that this figure is unverified and could be wrong. Treat that specific number as a starting point for your own measurement, not a confirmed spec, since Flock has never published it and the creator did not claim certainty either.

Where the Project Stands #

This is an early, DIY-only prototype, not a finished product. The creator described the software as “vibe coded” and still in progress, with a buzzer for audible alerts planned but not yet added, and no packaged board equivalent to the OUI-SPY hardware. The current version still requires a human to visually confirm that a flagged detection is an actual camera rather than another IR-emitting light source, so it works as a screening tool rather than a fully automated one.

This is a genuinely different detection surface than everything else in this article. It does not depend on WiFi, 2.4GHz or 5GHz, OUI matching, or MAC address behavior at all, which means none of the evasion techniques described in Issue #43 apply to it. That also means it inherits its own limitations: line of sight, daylight interference, and a duty cycle assumption that has not been independently confirmed.

What the Community Is Doing About It #

The response to both issues followed the same pattern that has kept this project useful for two years: someone reports a gap, someone else contributes the fix, and the fix ships as an update rather than sitting in a backlog.

• Issue #20 ended with a confirmed root cause and a firmware rewrite around the wildcard-probe signature, credited to the DeFlockJoplin community’s field research.
• Issue #43 remains open as of this writing, with the SSID pattern-matching suggestion still pending implementation. If you want to help close that gap, the fix (adding Flock Camera as an additional match pattern) is a small, well-scoped contribution for anyone comfortable with the firmware’s match logic.
• The underlying OUI dataset is versioned and dated in the repository, with demoted and low-confidence entries documented rather than silently dropped, so anyone forking the project sees exactly what changed and why.

This is the practical case for open-source detection tooling over a closed-source alternative. A proprietary detector cannot be patched by the person who found the gap. This one already has been, twice.

The Other Response: Taking the Hardware #

Wireless detection is one reaction to these cameras. A parallel effort went after the hardware itself, and in September 2026 it produced the most detailed public evidence about how a Flock camera works from the inside.

The stegan0gram collective removed a camera from its pole, copied the internal storage, and published the filesystem images through Distributed Denial of Secrets. They describe the work in plain terms:

“Why just destroy them when we can reverse engineer them and find the secrets of those spying on us? We liberated hardware in the field, disarmed them, and proceeded with reverse engineering of the cameras and associated solar equipment.”

The distinction matters. Destroying a camera removes one unit. Reverse engineering produces evidence about all of them.

What the Removal Produced #

The published dataset includes an 18 GB media partition, a 1.5 GB Android system image, and a 32 MB credentials partition, along with the recovered key for the encrypted media container. From it, researchers established the operating system version, the kernel version, the hardcoded backend credentials, and the plain-text authentication tokens the camera stores.

This evidence base now supports the security research covered in Flock Safety Camera Vulnerabilities: 50+ Flaws Found , which previously rested on lab devices and purchased units.

The Response to Removal #

Physical interference carries consequences, and the picture is mixed.

• Multiple people have been arrested nationwide for allegedly tampering with or sabotaging Flock cameras.
• Some towns have announced they will stop using Flock cameras, which is the outcome the cameras’ opponents want.
• One police department built a fake, 3D-printed Flock camera case to bait potential vandals, a decoy intended to generate arrests.

Noel Pichardo, a former Pawtucket, Rhode Island police officer who became a critic of Flock after challenging his department’s use of the cameras, makes the argument against sabotage directly. He told WIRED he understands the frustration but worries the tactic backfires. “I think that type of vigilantism will only crystallize the police and the state at large in their belief that this tool is necessary,” he said. “The longer the state continues to ignore the groanings of their constituents who are against this type of surveillance, the more this will happen.”

Where Detection Fits #

Nothing about the teardown changes the detection problem this article covers. The camera still broadcasts the way it broadcasts, the firmware still needs its OUI list and probe signature, and the two documented outages still stand.

What the dump adds is confirmation of the hardware identity, including one OUI entry now verified against a real unit, plus a reminder about which kind of pressure moves deployments. Cameras leave a route because a council vote ends a contract, not because a detector went dark. The wireless tooling answers a personal question about your own surroundings. The policy fight answers the larger one, and the dump handed the policy fight its strongest evidence yet.

Conclusion: Detection Is a Moving Target, Not a Fixed Answer #

A silent detector on a route that used to catch cameras is not proof your hardware failed. It is evidence that the wireless signature it was built to recognize has changed, again, in a pattern that has now repeated twice inside a single year. The management AP, BLE beaconing, and now potentially the 2.4GHz-only, OUI-only assumptions baked into the current firmware have each had a limited shelf life.

The fix has never been to give up on wireless detection. It has been to keep the detection method’s assumptions visible, documented, and open to correction the next time a report like Issue #20 or Issue #43 comes in. That is the argument for open-source firmware over any closed alternative: the fix ships as soon as the community finds the gap, not on the vendor’s schedule.

Key Takeaways #

• Two documented detection surfaces have already gone dark: the management WiFi AP (deactivated around December 2025) and BLE beaconing (unreliable by spring 2026).
• The current method, wildcard probe requests plus OUI and IE fingerprint matching, has a field-verified 11-of-12 detection rate, but it is WiFi-only and 2.4GHz-only.
• A pending report describes a new SSID format, a confirmed 5GHz hotspot, and locally-administered MAC addresses that the current OUI-based, 2.4GHz-only method cannot see.
• A separate, non-wireless approach is emerging: an ESP32 camera module with its IR-cut filter removed spots a Flock camera’s infrared illuminator, a detection surface that ignores WiFi entirely and is immune to every evasion technique above.
• Visual confirmation backs the wireless silence up: a camera visibly powered on and illuminating at night still logged zero legitimate WiFi hits, which rules out “the camera was removed” as the explanation for that specific unit.
• A zero-detection result on a known camera does not automatically mean your hardware is broken. Update your firmware first, then confirm the camera is physically still there.
• This is an open-source project that keeps shipping fixes as the community finds gaps. Read the GitHub issues, not only the README, to know the current state of detection.

Next Steps #

1. Update your firmware to the current main branch before troubleshooting anything else: github.com/colonelpanichacks/flock-you
2. Read the full hardware guide if you have not already: Flock-You Detection Project: Counter-Surveillance Hardware Guide
3. Cross-reference suspected dead zones against Flock Finder before assuming your device missed something
4. Understand what you are up against: Flock Safety Camera Surveillance: Prevalence, Privacy Concerns, and Protection Strategies
5. Pair WiFi detection with cellular detection using Rayhunter for a fuller counter-surveillance picture, since none of this article’s methods detect cell-site simulators

Related Articles #

References #

1. Flock-You GitHub Repository - colonelpanichacks
2. GitHub Issue #20 - Flock cameras not detected, but other devices detected
3. GitHub Issue #43 - 5GHz signal? New OUI / MAC address filtering
4. NitekryDPaul OUI Research Dataset
5. nitekry/nite-oui-collection
6. DeFlock Joplin - Community ALPR Research
7. Pintor, L. & Atzori, L. (2022) - Analysis of Wi-Fi Probe Requests Towards Information Element Fingerprinting, IEEE GLOBECOM
8. WIRED and 404 Media - Hackers Got Inside a Flock Camera
9. Micah Lee - Flock cameras are riddled with security vulnerabilities and hard-coded credentials
10. Distributed Denial of Secrets - Flock ALPR Camera Filesystem Images
11. Hackaday - This Week In Security: Flock Cameras Are Old
12. WiFi Mothership - Flock Safety ALPR Detection and Device Reference
13. GainSec - Firmware Research and Security Advisories
14. The Hunt for the Hidden Probe - Hidden SSID Wildcard Probe Behavior
15. DeFlock - Crowdsourced ALPR Camera Map
16. Colonel Panic Tech - OUI-SPY and Detection Hardware
17. STS Collective - FlockYou Devices
18. Something Strange Is Happening With Flock Cameras - Valleytech Custom Solutions
19. Infrared Wardriving Flock Cameras - Valleytech Custom Solutions
20. Flock Cameras Still On But No Broadcast - Valleytech Custom Solutions
21. Automatic Number-Plate Recognition - Wikipedia (infrared illumination in ANPR/ALPR systems)
22. Seeed Studio XIAO ESP32S3 Sense
23. L76K GNSS Module for Seeed Studio XIAO