Claude Opus 5 Finds Security Flaws in 5 Peripherals in 13 Hours

⏱️ Lectura: 11 min

A developer known as schlarp documented how he used thirteen hours of effective work from Claude Opus 5 and ninety-eight of his own prompts to perform AI-assisted reverse engineering on five desktop peripherals, over two weeks of free evenings. The result: a webcam whose recording light turns off without stopping the camera, a monitor that accepts firmware with no signature at all, a microphone with a plain-text command console, and a studio light that accepts memory writes from anyone on the same WiFi network.

📑 En este artículo

1. TL;DR
2. What happened: AI-assisted reverse engineering on five peripherals
3. The method: a clear objective and letting the agent iterate
4. Technical details: webcam, monitor, and their real protections
5. How to try it: agentic reverse engineering step by step
6. Impact and analysis: what this means for your peripherals’ security
7. What’s next
8. Frequently Asked Questions
   1. Is it legal to reverse engineer a device you own?
   2. What AI model did the author of the experiment use?
   3. Why doesn’t an MD5 hash protect the firmware?
   4. What is an extension unit (XU) in USB Video Class?
   5. Can I permanently turn off a webcam’s LED without AI tools?
   6. Do these findings apply to all models from the same manufacturer?
9. References

The experiment is not an attack on third parties: it’s an audit of his own devices, something that until recently required weeks of manual work with a disassembler.

TL;DR

• Claude Opus 5 reverse-engineered 5 peripherals in 13 hours of work and 98 prompts from the author.
• The Insta360 Link webcam took 3.7 hours and 33 prompts; its firmware only validates an MD5 hash, with no signature.
• The agent disabled the webcam’s recording LED without stopping the camera, by editing the firmware’s pattern table.
• The ASUS ROG Swift PG42UQ monitor took 1.2 hours and 13 prompts; it updates firmware over I2C with a simple checksum.
• According to the author, a microphone exposed a plain-text command shell accessible from the host.
• A studio light (‘key light’) accepts memory writes from any device on the same WiFi network.
• All the generated code was published in GitHub repositories, validated against real hardware.

What happened: AI-assisted reverse engineering on five peripherals

Over two weeks of free evenings, the author took five devices he already had at home (a webcam, a monitor, a microphone, a studio light, and a fifth peripheral) and gave Claude Opus 5 the official firmware, the manufacturer’s update utility, and read-only access to the device connected over USB. The instruction was always similar: document the update format, reimplement the flashing tool, evaluate the protocol’s security (checksums, signatures, secure boot), and find any hidden or debug functionality.

The most cited result is the Insta360 Link webcam: under the housing runs a full real-time operating system (ThreadX, by Ambarella), with embedded vision models for facial tracking and gestures. That same control channel made it possible to turn off the activity LED without stopping recording, something similar to what in 2013 required months of manual work in the iSeeYou exploit against the MacBook webcam.

The method: a clear objective and letting the agent iterate

The key to the process wasn’t a sophisticated prompt, but an explicit and verifiable one. The author gave Claude Opus 5 a directory with the firmware and the update utility, along with a list of concrete goals:

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
* implement our own update utility
* determine the security properties of the update protocol, including
  checksums, signature validation, secure boot
* use static and dynamic analysis to determine all protocol surfaces and
  completely enumerate functionality
* find any hidden or debug functionality in the product and how to access it

With that framework, the agent combined static analysis of the firmware binary with dynamic analysis against the real hardware connected over USB, in non-destructive mode. Peripherals turned out to be ideal candidates for this kind of work: they’re small computers with a data connection to the host and, almost always, their own firmware update mechanism, so the agent always has something to iterate against.

Technical details: webcam, monitor, and their real protections

On the Insta360 Link, the USB Video Class interface exposes an “extension unit” (XU) command that puts the device into mass storage mode. From there, a prepared firmware update can be transferred to the internal FAT filesystem, which the device applies only on reboot. But there’s a second channel, over the USB vendor class, that exposes arbitrary file read and write plus a reset command: that’s enough to fully reflash the device without any user intervention. The only integrity protection is an MD5 hash appended to the end of the file, with no cryptographic signature.

That same firmware stores a table of LED “patterns” that defines color and blinking based on the device’s state. The agent wrote a tool that erases the entry corresponding to “recording,” recalculates the MD5 hash, and flashes the result. After the test, the green recording LED stopped lighting up, although the Insta360’s gimbal still lowers when not recording, so the concealment isn’t complete.

The ASUS ROG Swift PG42UQ monitor turned out to be even more open: it updates its firmware over I2C via USB with a two-slot scheme (A/B) and a simple checksum, with no other protection. The author’s original goal was to disable the “pixel cleaning” pop-up warning that the monitor shows every eight hours of use, with no native way to turn it off. Claude found the exact area of the firmware to patch to remove that feature, although the author still isn’t confident enough to flash the real monitor given its cost.

The following table summarizes the effort and main finding for the two devices with public data:

Device	Attack vector	Firmware protection	Main finding
Insta360 Link (webcam)	XU command (USB Video Class) + file access via USB vendor class	Appended MD5 hash, no signature	Recording LED can be disabled without stopping the camera
ASUS ROG Swift PG42UQ (monitor)	I2C over USB, A/B scheme	Simple checksum, no signature	“Pixel cleaning” warning is patchable; firmware fully rewritable

How to try it: agentic reverse engineering step by step

The flow the author followed is reproducible with any peripheral you have on hand, as long as you respect the “don’t mutate” limit on the device until you confirm what each command does. The general steps:

