⏱️ Lectura: 12 min
An ASUS ROG Swift PG42UQ monitor costing nearly two thousand dollars accepts any firmware file sent to it over USB: no signature, no cryptographic validation, just a simple checksum. That is what a developer identified as schlarp found when he reverse-engineered the peripherals on his desk using AI with Claude Opus 5.
📑 En este artículo
Over two weeks of late-night sessions, the experiment expanded to five devices: a webcam, a monitor, a microphone, a video call light, and a fifth peripheral. The results were fully documented on his blog, with the code and findings published in GitHub repositories validated against real hardware.
TL;DR
- A developer used Claude Opus 5 to audit 5 peripherals over 2 weeks of late-night sessions: 13 hours of agent work and 98 prompts total.
- The Insta360 Link webcam exposes a hidden USB channel with arbitrary file read and write access, requiring no user interaction.
- Claude patched the Insta360 Link’s LED table and disabled the recording indicator after recalculating the firmware’s MD5 integrity hash.
- The ASUS ROG Swift PG42UQ monitor updates its firmware over I2C via USB with only a simple checksum, no cryptographic signature.
- The Insta360 Link runs a full Ambarella ThreadX RTOS, with embedded vision models for facial tracking and gesture detection.
- The webcam case recalls the 2013 iSeeYou exploit, which disabled the LED on MacBook iSight cameras without lighting any indicator.
- The five generated repositories were made public on GitHub, with documentation and flashing tools validated against real hardware.
- The video call light in the experiment exposes arbitrary memory writes accessible from the local WiFi network.
What happened
The experiment started over a household annoyance: schlarp kept getting a “pixel cleaning” notice on his ASUS ROG Swift PG42UQ monitor that he never asked to run. Instead of searching some forum for a modified firmware, he gave Claude Opus 5 access to the official firmware, the manufacturer’s update tool, and the physical device connected via USB, with explicit instructions not to change anything yet: only document, analyze, and validate.
The result was a pattern that repeated across all five devices: firmware downloaded from the manufacturer, the official update tool decompiled, the update protocol reconstructed by hand by the agent, and, in several cases, a hidden command channel the manufacturer never publicly documented.
By schlarp’s own count, taken directly from the Claude Code session transcripts, the total work added up to 13 hours of “churn” (the time the agent was actively working, not counting idle periods) and 98 prompts from the author, spread across two weeks of late-night sessions for five devices: a webcam, a monitor, a microphone, a video call light, and a fifth peripheral rounding out the list.
Context and history
Reverse engineering consumer firmware is not new: there’s a long tradition of hobbyists tearing apart routers, printers, and cameras to unlock features or audit their security. What changes with agents like Claude Opus 5 is the speed at which you can go from “I have a binary” to “I have a documented protocol and a working proof of concept against the real hardware”.
schlarp used a repeatable methodology for all five devices: he gave the agent the firmware, the official update tool, and read-only access to the connected device, and asked it to reconstruct the update format, implement its own flashing tool, evaluate the security properties (checksums, signatures, secure boot), and look for hidden or debug functionality.
The webcam case directly recalls the iSeeYou exploit, documented in 2013 by researchers at Johns Hopkins, which showed it was possible to record video on MacBook iSight cameras without turning on the indicator LED by reprogramming the camera’s microcontroller. More than a decade later, the same underlying problem (an LED controlled by software, with no hardware-level guarantee) is still alive in new devices.
Technical details and performance
The Insta360 Link turned out to be much more than a webcam: it runs a full real-time operating system, ThreadX, on an Ambarella system-on-chip, with several embedded vision models that perform facial tracking and gesture detection to control camera settings. All that complexity opens up an attack surface.
On top of the standard USB Video Class (UVC) interface, the camera exposes an Extension Unit (XU) command that puts it into “mass storage” mode, which allows a prepared firmware update to be copied to the device’s internal FAT file system, applied only on reboot. But there’s also a second channel, over the USB vendor class, that exposes arbitrary file read and write access and a remote reset command, with no need for the user to unplug and replug the cable. With that, it’s possible to fully reflash the device with zero human interaction.
The only integrity protection the agent found was an appended MD5 hash at the end of the firmware binary, with no cryptographic signature scheme or secure boot whatsoever. The firmware also contains a well-structured table of LED “patterns” (color, blinking) indexed by device state. Claude wrote a tool that locates the entry corresponding to “recording”, replaces it, recalculates the MD5 hash, and flashes the result. The test showed that the green LED that normally lights up while recording stopped activating. The camera’s gimbal does tilt downward when it’s not recording, so the concealment isn’t total, but the main light indicator is left entirely under the control of whoever has USB access.
The ASUS ROG Swift PG42UQ turned out to be even less protected: it updates its firmware over I2C, an internal bus that on this monitor is exposed through USB. The scheme uses two slots (A/B) with a simple checksum, no cryptographic signature of any kind. In practice, anyone with bus access can write whatever firmware they want. The “pixel cleaning” notice that started the whole experiment turned out to have no native option to disable it (it always reappears after 8 hours of use), but the agent did find the exact spot in the binary where that logic could be patched.
| Device | Main finding | Agent hours | Author prompts |
|---|---|---|---|
| Insta360 Link webcam | Vendor-class USB channel with arbitrary read/write access and control of the recording LED | 3.7 | 33 |
| ASUS ROG Swift PG42UQ monitor | Firmware with no cryptographic signature, just a simple checksum over I2C/USB | 1.2 | 13 |
| Microphone (not identified in the summary) | Plain-text command shell exposed | Not broken down | Not broken down |
| Video call light (not identified in the summary) | Arbitrary memory writes accessible from the WiFi network | Not broken down | Not broken down |
| Total (5 devices) | – | 13 | 98 |
The full churn and prompt figures are taken directly from the session transcripts that schlarp published alongside the analysis; the original report covers the microphone and the light in more depth, though without breaking down the exact time for each.
⚠️ Heads up: reflashing firmware on a real device carries a real risk of bricking it. schlarp himself admits he hasn’t yet worked up the nerve to write the modified firmware to his actual monitor, given the cost of the hardware.
flowchart TD
A["Official firmware and update tool"] --> B["Claude Opus 5 agent"]
B --> C["Static binary analysis"]
B --> D["Dynamic analysis against the real device"]
C --> E["Generated documentation and scripts"]
D --> E
E --> F["Validation on real hardware"]How to start your own AI reverse engineering
You don’t need a hardware lab to get started. The first step is simply seeing what your operating system exposes about each connected USB device.
# Linux: list USB devices with interface and endpoint detail
lsusb -v -d <vendor_id>:<product_id> | less
# macOS: full USB inventory
system_profiler SPUSBDataType
# Windows (PowerShell): connected USB devices
Get-PnpDevice -Class USB | Format-Table -AutoSizeThat first command already tells you how many interfaces the device exposes (on the Insta360 Link, for example, you’d see the standard UVC interface plus the vendor-specific interface that hides the arbitrary read/write channel) and which USB class each one is registered under.
The next step is to get the firmware and the manufacturer’s official update tool, and ask an agent like Claude Code to analyze them before touching anything. A minimal flow, once you have the binary downloaded, looks like this:
import hashlib
def recalcular_integridad(firmware: bytes) -> bytes:
# Reproduces the append-MD5 scheme Claude found
# on the Insta360 Link: the hash is appended to
# the end of the binary, with no cryptographic signature.
cuerpo = firmware[:-16]
checksum = hashlib.md5(cuerpo).digest()
return cuerpo + checksum
with open("firmware_original.bin", "rb") as f:
original = f.read()
# illustrative offset: the real one depends on each binary's layout
parcheado = bytearray(original)
parcheado[0x4A210:0x4A214] = b"\x00\x00\x00\x00"
firmware_final = recalcular_integridad(bytes(parcheado))
with open("firmware_parcheado.bin", "wb") as f:
f.write(firmware_final)This example is illustrative, not the actual offset schlarp used (he didn’t publish the full binary), but it reflects the general pattern: locate the data to modify, patch the bytes, and recalculate any integrity checksum before reflashing.
To verify your own analysis is on the right track, confirm each finding against the real device before assuming it’s correct: capture USB traffic with Wireshark plus the usbmon plugin on Linux (or USBPcap on Windows) while the official tool performs a legitimate update, and compare those packets against what your own implementation produces.
Impact and analysis
The pattern schlarp documented isn’t exclusive to these five devices: consumer peripherals are increasingly full computers (with their own operating system, their own network or USB stack, and their own update mechanism) sold as if they were passive accessories. That gap between a device’s actual complexity and the protection given to its firmware is, based on what this case shows, fairly common: neither the webcam nor the monitor had a cryptographic signature in their update scheme.
The advantage of using AI reverse engineering for this kind of work isn’t that Claude Opus 5 finds vulnerabilities a human engineer couldn’t find (everything it did could, in principle, be done by someone experienced in reverse engineering), but the speed: 13 hours of effective work and 98 prompts to cover five different devices is a pace that would previously have taken weeks of manual work per device.
💭 Key point: the agent didn’t just find the bugs, it also generated its own flashing tool and documentation for each device, published on GitHub and validated against real hardware, not just theorized on paper.
The video call light case (with arbitrary memory writes accessible from the local WiFi network) is probably the most serious of the five, because it requires no physical access or USB cable: any device on the same network could, in theory, exploit that channel. schlarp doesn’t detail in the summary whether he notified the manufacturer before publishing, a step that would be expected in a responsible vulnerability disclosure.
Try it yourself: run lsusb -v (or its macOS/Windows equivalent) on the next peripheral you connect, and check how many vendor-specific interfaces it exposes before assuming it’s a safe black box.
📖 Summary on Telegram: View summary
What’s next
schlarp plans to follow the same process with other devices on his desk, and has already said that at some point he’ll work up the nerve to try the patched firmware on his real monitor, currently held back by the risk of losing an expensive piece of hardware. The pattern of “give me the firmware, the update tool, and device access, and document everything before touching anything” stands as a reusable template for any developer curious about what’s running inside their own peripherals.
For the rest of the industry, the case leaves an open question: if auditing five consumer devices with AI reverse engineering took just 13 hours and found a lack of cryptographic signing in at least two of them, how many peripherals sitting on thousands of desks today have the same problem that nobody has looked at yet.
Frequently Asked Questions
What does “agentic reverse engineering” mean?
It’s the process of giving an AI agent (in this case Claude Opus 5) the firmware, the update tool, and access to the real device, then letting it iterate autonomously, analyzing the binary, testing commands, and documenting what it finds, with human oversight on any steps that modify the device.
Is it legal to do this with your own devices?
Auditing and modifying the firmware of a device you own, without distributing the manufacturer’s copyrighted firmware or violating explicit warranty terms, is a common practice within the hardware hacking community. The exact legality varies by country and device.
Do I risk bricking the device?
Yes. Reflashing firmware without the original protection scheme active can leave the device non-functional (bricked). That’s why schlarp documented the entire process before flashing anything, and still hasn’t worked up the nerve to modify the real firmware on his monitor.
Why does a webcam need a full operating system?
Because it does much more than capture video: the Insta360 Link runs embedded vision models for real-time facial tracking and gesture detection, features that require a compute stack much closer to a phone than an analog camera.
Can this method be applied to any peripheral?
In principle, yes, as long as the device has an accessible firmware update mechanism and the manufacturer publishes (even indirectly) the binary and the official update tool.
Where is the generated code and documentation?
schlarp published a GitHub repository for each device, with the generated documentation and custom update tools, validated against real hardware according to his own account.
References
- Everything I own, owned (schlarp.com): the original analysis covering all five devices, the session transcripts, and links to the GitHub repositories.
- USB Video Class (Wikipedia): specification of the extension units exposed by the UVC interface used by the Insta360 Link.
- Claude (Anthropic): official information on the Claude model family, including Opus 5.
- Reverse engineering (Wikipedia): general context on the process of analyzing software and hardware without access to the original design.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Anne Nygård en Unsplash
0 Comments