Finding 67 Flock Safety Live PTZ Camera/LPR Feeds and Debug Web Interfaces accidentally exposed without authentication to the internet

Uncategorized

** Super disappointed as well that I ended up messing up capturing artifacts so there’s many stills/some other things I would’ve loved to cover. If I end up finding another image or something I will add it. Also expect some formatting and general polishing of this post in the near future.**

With the rollercoaster I’ve experienced in the past months, the last thing I had on my mind was furthering the security research into Flock Safety devices. One of the last things I did was report a few issues directly to CERT as they previously opened a line of communication with me. I’m going to quickly cover those as they’re related to the exposed feeds. To start with, it’s important to note that from what I can tell, Collins (an application for spinning up the devices video feed) is an older use case, although it is very likely still be used in the wild depending on the devices. This write-up covers what is the more recent deployments of spinning up the device’s video feed. I’ll provide an overview of each piece of the stack but for now just note that ‘video feed stack’ is not related to Collins.

These findings are:

  1. Picard (Bravo) Compute Boxes and Falcon/Sparrow/Flex LPRs (Confident but not 100%)  enable use of cleartext traffic globally even when the Fast Reverse Proxy (FRP) tunnel drops (I’ll go over FRP later in this article), allowing control commands (CSRF deletion of footage anyone?!) and sensitive footage disclosure/interception/manipulation.

Relevant Output:

flock-video-recording.apk line 70:

`android:usesCleartextTraffic(0x010104ec)=(type 0x12)0xffffffff`

Relevant Output:

flock-speed-pourer.apk:assets/ipconfig.txt

00000000: 0000 0003 000c 6970 4173 7369 676e 6d65 ……ipAssignme 00000010: 6e74 0006 5354 4154 4943 000b 6c69 6e6b nt..STATIC..link 00000020: 4164 6472 6573 7300 0d31 3932 2e31 362e Address..192.16 00000030: 302e 3235 34

3. The ‘SpeedPourer’ FRP config can be modified/accessed by system (trivially achived since the Flock apps are shipped with ‘debuggable’ enabled).

2. Picard (Bravo) Compute Boxes and Falcon/Sparrow/Flex LPRs (Confident but not 100%) are shipped with the ‘SpeedPourer’ application which is a fully featured FTP client that loads unsigned (and insecure if desired) configs.

4. One relating to ‘Ciroc’ which I’m not going to cover in this article.

The impacts of these issues are obviously severe. An attacker can leverage the attack chains I previously disclosed and covered in my white paper [4] to expose all services directly to the internet of which the services do not support any kind of authentication or authorization (seems like it may be a theme). Additionally, one of the default services, I’ll go over the camera feed stack later in this write-up, runs an Open Network Video Interface Forum (ONVIF) service which has some interesting information disclosures and capabilities enabled/supported by default in this case. Use of ‘SpeedPourer’ also bypasses every on-device control (such what seems to be a password requirement when accessing certain camera feed services on the W/LAN).

Of course, I confirmed these by using one of my Picard compute boxes and SpeedPourer (and its FRP client) to connect and expose a web service it was running to the internet.

Now there’s more to note that I have not submitted to CERT, such as the fact that SpeedPourer stores (or at least supports) storing the passwords in cleartext. That the admin web service that’s exposed supports deleting footage via a GET request that has no CSRF protections (or authentication for that matter) among many other actions. There’s also more to poke at as it uses Mustache Templating. That’s just the tip of the iceberg…

Relevant Output:

From admin_page_template.html (lines 63-66) – Delete form uses GET:

<form method=”get” action=”/{{cameraId}}/deleteVideo”>

<input type=”hidden” name=”name” value=”{{filename}}” />

<button type=”submit”>Delete</button>

</form>

Relevant Output:

From admin_page_template.html (lines 103-110) – Bulk delete via GET fetch:

async function bulkDelete() {

const selectedFiles = document.querySelectorAll(‘input[name=”file”]:checked’);

for (const checkbox of selectedFiles) {

    await fetch(`/{{cameraId}}/deleteVideo?name=${checkbox.value}`, { method: ‘GET’ });

}

alert(‘Selected files have been deleted.’);

location.reload();

}