1. Download the official firmware and the manufacturer’s update utility (usually a Windows or macOS installer that can be unpacked).
2. Connect the real device to allow dynamic analysis, without yet running any operation that writes to the firmware.
3. Give the agent an explicit and verifiable objective, like the prompt quoted above, in a reverse engineering environment (disassembler, Wireshark/USBPcap, a Python interpreter).
4. Let the agent iterate: static analysis of the binary, dynamic analysis against the hardware, and cross-checking between both to validate hypotheses.
5. Document the protocol found in a repository and, if applicable, write your own update utility.

A simplified example of what a USB control transfer looks like to talk to the extension unit of a UVC webcam, in Python with pyusb:

import usb.core

VENDOR_ID = 0x2E1A     # Insta360 (illustrative example)
PRODUCT_ID = 0x0004    # Link
XU_UNIT_ID = 0x03
XU_SELECTOR_MODE = 0x01

dev = usb.core.find(idVendor=VENDOR_ID, idProduct=PRODUCT_ID)
if dev is None:
    raise SystemExit("device not found")

# bmRequestType, bRequest, wValue, wIndex, data
dev.ctrl_transfer(
    0x21, 0x01,
    (XU_SELECTOR_MODE << 8),
    (XU_UNIT_ID << 8) | 0x00,
    bytes([0x01])  # enable mass storage mode
)

This snippet illustrates the general pattern (control transfer to a UVC extension unit), not the exact code published by the author. The real code, validated against hardware, is in the GitHub repositories linked from his blog.

💡 Tip: Always start in read-only mode. Documenting the protocol before writing anything prevents turning your peripheral into a brick from a misinterpreted command.

Impact and analysis: what this means for your peripherals’ security

The pattern that repeats across the five devices is the same: integrity protection, not authenticity protection. An MD5 hash or a simple checksum confirm that the firmware wasn’t corrupted in transit, but they don’t confirm that the manufacturer generated it. Anyone with the documented format can build a valid image.

This diagram summarizes the flow the author used on each device:

flowchart TD
A["Official firmware and update utility"] --> B["Claude Opus 5 (agent)"]
C["Device connected via USB"] --> B
B --> D["Static and dynamic analysis"]
D --> E["Documented update protocol"]
D --> F["Vulnerabilities and hidden functions"]
E --> G["Custom update utility"]
F --> G

The most sensitive part, according to the author’s own summary, is the studio light: it accepts memory writes from any device on the same WiFi network, without authentication. Unlike the webcam or the monitor, which require physical USB access, that peripheral exposes its attack surface to the entire local network.

⚠️ Heads up: If a home network peripheral accepts memory commands without authentication, any compromised device on your WiFi (a smart TV, a smart plug) is a potential entry point.

This doesn’t mean these manufacturers are particularly careless: it’s the usual standard in consumer peripherals, where the cost of implementing secure boot and cryptographic signing rarely justifies itself against the product’s price. What changed isn’t the attack surface, but the cost of finding it: documenting an update protocol by hand can take weeks; with an agent iterating against real hardware, the author did it in hours.

What’s next

The author plans to publish additional findings as he analyzes more devices, and he’s already said he’ll try flashing the monitor’s modified firmware once he feels more confident about the process. Each repository remains as public documentation and as a basis for other users to replicate or correct the work against their own hardware.

For the industry, the case is one more sign that AI-assisted reverse engineering drastically lowers the barrier to entry: what once required specialized embedded firmware expertise is now accessible to any developer with curiosity and a free weekend.

📖 Summary on Telegram: View summary

Try it yourself: if you have a USB peripheral with firmware updates, start by unpacking the manufacturer’s official installer and ask an agent to document the format before writing anything.

Frequently Asked Questions

Is it legal to reverse engineer a device you own?

Yes, in most jurisdictions auditing a device you own for personal research purposes is legal. Legal risk arises if you distribute copyright-protected firmware or bypass a protection mechanism for commercial purposes.

What AI model did the author of the experiment use?

Claude Opus 5, from Anthropic, run inside a reverse engineering environment with access to the firmware, the manufacturer’s update utility, and the device connected over USB in non-destructive mode.

Why doesn’t an MD5 hash protect the firmware?

MD5 detects accidental corruption, it doesn’t verify who generated the file. Without a cryptographic signature validated against a manufacturer’s public key, anyone who knows the format can build an image that passes verification.

What is an extension unit (XU) in USB Video Class?

It’s a standard mechanism in the UVC specification that lets a manufacturer expose additional proprietary commands, outside the standard video controls, typically for configuration or debugging functions.

Can I permanently turn off a webcam’s LED without AI tools?

It’s possible in theory with manual firmware reverse engineering, but documenting the update protocol and finding the LED pattern table by hand usually takes weeks, not hours.

Do these findings apply to all models from the same manufacturer?

Not necessarily. The analysis was done on specific units (Insta360 Link, ASUS ROG Swift PG42UQ) and the protocol can vary between generations or models from the same manufacturer.

References

• Everything I own, owned: schlarp’s original article with the full technical detail and the GitHub repositories for each device.
• USENIX Security: the academic venue where the original iSeeYou exploit against the MacBook webcam LED was published.
• Display Data Channel (DDC/CI) on Wikipedia: explains the control channel that monitors expose over the video cable.
• Ambarella: manufacturer of the system-on-chip and the ThreadX platform that runs inside the Insta360 Link webcam.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Michael Dziedzic en Unsplash