A developer bought a Plustek 8200i film scanner to digitize his late mother’s negatives, found the chipset had changed to one Linux didn’t support, and gave up for months. Then he gave Claude Code control of a Windows VM so it could run scans, capture the USB traffic, and read the hex dumps itself. Within a few hours he had his first working scan under Linux. Days later, a near-perfect driver with infrared support. He then pointed the same setup at a broken MIPI camera driver on his laptop and had kernel and libcamera patches by the end of one day.

If you run a plant with machines that speak undocumented protocols, that timeline should get your attention. Here’s what changed, and what it means for integrating equipment vendors won’t help you with.

The Machine on Your Floor That Nobody Can Talk To Anymore

Every plant has at least one. A press, a tester, a labeller that runs fine mechanically but is digitally mute. No API, no protocol spec, a chipset the vendor swapped without telling anyone, or a support contract that ended three acquisitions ago. The machine works. You just can’t get data out of it.

So you pick from three bad options: rip and replace capable equipment, buy an OEM gateway priced like it’s doing you a favour, or keep a technician transcribing readings into a spreadsheet forever. Most teams quietly choose option three and call it a process.

Christian Schaller hit the consumer version of this and published what he did about it on 15 October 2026. His write-up points at a fourth option that operations leaders wrote off years ago as too slow and too expensive to be worth costing out.

How a Stalled Scanner Project Turned Into a Working Driver in One Afternoon

The project did not stall because the model was too weak. Schaller had already shipped small Linux utilities with Claude Code, including a controller app for his Dell camera. The scanner driver was a different animal. He got nowhere for months and wrote it off.

What changed was not the prompting. It was what the agent was allowed to touch.

The breakthrough: giving the agent a controlled environment, not just better prompts

The shift came from a post on X by Tom Crider, better known as Glorious Eggroll, describing how he fixed a mouse driver by handing an AI agent full control of a Windows instance so it could capture the data it needed itself. Schaller pasted that tweet into Claude and asked it to build the same arrangement for his scanner.

It can read thousands of lines of USB capture, notice that a sequence repeats with one byte changing, and propose what that byte means. It can write the test to confirm it, and it doesn’t get bored.

That is the entire mechanism. The agent could trigger a scan against the vendor’s own Windows driver, capture the bus traffic from that run, and analyse it without anyone exporting logs or pasting hex into a chat window. He also had it write the scanning application, which he named Negative Vibes.

Reusing the harness on a second, unrelated device

The setup turned out to be portable. Schaller aimed it at the MIPI camera support on his laptop, a different device class on a different bus with a different failure mode, and simply told Claude to reuse what already existed. No rebuild, no new methodology.

One detail worth sitting with: while he had given up, someone else committed scanner support upstream to SANE. “it happens sometimes.” That is a hobbyist’s luck. Nobody is going to volunteer a driver for your 2004 labeller, which is exactly why he asked Claude to make the tooling generic and documented for other people’s hardware.

Why Protocol Decoding Is Almost Perfectly Shaped for an AI Agent

Reverse engineering undocumented hardware has a specific shape. You capture bus traffic, stare at hex dumps, form hypotheses about what each register or control transfer does, then test them one at a time. Schaller’s own summary: “None of it is conceptually hard, but it takes a lot of patience and skills.” That is exactly the kind of work humans are bad at sustaining and machines do not mind at all.

The capture-hypothesise-verify loop, step by step

The loop is simple enough to describe in four moves. Run the operation under the OS the vendor supports and record the USB traffic. Diff two captures that differ by one setting. Propose what changed and why. Write code against that theory and run it on the physical device.

It can read thousands of lines of USB capture, notice that a sequence repeats with one byte changing, and propose what that byte means. It can write the test to confirm it, and it doesn’t get bored.

Each cycle takes minutes instead of an evening, and wrong guesses cost almost nothing. That is the real change in AI reverse engineering: not smarter hypotheses, just thousands more of them, each one checked against hardware rather than argued about.

What hw-harness generalises and what it deliberately leaves to you

Schaller is clear that hw-harness was not what he used on the scanner or the MIPI camera. Those were bespoke scripts. The published project is an attempt to make that setup generic and documented so other people do not rebuild the plumbing from scratch. What it standardises is the boring part: the controlled VM, the capture tooling, the agent’s access to both.

What it does not do is decide anything. The human still picks the target, defines what “working” means, and confirms the result on real equipment. An agent will happily produce a driver that passes its own tests and fails on your machine. Physical verification is not optional, and nobody has automated it away.

Where This Pays Off in a Factory, and Where It Absolutely Doesn’t

Three legacy-integration jobs worth piloting this quarter

The pattern fits read-only data extraction from equipment that already works. Start with a bench instrument or test rig that speaks a proprietary serial or USB protocol and currently requires someone to copy numbers off a screen. You are not controlling the machine. You are listening to it, which is the lowest-risk version of this work.

Two more candidates sit in most plants:

• The old inspection camera: a 12-year-old unit that still has good optics but no driver for any modern vision pipeline. Getting frames out of it is a protocol problem, not an optics problem.
• The sensor behind a paywalled gateway: when the vendor wants 20,000 euros for a box that exposes data the device is already transmitting on the wire, decoding it yourself changes the maths considerably.

The legal, safety, and ‘someone already did it’ checks to run first

Hard stops first. Anything inside a safety interlock chain stays untouched, full stop. If reverse engineering the interface voids a warranty or breaches an active service contract, get that in writing from legal before anyone opens a capture tool. And if the protocol is genuinely encrypted rather than merely undocumented, this approach does not apply. Undocumented is a patience problem. Encrypted is a different problem entirely.

Then check whether the work already exists. Schaller finished a near-perfect driver with infrared support, then discovered someone had committed scanner support to SANE in the months he had given up: “it happens sometimes.” An hour searching upstream projects, vendor forums, and GitHub beats a week of duplicated effort.

On ROI, be honest with your finance team. You are spending days of engineer time, not weeks, against a capex replacement line or a recurring gateway licence. That is a good bet, not a guaranteed one. Some protocols will not yield, and you need to agree upfront what a failed pilot costs and when you stop.

What Comes Off Your Integration Backlog Once Decoding Gets Cheap

Look at your integration backlog and you will find items that have survived three budget cycles. Not because nobody wanted them. Because every one carried the same hidden line item: weeks of someone senior doing protocol archaeology with no guarantee of a result. At that price, a small integration never clears the bar, so it gets deferred again.

Change the cost from weeks to a day and those items stop being capital requests. They become triage decisions. You are no longer asking whether the integration is worth funding, you are asking which one to do first.

Resist the urge to turn that into a plant-wide data layer programme. Those take eighteen months and die in scope negotiation. Pick the single machine whose missing data causes the most manual work right now, and go after that one.

A two-day pilot structure for one piece of orphaned equipment

Day one is setup and capture. Your engineer stands up a VM with the vendor’s Windows software, wires in USB capture, and gives the agent control of the environment so it can run the operation and read its own traffic. The developer behind the Plustek work made the point that anyone could start from scratch, but he asked Claude to make the capture setup generic and documented it so others would not have to. Start from that rather than from nothing.

Day two is hypothesis and verification against the real machine. The agent proposes what each byte means, writes the test, and runs it. Your engineer checks the output against known-good readings from the physical equipment. Success criterion: one correct value pulled from the machine without a human reading a screen.

If that works, you have a repeatable method and a cost figure for the next twelve items. If it does not, you spent two days, not a quarter. The human sets the target and validates on real hardware. The agent absorbs the slog, and does not get bored doing it.

Source: blogs.gnome.org