Hackers physically obtained a Flock Safety camera and extracted its software and stored data, according to information shared with WIRED and 404 Media, providing a detailed look at how the widely deployed surveillance cameras collect and process information.
The hackers were able to copy the camera’s storage and recover an encryption key stored on the device, allowing them to unlock videos and other data.
Analysis of approximately 21 days of recovered logs found that a single camera photographed roughly 50,200 vehicles and generated about 1.6 million images. A typical passing vehicle generated approximately 28 images, while some produced more than 100.
John Strand, Owner, Black Hills Information Security:
“A lot of companies ignore physical device security when they’re building their threat models. There’s that old saying that anytime you think no one will go through the trouble, some kid in Finland is already going through the trouble. Today, it’s more like this. Anytime you think no one is going to go through the trouble of pulling down your Flock camera and reverse engineering the hardware, there’s some hacker in a hoodie who absolutely will. Anyone building or deploying physical devices should look at stories like this and ask a basic question. How do we actually secure the physical device itself?”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Stealing one Flock Safety camera can expose a substantial amount of what that unit stored locally. The recovery team made a near-complete copy of the drive, pulled an encryption key stored on the device, and unlocked thousands of roadside clips and still bursts, though WIRED reported much of the most sensitive storage stayed encrypted. WIRED and 404 Media’s analysis logged about three weeks of activity on one pole, roughly 50,200 vehicles and 1.6 million images, with on-device software that also flags people in frame.
“I would put that in front of any council vote on automatic license plate readers (ALPRs). Residents hear about the cloud database, but the pole still hoards detailed imagery locally, and the security model starts to look like locking a digital video recorder (DVR) while leaving the key inside the enclosure. Anyone who can lift the box gets offline access to which vehicles passed, when, and scene-level detail the camera already captured, bumper stickers, a flag patch on a saddlebag, riders flagged as people, with no Flock login and no law-enforcement audit trail on the read.
“Flock bolts these units to public poles and roadway arms, often around 8 to 12 feet high per the company’s install docs, where technicians ,or attackers, can easily reach them with a ladder. Theft and vandalism are already happening in the open, so the physical threat runs far higher than for rack-mounted gear in a locked facility.
“When the decryption key is stored on that same publicly reachable box and every successful pull becomes a bulk export of neighbor travel history, that is a massive privacy issue.”
Damon Small, Board of Directors, Xcape Inc.:
“Physical hardware exposure in widespread edge deployments creates severe operational, legal, and reputational risks for surveillance networks that rely on poorly secured endpoint storage. As Ben Franklin famously observed, those who give up liberty for security deserve neither. Massive government surveillance programs represent an intolerable overreach, and the hackers who expose these physical hardware vulnerabilities perform a necessary service by forcing accountability onto opaque monitoring systems. Security executives must recognize that physical obscurity is a false defense, requiring hardware-backed roots of trust, unique per-device secrets, and mandatory data minimization to constrain the blast radius of compromised hardware.
“Critical Takeaways
- Edge deployments fail when encryption keys and sensitive logs reside unencrypted in local memory.
- Massive surveillance apparatuses carry severe liability when physical tampering uncovers systemic data collection practices.
- Defenders must enforce hardware key isolation, distinct device credentials, and immediate data ephemeralization across all remote nodes.
“Exposing mass surveillance through hardware reverse engineering proves once again that security by obscurity fails every time it meets a screwdriver.”
Larry Pesce, VP of Services, Finite State:
“The Flock camera teardown isn’t a surveillance story. It’s a firmware story we’ve all seen before.
“Hackers physically recovered a deployed Flock Safety ALPR camera, imaged its storage, and recovered an on-device encryption key that unlocked its stored video and logs (reporting by WIRED and 404 Media). Micah Lee then dug into the published filesystem images (https://micahflee.com/flock-cameras-are-riddled-with-security-vulnerabilities-and-hard-coded-credentials/), and that’s where it gets interesting for anyone who builds, buys, or assesses connected devices.
“What the teardown showed, per Lee’s analysis:
- The camera runs a modified Android 8.1, an OS released in 2017 that Google stopped supporting in 2021, with a security patch level of June 2018
- The Linux kernel is 3.18.71, a 2017 release from a kernel series that itself went end-of-life in 2019, and the device wasn’t even at the final release of that dead series
- A hard-coded API key ships in a shared library bundled into 19 separate on-device apps, and that key appears to let a caller request credentials for a camera by MAC address
- Device credentials sit in plaintext on an unencrypted partition designed to survive factory reset, and the key protecting the media partition is stored on the same partition it protects
“An important caveat before anyone piles on: this is one camera. We don’t know how old this unit is, when it was installed, or whether its software was current relative to the rest of Flock’s fleet. That matters, and it cuts in an uncomfortable direction. The build on the device was compiled in June 2025. If that’s accurate, this wasn’t a forgotten unit that drifted out of date. It was recent software built on top of an ancient base, which points at a platform decision rather than a patching lapse.
“And that’s the part that generalizes, because almost nothing here is unique to Flock. This is the default state of the IoT industry:
“The kernel you ship is the kernel your SoC vendor gave you. Chip vendors hand device makers a board support package pinned to a specific kernel and Android version, and moving off it is expensive enough that most products never do. The OS is effectively frozen at the moment the hardware was designed, then sold and supported for a decade.
“Physical access isn’t in the threat model, even when the device lives on a pole. Keys stored next to the data they protect, plaintext credentials in persistent storage, no meaningful hardware root of trust. We see this constantly in firmware analysis and hardware assessments. If an attacker can touch the device, and for roadside infrastructure they obviously can, everything on that flash should be assumed recoverable.
“Shared secrets turn one device into the whole fleet. A hard-coded key baked into every unit means the compromise of a single camera in Wisconsin is potentially a credential-provisioning problem for every camera everywhere. That’s the finding I’d lose sleep over, not the CVE list. Individual kernel vulns matter less than the architectural reality that one extracted device can reach production infrastructure.
“None of this gets fixed by a bug bounty intake form. It gets fixed by knowing what’s actually in your firmware before it ships, threat modeling for physical possession, provisioning per-device credentials, and committing to a software lifecycle that outlives the BSP the chip vendor handed you. Regulators are starting to demand exactly this (the EU CRA’s update and support obligations come to mind), but the companies that get ahead of it will do so because it’s sound engineering, not because a checklist told them to.
“If your product runs on hardware, someone will eventually have your hardware. Design like it.”
Seeing as Flock has such a negative reaction, maybe it is time to rethink things? Just a thought.
Related
This entry was posted on September 18, 2026 at 4:55 pm and is filed under Commentary with tags Flock. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Hackers crack Flock camera
Hackers physically obtained a Flock Safety camera and extracted its software and stored data, according to information shared with WIRED and 404 Media, providing a detailed look at how the widely deployed surveillance cameras collect and process information.
The hackers were able to copy the camera’s storage and recover an encryption key stored on the device, allowing them to unlock videos and other data.
Analysis of approximately 21 days of recovered logs found that a single camera photographed roughly 50,200 vehicles and generated about 1.6 million images. A typical passing vehicle generated approximately 28 images, while some produced more than 100.
John Strand, Owner, Black Hills Information Security:
“A lot of companies ignore physical device security when they’re building their threat models. There’s that old saying that anytime you think no one will go through the trouble, some kid in Finland is already going through the trouble. Today, it’s more like this. Anytime you think no one is going to go through the trouble of pulling down your Flock camera and reverse engineering the hardware, there’s some hacker in a hoodie who absolutely will. Anyone building or deploying physical devices should look at stories like this and ask a basic question. How do we actually secure the physical device itself?”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Stealing one Flock Safety camera can expose a substantial amount of what that unit stored locally. The recovery team made a near-complete copy of the drive, pulled an encryption key stored on the device, and unlocked thousands of roadside clips and still bursts, though WIRED reported much of the most sensitive storage stayed encrypted. WIRED and 404 Media’s analysis logged about three weeks of activity on one pole, roughly 50,200 vehicles and 1.6 million images, with on-device software that also flags people in frame.
“I would put that in front of any council vote on automatic license plate readers (ALPRs). Residents hear about the cloud database, but the pole still hoards detailed imagery locally, and the security model starts to look like locking a digital video recorder (DVR) while leaving the key inside the enclosure. Anyone who can lift the box gets offline access to which vehicles passed, when, and scene-level detail the camera already captured, bumper stickers, a flag patch on a saddlebag, riders flagged as people, with no Flock login and no law-enforcement audit trail on the read.
“Flock bolts these units to public poles and roadway arms, often around 8 to 12 feet high per the company’s install docs, where technicians ,or attackers, can easily reach them with a ladder. Theft and vandalism are already happening in the open, so the physical threat runs far higher than for rack-mounted gear in a locked facility.
“When the decryption key is stored on that same publicly reachable box and every successful pull becomes a bulk export of neighbor travel history, that is a massive privacy issue.”
Damon Small, Board of Directors, Xcape Inc.:
“Physical hardware exposure in widespread edge deployments creates severe operational, legal, and reputational risks for surveillance networks that rely on poorly secured endpoint storage. As Ben Franklin famously observed, those who give up liberty for security deserve neither. Massive government surveillance programs represent an intolerable overreach, and the hackers who expose these physical hardware vulnerabilities perform a necessary service by forcing accountability onto opaque monitoring systems. Security executives must recognize that physical obscurity is a false defense, requiring hardware-backed roots of trust, unique per-device secrets, and mandatory data minimization to constrain the blast radius of compromised hardware.
“Critical Takeaways
“Exposing mass surveillance through hardware reverse engineering proves once again that security by obscurity fails every time it meets a screwdriver.”
Larry Pesce, VP of Services, Finite State:
“The Flock camera teardown isn’t a surveillance story. It’s a firmware story we’ve all seen before.
“Hackers physically recovered a deployed Flock Safety ALPR camera, imaged its storage, and recovered an on-device encryption key that unlocked its stored video and logs (reporting by WIRED and 404 Media). Micah Lee then dug into the published filesystem images (https://micahflee.com/flock-cameras-are-riddled-with-security-vulnerabilities-and-hard-coded-credentials/), and that’s where it gets interesting for anyone who builds, buys, or assesses connected devices.
“What the teardown showed, per Lee’s analysis:
“An important caveat before anyone piles on: this is one camera. We don’t know how old this unit is, when it was installed, or whether its software was current relative to the rest of Flock’s fleet. That matters, and it cuts in an uncomfortable direction. The build on the device was compiled in June 2025. If that’s accurate, this wasn’t a forgotten unit that drifted out of date. It was recent software built on top of an ancient base, which points at a platform decision rather than a patching lapse.
“And that’s the part that generalizes, because almost nothing here is unique to Flock. This is the default state of the IoT industry:
“The kernel you ship is the kernel your SoC vendor gave you. Chip vendors hand device makers a board support package pinned to a specific kernel and Android version, and moving off it is expensive enough that most products never do. The OS is effectively frozen at the moment the hardware was designed, then sold and supported for a decade.
“Physical access isn’t in the threat model, even when the device lives on a pole. Keys stored next to the data they protect, plaintext credentials in persistent storage, no meaningful hardware root of trust. We see this constantly in firmware analysis and hardware assessments. If an attacker can touch the device, and for roadside infrastructure they obviously can, everything on that flash should be assumed recoverable.
“Shared secrets turn one device into the whole fleet. A hard-coded key baked into every unit means the compromise of a single camera in Wisconsin is potentially a credential-provisioning problem for every camera everywhere. That’s the finding I’d lose sleep over, not the CVE list. Individual kernel vulns matter less than the architectural reality that one extracted device can reach production infrastructure.
“None of this gets fixed by a bug bounty intake form. It gets fixed by knowing what’s actually in your firmware before it ships, threat modeling for physical possession, provisioning per-device credentials, and committing to a software lifecycle that outlives the BSP the chip vendor handed you. Regulators are starting to demand exactly this (the EU CRA’s update and support obligations come to mind), but the companies that get ahead of it will do so because it’s sound engineering, not because a checklist told them to.
“If your product runs on hardware, someone will eventually have your hardware. Design like it.”
Seeing as Flock has such a negative reaction, maybe it is time to rethink things? Just a thought.
Share this:
Like this:
Related
This entry was posted on September 18, 2026 at 4:55 pm and is filed under Commentary with tags Flock. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.