Full list of endpoints of the admin portal template on lab Compute unit:

EndpointMethodHandlerDescriptionEndpoint
/{cameraId}/videoAdminGETdumpFiles()Video file listing dashboard/{cameraId}/videoAdmin
/{cameraId}/videoAdmin?day=YYYY-MM-DDGETdumpFiles()Filter videos by date/{cameraId}/videoAdmin?day=YYYY-MM-DD
/{cameraId}/getVideo?name=<filename>GETgetVideoFile()Stream/download video file/{cameraId}/getVideo?name=<filename>
/{cameraId}/deleteVideo?name=<filename>GETdeleteVideoFile()Delete single video file/{cameraId}/deleteVideo?name=<filename>
/{cameraId}/deleteAllGETdeleteAllVideoFiles()Delete ALL video files/{cameraId}/deleteAll
/{cameraId}/archiveVideo?name=<filename>GETarchiveVideoFile()Move video to archive/{cameraId}/archiveVideo?name=<filename>
/rebootGETreboot()Reboot device/reboot
/speedTestGETspeedTest()Run bandwidth test/speedTest
/metadataGETpublishMetaData()Get device metadata/metadata

Full list of ONVIF Endpoints on lab Compute unit:

EndpointProtocolDescription
/onvif/device_serviceSOAP/XMLDevice capabilities, info
/onvif/device_service?wsdlHTTPWSDL definition
/onvif/media_serviceSOAP/XMLMedia profiles, streams
/onvif/ptz_serviceSOAP/XMLPan-tilt-zoom control
/onvif/analytics_serviceSOAP/XMLVideo analytics
/onvif/events_serviceSOAP/XMLEvent subscription

Default Fast Reverse Proxy (FRP) Tunnel Service on lab Compute unit:

FunctionDescription
TCP tunnelForward local ports to remote FRP server
OIDC authhttps://REDACTED.us.auth0.com/oauth/token
Audiencecom.flocksafety.frp-server

It’s clear that this admin portal including in the stack was designed with the assumption that network isolation is sufficiently hardening.

