Using Claude Code to Reverse Engineer Hardware: A Linux Driver Workflow

Writing a driver for undocumented hardware has long meant capturing bus traffic, staring at hex dumps and testing hypotheses one by one for weeks. In a blog post on October 15, 2026, Fedora and GNOME contributor Christian Schaller describes how he used Claude Code to shrink that slog. The result: a working Linux backend for a film scanner, a scanning app, and patches that improve the camera on a ThinkPad. His post is at blogs.gnome.org, and it was discussed on Hacker News.

The reusable idea is not "ask an AI to write a driver." It is a controlled comparison: record what a working driver does, record what yours does, and let the model work from the differences. This guide walks through that method, the three projects, the numbers the author reports, and the limits he states himself.

TL;DR

The workflow: four steps from the post

According to the post, hw-harness is meant to help a Claude or Codex session by following these steps:

1. Record a reference session. Run the vendor's Windows driver in a KVM virtual machine, with the real device passed through to the guest.
2. Capture from outside the VM. Record traffic on the Linux host with usbmon. It sits below the passthrough layer, so the guest cannot see it.
3. Repeat the same operation on Linux with your own driver, and capture that the same way.
4. Diff the two traces. Both come from the same instrument, so they compare directly, and "the differences are your list of driver bugs."

For devices with no bus to tap, such as an internal MIPI camera, the harness uses Windows-side inspection: INF files, registry data, ACPI tables and device properties.

The author stresses that the approach "doesn't rely on copying any code." Instead it observes what the hardware does and extracts only configuration data from the Windows drivers, so each constant in the new driver can be traced to something recorded. Anyone doing this should still read the licence terms of the vendor driver and the law where they live; that is the author's description of his method, not legal advice.

Why AI helps here

Schaller's argument is that this kind of work is conceptually easy but laborious. A model "can read thousands of lines of USB capture, notice that a sequence repeats with one byte changing, and propose what that byte means," then write a test to confirm it, and "doesn't get bored." The human still decides what to build and checks that it works on real hardware.

He had tried before. He got "stuck and got nowhere for the longest time" and gave up for a few months. What changed was seeing a post on X by Tom Crider (Glorious Eggroll) about fixing a mouse driver with AI tooling by giving an agent full control of a Windows instance to capture data. Schaller pasted that post into Claude and asked it to help set up a Windows VM for his scanner. With the ability to run scans under Windows and capture the USB data, plus what he suspects were improvements in Claude Code, he had a first working scan within hours.

Project 1: a SANE backend for the Plustek OpticFilm 8200i

The newer 8200i uses a Genesys GL128 controller (USB 07b3:1825); the older model with the same name uses a GL845 and is already handled by SANE. The new backend supports colour, gray, infrared and colour plus infrared modes, resolutions from 300 to 7200 dpi at 8 or 16 bits per channel, dust and scratch removal from the infrared channel, and an exposure multiplier for dense negatives. It is packaged as a Fedora RPM.

There is a twist the author reports honestly: while he was away from the project, someone had already committed support for the scanner to upstream SANE (the genesys backend gained it in September 2026). He compared the two. Both resolved the same fine detail at 3600 dpi; his was faster at full resolution (34.6 seconds against 54.4) and supports infrared dust removal, while upstream offers more resolution steps. He calls these "single-unit, single-frame results" and says he expects to use upstream once it reaches parity. The value, he says, is as a proof of concept and a source of discoveries for the SANE project.

Project 2: Negative Vibes, a Rust app for scanning film

A driver is little use if scanning negatives is painful, so he had Claude write a GNOME app in Rust called Negative Vibes. It keeps the scan exactly as delivered (16-bit, linear, with the infrared plane) and applies non-destructive settings on top: density-space negative inversion with film base and dye-crosstalk correction, roll-wide settings with per-frame overrides, infrared and software dust removal, IT8 calibration through ArgyllCMS, and export to TIFF, JPEG, PNG and DNG with ICC profiles. It ships as a Flatpak with the scanner backend, tested so far on the 8200i. He notes SANE lacks a standard way to expose infrared channels, which would be needed to support other film scanners.

