Using Artificial Intelligence to reverse engineer hardware
B · Useful, limited First-hand account by Christian Schaller, a long-time Fedora and GNOME figure, of building Linux drivers with Claude Code and a capture harness; concrete and tested on real hardware, but single-unit results.
Summary based on the full text·Original: about 10 minutes to read
In short
Christian F.K. Schaller (blog, 15 October 2026) describes using Claude Code to reverse engineer hardware with no Linux support. The method: run the vendor's Windows driver in a KVM virtual machine with the device passed through, capture USB traffic from the Linux host with usbmon, repeat on Linux with the new driver, and let the agent diff the two traces. He got a near-complete film scanner driver in days and camera fixes in one day, and released the setup as hw-harness.
Key numbers
- 34.6 s vs 54.4 sfull-resolution scan time, his AI-built SANE backend vs the upstream driver
- 31.1 to 90.9frame brightness in a low-light test after the MIPI camera fixes
- about 2.7 stopscorner darkening from missing lens shading correction in libcamera's software ISP
- about 1.8 stopssensitivity lost to a too-low analogue gain cap in the kernel driver
As reported by the source.
English·Web page·opens blogs.gnome.org
What it reports
- SANE backend for the Plustek OpticFilm 8200i (Genesys GL128): colour, grey and infrared modes, 300-7200 dpi, infrared dust removal. First recognisable scan within hours. Upstream SANE added support in September 2026; his driver is faster at full resolution (34.6 s vs 54.4 s), upstream has more resolution steps.
- Negative Vibes, a GNOME app in Rust for scanning negatives, also written with Claude.
- ThinkPad X1 Carbon camera (Sony IMX471, Intel IPU7): kernel fixes for a crop bug, a wrong register width and a gain cap costing about 1.8 stops; libcamera fixes for missing lens shading (corners about 2.7 stops dark) and a white-balance bit-depth error. Brightness rose from 31.1 to 90.9; blue still about 17% short in low light.
- Patches submitted to kernel and libcamera maintainers.
- Lessons: a known-good reference capture turns "it doesn't work" into a list of differences; the agent handles the tedium; real hardware is the only judge.
How they got it
Personal projects on his own devices, with measurements from single-unit, single-frame tests.
Limits
- One unit per device; he calls the scanner comparison one data point.
- hw-harness is a generalised rewrite of bespoke scripts, not the exact tool he used.
- No time or cost accounting beyond "hours" and "days".
Why it matters for companies
The pattern generalises beyond drivers: give an agent a trusted reference behaviour and a way to capture and compare its own output, and it can grind through work that used to take weeks. Firms with legacy systems, undocumented integrations or protocol work can apply the same set-up. A human still has to own the physical test and the decision on what ships.
Summary based on the full text. Read the original for the full argument and data.Read the original on blogs.gnome.org
- Tags
- Coding agents