With that covered, the last thing I did was set up the wiring to add a Standard Range/Long Range camera to the camera feeds configuration so that the camera feed services would run because I don’t have a Standard Range/Long Range camera nor the camera to get it connected to the Picard Compute Box. I did however note the ports, any unique identifiers (like within the default HTML page it returns ‘admin_page_template.html’. Prior to that I did spend an hour or two doing light passive recon to see if I could find any instances of this camera feed admin page exposed to the internet. I ended up not finding anything. So, at that point, I created the wiring to add a fake camera to the camera feed stack so that the stack would fully spin up. However, with getting that wiring hopefully working at the crack of dawn, I ended up not fully confirming it, not having the time to try it out completely and then traveling for a bit.

Never did I expect the text I’d receive a few weeks later…

Introduction

It was a text from Benn Jordan. He’s a musician, Youtuber, inventor, entrepreneur, security researcher, and I hope he’ll be ok with me saying, a friend. Previously, he had reached out to me and brought me to him to assist in his video coverage of my Bird Hunting Season research, his independent Flock Safety research and Josh Michael’s [Founder of Nexanet AI] (and another friend) independent Flock Safety research.

The text was brief and odd. A cleartext HTTP URL with of just an IP on an uncommon port (8900). I navigated to it and couldn’t believe it… An unauthenticated camera feed.

He then added me to a group with 404 Media’s Jason Koebler, someone whose voice I recognize from his host/guest credits on CYBER and from his work as a journalist. I would come to find out that they were both working on pieces related to the few exposed feeds that Benn discovered and Benn was interested if I had any ideas for determining if there were more feeds exposed. Keep in mind, the web service had no with authorization banner, no authentication, no warning  and was exposed to the internet. Especially because Benn ended up finding the three (3-4) live instances by searching “Flock Admin” on Shodan…

As a side note, I love Shodan (yes I know I love a lot of things relating to offensive security) and those types of search engines. I’ve had a dream to build my own system to continuously port scan the internet for a long time, maybe one day…

I have extensive experience with Shodan and have found my fair share of wild stuff, although nothing that compares to what Viss has found. I highly recommend the amusement you’ll get from watching one of his lectures. [5]

As I mentioned, the passive reconnaissance and OSINT I did previously include Shodan. Point 1 to note, it turns out that the admin template on my units were different than the ones Benn discovered. So, I most definitely was envious of his discovery momentarily, which was then instantly washed away by the stroke I felt for him. Because of what he found and that he was the one who found it.

 If my experience doing a breadth of offensive security engagements for over a decade has taught me anything, it is that I knew instantly there were more instances of what Benn found out there. In fact, if you go into Shodan today, you can see entries that are quite old, some first seen in 2023 I believe even, but ultimately Shodan had about 11 listing with 3 or so being live still.

After some discussion and banter with both Benn and Jason, as well as mulling over if I could bring myself to do some research of my own. I decided to show Benn he told the right guy (subtle I know). External penetration tests are one of my favorite types of engagements (real ones not port scans + vulnerability scans) and the passive/semi-passive recon phase is often neglected.

It was at this point that I told Benn and Jason why (most likely) the camera feeds were exposed and what type of devices they were. I’d later come to learn that both theories I disclosed were half right, something I found quite embarrassing and will haunt me occasionally when I try to sleep for the foreseeable future. Given if you put yourself in my shoes, the last thing I did was discover the vulnerabilities I covered in the first section of this paper which most definitely could explain how these feeds ended up exposed to the internet…

However, I ran into important point 2 & point 3 at this time, when viewing the `logcat` output of the instances Benn found (yes you can do that, find out further in this paper) there were references to Flock applications running on the units I never saw before. There was also some configuration information on those did not mention Falcon, Flex, Sparrow, Range, Picard, or any of the model/internal names of the units I have in my lab. 

Before I step through the process I took to turn his 3 or 4 instances of camera feeds into 67, let’s go over the video feed stack. From what I saw, the primary stack is the same, it’s just optional pieces (SPOILER ALERT), like ‘SpeedPourer’ were not running on most of the instances.


Feed Stack & Other Affected Services

Since most of the feeds were Pan Tilt Zoom (PTZ) it makes sense as to why I saw some new applications in the logs (I don’t have a Flock PTZ Camera in my lab).

So, I’ve broken down from what I’ve understood the stack looks like.

Port Summary:

PortServiceProtocolAuth
8900Admin PortalHTTPNone
8554RTSP LiveRTSP/RTPNone
8000ONVIFSOAP/XMLNone
9554RTSP Live?RTSP/RTP?None
554RTSP LiveRTSP/RTPNone

Most importantly point 5, these services bind to * aka 0.0.0.0 by default. Which is a concern. As well as a hint as to how this exposure occurred.

Feed Stack & Other Affected Services

My general approach was to determine as many unique fingerprints as possible to make OSINT similar. Which leads me to point 6, all 67 live camera feeds I found were shown to be on a Verizon ASN.

So doing a search query on Shodan & ZoomEye searching that ASN, with Port 8900 and in the US is how I found 15 or so more live instances.

Example Shodan Query:

country:”US” port:”8900” asn:”AS12738”

Example ZoomEye Query:

country=”US” && port=”8900” && asn=”AS12738”

I also did some queries with the default DNS names assigned by Verizon. Then I did a port scan for port 8900 first for only the last octet (/24) and then for the two last octets (/16). Additionally, I ran httpx on port 8900 against the same octets, although eventually I stopped it before it finished. That’s how the found instances grew to 67.

Then once I had the list, I use a script to hit the IPInfo API to get the geolocation data. Which if you know you know, wasn’t completely accurate but was surprisingly closer to the actual location of the cameras then you’d think. However, as I’m not good at geo guessing someone else figured out precisely where all the cameras were physically located.

So, here’s a high-level overview of the tooling I used, note that I did try regular search engine dorking and some other OSINT techniques like searching by source code, etc., but as expected, there were no results.

ToolPurpose   
ShodanInternet-wide device search   
ZoomEyeInternet-wide device search   
MasscanHighspeed port scanner       
httpx  HTTP probing/fingerprinting   
IPInfo IP geolocation API            

Let me be clear, this is obviously not the route or process I’d take during an actual engagement, but I was prioritizing keeping things light and quick as well as not trying to put the same amount of effort I would if this was a real engagement. Among many other things.

Below is the list of the 67 instances I found. I’ll include them again along with the output from IPInfo in the following section.

75.194.128.14175.198.223.675.205.159.6675.205.211.4175.226.76.15197.147.0.53
75.194.146.16375.198.45.5575.205.165.23675.205.212.14175.226.76.2597.147.101.112
75.194.148.20075.198.58.13275.205.177.24575.226.140.3475.226.83.13197.147.117.40
75.194.162.19375.203.180.17175.205.180.22275.226.153.15275.226.85.8297.147.45.77
75.194.172.24875.205.138.14075.205.182.4875.226.198.4475.226.94.397.147.57.180
75.194.183.10575.205.140.4575.205.183.14375.226.202.17275.232.66.9797.147.75.156
75.198.133.15675.205.146.11775.205.184.23775.226.232.16375.236.195.8697.147.91.61
75.198.149.10575.205.147.12475.205.185.1275.226.247.6775.236.210.149 
75.198.167.11075.205.148.14175.205.185.12075.226.65.17875.236.224.7 
75.198.205.2475.205.153.21775.205.186.7075.226.69.13775.236.229.174 
75.198.208.15475.205.156.2475.205.187.24975.226.70.17375.236.244.20 
75.198.209.2975.205.159.13775.205.188.8375.226.75.12375.239.144.182 

How & Why The Camera feeds Ended up Exposed on the internet

My original theory that I voiced to Jason and Benn was:

1. These are likely all Picard (Bravo) Compute Boxes

2. They are exposed because Flock spun up ‘SpeedPourer’ FRP and forgot to shut it down.

It’s frustrating to have to keep saying “I think,” and I apologize for that. I have misplaced some of my notes or more likely, I didn’t take enough.

Turns out that I was right and I was wrong. There were some LPRs/ Picard (Bravo) Compute Boxes that were using SpeedPourer FRP…BUT they were properly connected to a Flock proxy server so ultimately the camera feed was exposed for the same reason as the other devices.

So, what happened you ask?!

Well, it turns out that 4G/LTE/5G is not guaranteed to be Carrier-Grade Network Address Translation (CGNAT) nor to even be behind a firewall. Which was news to me. It turns out that it is uncommon but not unheard of that 4G/LTE/5G to not have these basic protections. The good news is, it seems that I learned this at the same time Flock did which is also bad news. I’m not 100% on this, but from what I understand, when SIM/eSIMs are purchased from the business side of an ISP and/or when it’s a data only SIM there’s a higher likelihood of this occurring. But don’t quote me on that.

So, the lack of CGNAT + Firewall at the ISP level means that those services bound to all network interfaces will happily respond on the external IP address.

Voila.

It also lead to some funny cases like the fact that the LAN RTSP feed on one of the ports had authentication (although in the next section I’ll cover a bunch of security issues with Flock’s implementation) but since you weren’t hitting the device over its W/LAN IP, no big. Although it was possible to change the RTSP password anyway or remove it entirely.

Another interesting case was only a few of the instances had a “Commands” Section on one page of the admin/debug portal. But it the JavaScript (JS) or whatever needed to utilize was missing from the instance. Not that I would’ve tried that anyway. I also considered just adding the JS myself based off the functionality in the admin template portal I have on my unit but as this is security research I of course did not attempt to do that.

Other Security issues

Example of one of the PTZ (Condor) Exposed Cameras.

Example of one of the Falcon/Sparrow/Flex LPR’s Exposed Cameras.

Another example of one of the Falcon/Sparrow/Flex LPR’s Exposed Cameras.

Some had multiple units connected to them.

There were even either long range Falcon or Standard/Long Range Cameras that are connected to the Picard (Bravo) Compute box as well.

Note that there’s no password to access the feed set for the LPRs.

Additionally, it seemed that the units that did have passwords set to view the RTSP feeds locally or via the FRP they had setup likely, the passwords *seemed* modifiable (I didn’t check) and when they were set, they were unique but disclosed in cleartext.

Condors had encrypted passwords and some were in cleartext.

In terms of security issues, there’s quite a few, so I’ll list them below:

Log Disclosure Security Issues:

  1. RTSP Digest Authentication Credentials Exposed

Authorization: Digest username=”admin”, realm=”e4f14c8af4f6″,

nonce=”e9349247cd7ec8a04d51438ed1bc3e0a”,

uri=”rtsp://192.168.0.100:554/”,

response=”1d08fa25b19674601d7983bd8cf96e91″

  • RTSP Session IDs Exposed

Session: a15cad996e4cad996a4cad99064cad9

Session: 227d238ced6d238ce96d238c856d238

  • Auth0 Token Usage Logged

Auth0ServiceController: service: com.flocksafety.android.sambuca.lib.IAuth0KeyServiceInterface$Stub$Proxy@8eccfce

HpnotiqService: HpnotiqService using Auth0 token

  •  Device Serial Numbers Disclosed

HpnotiqService: sendValidationTestResults() serial=250403P021004BR

  • Camera IDs & File Paths Exposed

Camera ID: 250626900E5, Format: H265, Average FPS: 19.9

/media/ufs/media/pipeline/250626900E5/2025-12-11/18/discard_2025-12-11-18-52-37-660_1.mp4

/media/ramdisk/250626900E5/hls/1920×1080/H265/2025-12-11/segment_1765479157755.ts.tmp

  • FRP Tunnel Session IDs

FrpTunnel: frp log: [bd148b4ad64738ab] send heartbeat to server

FrpTunnel: frp log: [bcc8e160571e8832] receive heartbeat from server

FrpTunnel: frp log: [4eeb894e4e9094fb] send heartbeat to server

  •  Internal RTSP Client User-Agent

User-Agent: happytimesoft rtsp client

Confirms use of HappyTime RTSP library.

  • Full Java Stack Traces

Logs contain complete stack traces revealing:

– Internal class names (com.flocksafety.android.peripheral.impl.PowerModuleDevice)

– Method names and line numbers

– File paths (PeripheralControllerPicard.kt:475)

  • Video Encoding Parameters

bitrate = 15750000

width = 1920, height = 1080

frame-rate = 30

mime = “video/hevc”

10. System Build Info

TKQ1.250502.001  (Android build version)

Qualcomm QC2 media codecs

Impact

Based off the reversing and analysis I performed from the versions of the applications on the units in my lab, things like video modification, deletion, denial of service, etc. were all possible while these feeds were exposed. Beyond just the fact that the feeds were exposed!

Additionally, the exposed device identifiers, cellular network information, and tunnel configurations provide sufficient data for an attacker to fingerprint, geolocate, and potentially target specific Flock Safety camera units. Leaked FRP tunnel session IDs and server addresses reveal the exact attack surface for accessing internal device services including RTSP video streams and HTTP management interfaces. The combination of missing ADB key initialization, SELinux policy failures, and verbose authentication logging creates multiple vectors for unauthorized access and privilege escalation. If exploited, an attacker could intercept video feeds, manipulate device configurations, or use compromised units as pivot points into Flock Safety’s infrastructure. These findings represent systemic logging hygiene issues that expose sensitive operational and personal identifiable information across the entire device fleet.

Recommendations

#CategoryRecommendation
1Device IdentifiersHash or tokenize all hardware identifiers before logging (camera IDs, child serials, battery serials, external battery JSON fingerprints)
2Cellular PIIStrip MCC/MNC, Cell ID, and TAC from StatusTask logs
3FRP Tunnel SessionsEncrypt or mask tunnel session IDs in logs
4Tunnel ConfigDo not log server addresses, ports, or device external IDs
5Auth0 ServiceRemove service proxy addresses from verbose logging
6ADB ConfigurationProperly initialize ADB keys or disable ADB entirely in production
7SELinux HardeningReview and fix policy denials (cache_file, vendor_qmcs_file, firmware_file)
8Diag SubsystemFix Diag_LSM_Init failures – diagnostic subsystem not functioning
9Network BindingOnly have services listen on required interfaces; avoid binding to 0.0.0.0 when localhost suffices
10Credential StorageDo not store passwords or secrets in cleartext; use secure credential storage
11Defense in DepthDo not rely on security through obscurity; implement proper authentication and authorization
12Access MonitoringLog and monitor access to sensitive services and endpoints

Conclusion

This took way too long to write up, and I dropped the ball in terms of notes, stills and artifacts. There is a ton of meat left on the bone in terms of other security analysis (or even tests if one were to be authorized). Even further examination of the logs may reveal more information. That said, it clearly indicates that the previous issues I’ve disclosed and covered in my white paper are the tip of the iceberg and Flock Safety (as well as any vendor in similar industries) can really benefit from getting their infrastructure, devices, and applications tested thoroughly and continuously. Seeing that they’ve recently opened a position for Director of OffSec is a great sign imo. This is also the first and likely only time I will have had any type of insight into how these LPRs, Compute Boxes and PTZs that record me every time I leave my street (like they do that) run in the wild.

P.S. – I did provide CERT with info relating to the exposed camera feeds prior to Benn’s video being released. However, I never heard back so I have no idea if they did anything with it. That said, last time I ran a quick check, all 67 instances are no longer exposed unauthenticated to the entire internet. It is also unclear how long they ended up being exposed.

Just a final reminder, that IP address to Coordinate lookup are rarely correct and I know for a fact that the Coordinates I provide below aren’t exact. Enjoy.

#IP AddressCityStateCoordinatesPostal
175.194.128.141RocklinCalifornia38.7907,-121.235895677
275.194.146.163SunnyvaleCalifornia37.3688,-122.036394088
375.194.148.200RocklinCalifornia38.7907,-121.235895677
475.194.162.193SunnyvaleCalifornia37.3688,-122.036394088
575.194.172.248SunnyvaleCalifornia37.3688,-122.036394088
675.194.183.105SunnyvaleCalifornia37.3688,-122.036394088
775.198.133.156RocklinCalifornia38.7907,-121.235895677
875.198.149.105RocklinCalifornia38.7907,-121.235895677
975.198.167.110RocklinCalifornia38.7907,-121.235895677
1075.198.205.24RocklinCalifornia38.7907,-121.235895677
1175.198.208.154RocklinCalifornia38.7907,-121.235895677
1275.198.209.29RocklinCalifornia38.7907,-121.235895677
1375.198.223.6RocklinCalifornia38.7907,-121.235895677
1475.198.45.55IndianapolisIndiana39.7684,-86.158046204
1575.198.58.132IndianapolisIndiana39.7684,-86.158046204
1675.203.180.171AuroraColorado39.7294,-104.831980040
1775.205.138.140CharlotteNorth Carolina35.2271,-80.843128202
1875.205.140.45CharlotteNorth Carolina35.2271,-80.843128202
1975.205.146.117CharlotteNorth Carolina35.2271,-80.843128202
2075.205.147.124CharlotteNorth Carolina35.2271,-80.843128202
2175.205.148.141CharlotteNorth Carolina35.2271,-80.843128202
2275.205.153.217CharlotteNorth Carolina35.2271,-80.843128202
2375.205.156.24CharlotteNorth Carolina35.2271,-80.843128202
2475.205.159.137CharlotteNorth Carolina35.2271,-80.843128202
2575.205.159.66CharlotteNorth Carolina35.2271,-80.843128202
2675.205.165.236RichmondVirginia37.5538,-77.460323173
2775.205.177.245AlpharettaGeorgia34.0754,-84.294130009
2875.205.180.222AlpharettaGeorgia34.0754,-84.294130009
2975.205.182.48AlpharettaGeorgia34.0754,-84.294130009
3075.205.183.143AlpharettaGeorgia34.0754,-84.294130009
3175.205.184.237AlpharettaGeorgia34.0754,-84.294130009
3275.205.185.12AlpharettaGeorgia34.0754,-84.294130009
3375.205.185.120AlpharettaGeorgia34.0754,-84.294130009
3475.205.186.70AlpharettaGeorgia34.0754,-84.294130009
3575.205.187.249AlpharettaGeorgia34.0754,-84.294130009
3675.205.188.83AlpharettaGeorgia34.0754,-84.294130009
3775.205.211.41VistaCalifornia33.2000,-117.242592083
3875.205.212.141VistaCalifornia33.2000,-117.242592083
3975.226.140.34North Las VegasNevada36.1989,-115.117589036
4075.226.153.152North Las VegasNevada36.1989,-115.117589036
4175.226.198.44SchertzTexas29.5522,-98.269778154
4275.226.202.172SchertzTexas29.5522,-98.269778154
4375.226.232.163TulsaOklahoma36.1540,-95.992874102
4475.226.247.67TulsaOklahoma36.1540,-95.992874102
4575.226.65.178EulessTexas32.8371,-97.082076040
4675.226.69.137EulessTexas32.8371,-97.082076040
4775.226.70.173EulessTexas32.8371,-97.082076040
4875.226.75.123SouthfieldMichigan42.4734,-83.221948086
4975.226.76.151SouthfieldMichigan42.4734,-83.221948086
5075.226.76.25SouthfieldMichigan42.4734,-83.221948086
5175.226.83.131New BerlinWisconsin42.9764,-88.108453151
5275.226.85.82New BerlinWisconsin42.9764,-88.108453151
5375.226.94.3OmahaNebraska41.2563,-95.940468101
5475.232.66.97YonkersNew York40.9304,-73.897910702
5575.236.195.86AlpharettaGeorgia34.0754,-84.294130009
5675.236.210.149AlpharettaGeorgia34.0754,-84.294130009
5775.236.224.7AlpharettaGeorgia34.0754,-84.294130009
5875.236.229.174AlpharettaGeorgia34.0754,-84.294130009
5975.236.244.20WindsorConnecticut41.8526,-72.643706006
6075.239.144.182HoustonTexas29.7633,-95.363377002
6197.147.0.53SchertzTexas29.5522,-98.269778154
6297.147.101.112Baton RougeLouisiana30.4433,-91.187570801
6397.147.117.40Baton RougeLouisiana30.4433,-91.187570801
6497.147.45.77SchertzTexas29.5522,-98.269778154
6597.147.57.180SchertzTexas29.5522,-98.269778154
6697.147.75.156Baton RougeLouisiana30.4433,-91.187570801
6697.147.91.61Baton RougeLouisiana30.4433,-91.187570801

Summary by Location

StateCityCount
GeorgiaAlpharetta14
CaliforniaRocklin9
North CarolinaCharlotte9
TexasSchertz5
LouisianaBaton Rouge4
CaliforniaSunnyvale4
TexasEuless3
MichiganSouthfield3
CaliforniaVista2
NevadaNorth Las Vegas2
OklahomaTulsa2
WisconsinNew Berlin2
IndianaIndianapolis2
ColoradoAurora1
ConnecticutWindsor1
NebraskaOmaha1
New YorkYonkers1
TexasHouston1
VirginiaRichmond1

Total: 67 instances across 19 cities in 15 states — all on Verizon Business (AS6167)

PackageDescription
com.flocksafety.android.videorecordingVideo recording service
com.flocksafety.android.streamingVideo streaming service
com.flocksafety.android.pipelineVideo processing pipeline
com.flocksafety.android.cameraconfigCamera configuration / admin portal
com.flocksafety.android.peripheralPeripheral device control
com.flocksafety.android.peripheral.implPeripheral implementation
com.flocksafety.android.peripheral.libPeripheral library
com.flocksafety.android.sambuca.libAuth0 authentication library
com.flocksafety.android.sensorserviceSensor data collection
com.flocksafety.android.medallalightCrash / log collection
PackageDescription
com.android.server.adbADB debugging service
com.android.serverSystem server
com.android.providers.mediaMedia provider
com.android.internal.utilInternal utilities
com.android.phonePhone / telephony
com.android.shellShell service
com.android.printspoolerPrint spooler
com.android.statementserviceStatement service
com.android.cellbroadcastreceiver.moduleCell broadcast
com.android.remoteprovisionerRemote provisioning
com.android.adservicesAd services
com.android.wifiWiFi service
com.android.tetheringTethering
com.android.cellbroadcastCell broadcast
com.android.mediaproviderMedia provider
com.android.ondevicepersonalizationPersonalization
Service TagDescription
SpeedPourerServiceFRP / port forwarding service
FlockCameraManagerCamera management
FlockBatteryStationHALBattery station HAL
Phone Home ServiceTelemetry / status reporting
Auth0ServiceControllerAuth0 authentication
HpnotiqServiceValidation / test service
AdbDebuggingManagerADB debugging
DiskStatsServiceDisk statistics
BatteryExternalStatsWorkerBattery stats
AmbientContextManagerServiceAmbient context
AutofillManagerServiceAutofill
GnssLocationProviderGPS location
TelephonyManagerTelephony
ReferenceContext
android.os.Binder.doDumpBinder dump operations
android.os.Binder.dumpBinder dump
android.os.Binder.onTransactBinder transaction handler
android.os.Binder.execTransactInternalTransaction execution
android.os.Binder.execTransactTransaction execution
android.debug.IAdbManager$Stub.onTransactADB manager AIDL
IPeripheralServiceInterface$Stub.onTransactPeripheral service AIDL
IAuth0KeyServiceInterface$Stub$ProxyAuth0 service proxy
hw-BpHwBinderHardware binder proxy
JavaBinderJava binder exceptions
ClassMethodFile:Line
PowerModuleDevicereadWithSocket()PowerModuleDevice.kt:228
PowerModuleDeviceread()PowerModuleDevice.kt:93
PeripheralControllerPicardgetPpmValues()PeripheralControllerPicard.kt:475
PeripheralService$binder$1getPpmValues()PeripheralService.kt:159
IPeripheralServiceInterface$StubonTransact()IPeripheralServiceInterface.java:389
SensorRecorderTask$sendPowerSources$1invokeSuspend():694
ClassMethodFile:Line
AdbDebuggingManagerdump()AdbDebuggingManager.java:1776
AdbServicedump()AdbService.java:604
DiskStatsServicereportCachedValues()DiskStatsService.java:209
DiskStatsServicedump()DiskStatsService.java:147
MediaProviderdump()MediaProvider.java:10678
FastPrintWriterflushBytesLocked()FastPrintWriter.java:354
LoggingdumpPersistentFile()Logging.java:158
IoBridgeopen()IoBridge.java:574
FileInputStream<init>FileInputStream.java:160
FileUtilsreadTextFile()FileUtils.java:637
RuntimeInit$MethodAndArgsCallerrun()RuntimeInit.java:548
ZygoteInitmain()ZygoteInit.java:942
ComponentDescription
vendor.qti.media.c2@1.0-serviceQualcomm media codec service
android.system.suspend@1.0-serviceSystem suspend service
QC2InterfaceQualcomm Codec2 interface
QC2ImageConverterImage conversion
QC2V4l2DriverV4L2 video driver
CCodecBufferChannelCodec buffer channel
MPEG4WriterMP4 file writer
diagcommdQualcomm diagnostics daemon
Diag_LibDiagnostics library
TagCategory
EncodeNodeVideo encoding
AVFileWriter-DiscardedFile writing
NativeMuxerMedia muxing
DiskManagerStorage management
flock-rtspRTSP streaming
MPEG4WriterMP4 writing
QC2ImageConverterImage conversion
NEncoder2-DiscardedEncoder
CCodecBufferChannelCodec buffers
Codec2-OutputBufferQueueOutput queue
PipelineWatcherPipeline monitoring
AssetDetectorAsset detection
FrpTunnelFRP tunnel logs
RTSP_CLNRTSP client
CrashPackUtilCrash reporting
goat_collectorMemory monitoring
dumpstateSystem dump
SDMDisplay manager
BufferPoolAccessor2.0Buffer pool
PathContent
/media/ufs/media/pipeline/250626900E5/Video recordings
/media/ramdisk/250626900E5/hls/HLS stream segments
/data/misc/adb/adb_keysADB authorization keys
/data/misc/adb/adb_temp_keys.xmlTemporary ADB keys
/data/system/diskstats_cache.jsonDisk statistics
/data/user_de/0/com.android.shell/files/bugreports/Bug reports
/dev/video33Video device

You can download two pieces of the log files that were exposed as shown below HERE

END TRANSMISSION

Published

Leave a Reply