Everything I own, owned - schlarp.comEverything I own, owned<br>August 23, 2026Over the past couple weeks I’ve been doing agent-driven reverse engineering of peripherals that happen to be<br>within arm’s reach. From those devices, I’ve come away with a full plaintext command shell inside my microphone,<br>a webcam whose activity LED I can switch off while it records, and a key light that hands out memory writes to<br>anyone on the WiFi. Peripherals have proven to be an ideal target for agentic RE - they’re tiny computers<br>attached to my computer, with a data connection to the host and usually a firmware update mechanism, so an<br>agent has something to iterate against. The net outcome is better control and understanding of my machine.<br>My process was pretty much the same for each of these devices: grab a copy of the device’s firmware and<br>associated update tool from the manufacturer, throw it into my<br>reverse engineering environment, tell Claude Opus 5 what my goals are,<br>and let it churn. Depending on the device, the goals were somewhat different, but they usually looked something<br>like:<br>In this directory is the firmware and update utility for ___. The device is also attached to this computer, and you may interact with it in non-mutating ways. Exhaustively document and cross-validate the entire firmware, including the following goals:
* reverse engineer the firmware update format and update protocol<br>* implement our own update utility<br>* determine the security properties of the update protocol, including checksums, signature validation, secure boot<br>* use static and dynamic analysis to determine all protocol surfaces and completely enumerate functionality<br>* find any hidden or debug functionality in the product and how to access it<br>Depending on the results, there were different directions of follow-up, but you should get the general idea.<br>Let’s run through the list - each device links to a GitHub repo full of generated-slop docs and scripts, most<br>of which have been validated live against real hardware. I’ve also included the effort each device took, pulled<br>out of the Claude Code session transcripts. “Churn” is the time Claude was actually working, with the long idle<br>gaps removed. “Prompts from me” is every message I typed, including the one-word ones telling it to keep going.<br>All five devices together came out to about 13 hours of churn and 98 prompts, spread across two weeks of<br>evenings.<br>Everything I own<br>Insta360 Link webcam<br>GitHub repo - 3.7 hours of Claude churn, 33 prompts from me
I use an Insta360 Link webcam, which is a nice gimbaled pan-tilt-zoom camera that does face<br>tracking for automatically framing the shot. I wanted to know if it was possible to subvert the activity LED,<br>like in the classic<br>iSeeYou exploit.<br>Interestingly, it was immediately obvious that this camera has a lot going on inside it. It turns out that it<br>runs a whole RTOS (ThreadX) sourced from the upstream SoC vendor, Ambarella. The<br>RTOS hosts several small vision models that provide things like the aforementioned face tracking, as well as<br>gesture detection for controlling settings. Pretty amazing complexity inside a tiny webcam, but it also means<br>there’s some exciting attack surface here.<br>Over the USB Video Class interface, there’s an XU (Extension Unit) command that kicks the device into “mass<br>storage” mode. This then lets us transfer a staged firmware update to the device’s internal FAT filesystem,<br>which the device then applies to itself on reboot. This route does require user intervention to reboot with a<br>replug, but there’s actually another command channel that exposes<br>arbitrary read/write of files and a<br>reboot command over the USB vendor class. With this, we can fully flash the device without any user interaction.<br>Once the firmware is in the right place, there’s effectively no anti-tamper, just an appended MD5 hash to<br>ensure integrity.<br>The indicator LED turns out to have a<br>well-structured set of “patterns”<br>in the firmware that dictate color, blink pattern, etc. that are indexed into for various device states. I had<br>Claude write a tool to patch out the table entry for camera activity, fix up the integrity hash, and flash it to<br>the camera. A quick test showed that the green LED that normally illuminates while recording no longer turned<br>on. Horrifying! On this device, the gimbal itself also deflects down when not recording, so it’s not<br>completely stealth, but it still doesn’t feel great.
The LED behavior before and after patching.<br>ASUS ROG Swift PG42UQ monitor<br>GitHub repo - 1.2 hours of Claude churn, 13 prompts from me
My ASUS ROG Swift PG42UQ monitor was actually where I started, because I got annoyed at the pop-up overlay<br>that comes up every once in a while that tells me to run “pixel cleaning”. I have never intentionally run pixel<br>cleaning on this monitor and I never will, I don’t care, and I would...