Project 3: fixing the MIPI camera on a ThinkPad X1 Carbon

The third project reused the harness. The camera in his Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition) uses a Sony IMX471 sensor behind an Intel IPU7, and on Linux it produced dark, vignetted images with a yellow-green cast. The fixes he lists:

Kernel (IMX471 driver)

• A crop-selection bug returned an error before storing the crop rectangle, so libcamera assumed the full pixel array.
• The test-pattern register was declared with the wrong width.
• The analogue gain cap was too low, costing about 1.8 stops of sensitivity.

libcamera software ISP

• Lens shading correction was missing entirely, leaving corners about 2.7 stops darker.
• White-balance statistics were summed at the sensor's native bit depth against an 8-bit black level, which skewed white balance and affects any RAW10 or RAW12 sensor.

In a controlled low-light test, mean frame brightness rose from 31.1 to 90.9, and the red/green and blue/green ratios moved from 0.890 and 0.672 to 1.047 and 0.823, close to a USB webcam reference. Blue is still about 17% short in low light, which he attributes to grey-world white balance. He submitted the kernel patches to the driver maintainer, and the libcamera patches are being reviewed for submission upstream. A USB camera connected at the same time gave Claude a reference capture, which he calls critical.

What he says he learned

• Reference captures are a big step. Comparing a known-good trace against a failing one turns "it doesn't work" into a concrete list of differences.
• The AI is good at the tedium: decoding captures, writing probes and cross-checking constants. The human still holds the physical hardware.
• Real hardware is the only judge. Every claim was checked on the actual scanner or laptop.

His closing note is cautious: he is not claiming the scans or camera are perfect, only that the work "moved the needle despite lacking the in-depth knowledge for this type of work."

What Hacker News commenters added

The thread was small when we read it. One commenter said they had just pointed Claude at their work laptop's MIPI driver (comment by XorNot, item 50104379). Another reported finishing custom firmware for an old MP3 player by exploring and reverse engineering it over a USB connection (tinchos, item 50104462). A third argued people should aim the same technique at more valuable closed hardware and software, claiming Claude had already helped with projects such as Nvidia GPUs on Intel Macs and pairing an Apple Watch with Android (rvz, item 50104602); we have not verified those claims. Another asked for "smart" TVs to be tackled to remove ads (xnx, item 50104663). These are commenters' reports, not verified results.

How to try the method safely

1. Pick hardware that has a Windows driver and a Linux gap, and that you own.
2. Set up KVM with USB passthrough, then capture on the host with usbmon so the guest cannot interfere.
3. Give the agent the reference trace and your failing trace, and ask for a ranked list of differences rather than a finished driver.
4. Have it write small probes that test one hypothesis at a time, and run them yourself on the real device.
5. Keep the agent inside a VM or container, since driver work involves root, kernel modules and raw device access. A runtime policy layer helps: AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions. Our guide to Capsem VM sandboxes for coding agents covers sandboxing options.
6. Upstream your fixes, and check the upstream project first; the SANE support appeared while the author was away.

Limits and legal questions

• Single-device results do not show a driver works across hardware revisions.
• Upstream already had support, so this is a proof of concept for the scanner, though the camera fixes are new patches under review. Check the SANE backends project for the current scanner status and libcamera for the camera pipeline before relying on either.
• Reverse engineering rules vary by country and by the vendor's licence for its driver.
• Kernel patches need maintainers to review them, and AI-written code policies differ between projects; see our post on NetBSD's AI-free commit rules.

What this means if you build with coding agents

The pattern generalises beyond drivers: give the agent an oracle. A reference trace, a passing test suite or a known-good output turns open-ended guessing into a comparison problem the model is good at. For the wider shift in how engineers use agents on long tasks, see our Claude Code parallel sessions guide and the Superpowers agentic skills framework.

Related reading

• Capsem VM sandboxes for coding agents
• How AI agents decompile games: a workflow and its limits
• NetBSD's AI-free commit guidelines
• Claude Code desktop parallel sessions
• Superpowers agentic skills framework
• Solidcraft: open-source Rust CAD with MCP for agents

Details are accurate as of October 15, 2026, from the author's blog post; results are his own, single-device measurements.