Your Dead Printer Isn't Dead. It's Just Undocumented.

Everyone has one. The printer in the closet that works perfectly but has no macOS driver. The scanner from a company that went under in 2019. The audio interface whose vendor shipped its last update during the Obama administration. The hardware is fine. The software support is gone, and that’s the end of it.

Except a developer just took a Windows-only HP printer, captured its USB traffic, handed the logs to Claude, and got working macOS code out the other side. That closet full of dead electronics suddenly looks different.

What actually happened

The setup is boring, which is the point. HP never shipped a macOS driver for this model. The user has a Mac. Normally you have two options: throw the printer out, or keep a Windows laptop alive as a very expensive print server.

They picked a third. They ran the printer from Windows, captured the raw USB traffic going out to the device, and fed the whole dump to an AI with roughly this instruction: figure out what protocol this is, then write code that speaks it from macOS.

The whole trick is packet capture. You don’t need documentation if you have a recording of the actual conversation. Press print, watch which bytes go out, watch what the printer says back. Do that enough times and structure starts to surface — command boundaries, headers, payloads, checksums.

Humans do this all the time. It takes days or weeks. You stare at hex, hunt for repetition, guess where the header ends, form a hypothesis, fire it at real hardware, and start over when the printer does nothing. It is genuinely tedious work.

Why this is exactly what LLMs are good at

Reverse engineering is a suspiciously good fit for a language model, for three reasons.

Pattern recognition. Eighty percent of protocol reversing is asking “what repeats here?” A human staring at hex dumps gets fatigued and starts missing things after an hour. To a model, a byte sequence is just another token array. It reads all of it, every time, without getting bored.

Prior knowledge. No manufacturer invents a printer protocol from scratch. It’s almost always PCL, PostScript, ZPL, or something layered on IEEE 1284 with vendor-specific extensions bolted on. A model that has absorbed a large chunk of the world’s technical documentation doesn’t start from a blank page — it starts from “this looks like PCL with a custom escape sequence in the middle,” which collapses the search space immediately.

Cheap iteration. The hypothesize-code-test-fail loop is what kills human reverse engineers. It’s demoralizing. For an AI it’s just the next prompt. Printer didn’t respond? Read the log, form a different theory, rewrite, try again. No ego, no Sunday-afternoon exhaustion.

The kernel objection, and why it’s half wrong

This is where the Hacker News thread split. Drivers aren’t ordinary application code. A bug in your web service returns a 500. A bug in system-level code does other things.

Fair — but let’s correct the framing first. Writing a macOS printer driver in 2026 does not mean writing a kernel module. Apple effectively killed kernel extensions years ago. Device access now runs through DriverKit, or userspace libusb, or a CUPS filter. This code lives in user space. A crash kills a process, not the machine. “They let an AI write kernel code” is a more exciting sentence than the truth.

That said, the risk isn’t zero. USB communication means firing raw commands at physical hardware. A malformed byte sequence can wedge a device’s firmware into a strange state, and in the worst case touch the firmware region and brick it outright. With a printer, your downside is one printer. Apply the same technique to a storage controller or a network appliance and the math changes.

The deeper problem is verification. What does it mean to say the AI-written driver works? It means a test page came out. Does color mode work? Duplex? What happens on a paper jam — does the error path do anything sane? What about waking from sleep? Human-written drivers fail at exactly these edges. A protocol inferred from packet captures has a worse problem: there’s no spec to check yourself against. Behavior you never captured effectively doesn’t exist. You can’t audit for gaps when you don’t have the map.

The thing that changed is the price

What makes this notable isn’t difficulty. This was always technically possible. It’s the exact work the Linux community has been doing for thirty-plus years, mostly for free, mostly unthanked. The barrier was never capability. It was labor cost.

Burning three weekends to resurrect one printer is not a rational trade. So most abandoned hardware just got abandoned. Popular models attracted enough community energy to survive; everything else quietly became e-waste. The determining factor was never whether the device was worth saving — it was whether enough people owned it to justify someone’s unpaid weekend.

AI moves that line. When three weekends becomes one evening, the long tail becomes reachable. Niche models. Low-volume industrial gear. Products from companies that no longer exist. Drivers nobody wrote because the addressable market was forty people can now be written by one of those forty people, for themselves.

There’s an environmental argument underneath. Perfectly functional hardware getting landfilled because a software team moved on is a real waste, and manufacturers have no commercial incentive to fix it — they’d rather sell you the new one. If individuals can fill that gap cheaply, hardware lifespans stretch.

Where the law sits

Worth addressing, because someone always asks.

Reverse engineering for interoperability is broadly protected in most Western jurisdictions. The US DMCA contains an interoperability exemption. The EU Software Directive explicitly permits decompilation for the purpose of building compatible programs. “I bought this printer and I want it to work with my computer” sits comfortably inside that.

The gray areas are the usual ones. Did you decompile the vendor’s driver binary and crib from it? Did the firmware have signature verification you had to route around — because circumvention is a separate offense from reversing? Are you publishing the result? There’s real distance between one person making their own hardware work and pushing a driver to a public repo where thousands install it.

Using AI doesn’t change the legal analysis. What it might change is the volume. If this becomes routine rather than heroic, expect manufacturers to notice — more device attestation, signed protocol handshakes, harder-to-capture encrypted USB channels. The lock gets better when picking it gets easier.

The takeaway

This isn’t a new magic power. It’s an old capability that got cheap, and cheap changes behavior in ways that capability alone never did. The blast radius is wider than printers: orphaned peripherals, products from dead companies, legacy industrial systems nobody has maintained since the original engineer retired.

It also means a lot more unverified low-level code in the world. For a printer, worst case is wasted paper. Move the same approach to medical devices or factory equipment and the calculation looks entirely different. Works and safe are not synonyms, and the gap between them is exactly where the interesting failures live.

So: what’s in your closet that’s only dead because nobody wrote the software? And how far would you go to bring it back?