I was able to (through heavy Claude use) successfully reverse engineer a golf cart motor controller that is programmable over USB, but only was supported by a Windows application. Claude walked me through using ILSpy on the .NET assembly, using Wireshark to capture the protocol over USB, and to completely map out all of the functionality in the Windows application. The output was a portable C library and CLI program which, so far, has worked well.
I consider myself kind of an AI detractor but even I'll admit that the tool allowed me to do something it would have taken weeks-to-months to learn to do the hard way.
And with the Linux Kernel being friendly to both LLM usage and a modern language, for some of us who don't know C, a huge barrier is lifted from being able to write device drivers.
Not a successful anecdote, but I have a Windows Hello compatible Kengsington fingerprint reader, and for some time I wanted to write drivers for Linux. Even without using C, it would have been a huge undertaking only to fail in the end; because Claude did much of the research and concluded that the device wouldn't work on Linux (can't remember why but it made sense). Then it suggested what could work.
Back in the day when dial-up modems were a "significant" market, the concept of "WinModems" came around. Minimum hardware, maximum software. If the sensor is good enough to actually work though, it probably won't be long before an agent can implement the driver, if it can't already.
LLMs are good at producing what they/the public know.
In this case:
LLMs know the USB Spec very well.
LLMs know how to read raw packet dumps.
LLMs know how to convert a packet dump to USB spec
LLMs know how to write code to generate USB packets from the spec.
LLMs are also VERY good at transliteration, i.e., converting known-good Python to Rust.
Basically, If you have a well-documented problem, the LLM is a shortcut to learning it yourself. LLMs fail when you have a novel or poorly documented problem. They also fail when you provide the LLM with terrible context or too much context.
IMO it's because they don't get burnt out by a lack of results.
After 5-6 consecutive approaches fail, I need a reason to think the next one might work out to stay motivated.
Claude will keep burning credits trying new approaches until something sticks. That's a huge advantage in a field where most of the things you try don't go anywhere.
LLMs seem to be trained to work very well against a goal, especially one it can verify against. I guess because it can easily know if it passed or failed, va other tasks where good/bad output is subjective
To some degree. But esp for drivers, you still need to know when they go wrong, and steer them right, or your code will either just not work or be an unmaintainable, not-upstreamable mess.
I don't think they're any more skilled at it than someone who knows how to reverse engineer stuff... But it is definitely a place where AI is amazing because reverse engineering is usually extremely time consuming and tedious. AI doesn't care about that.
It also has the benefit that it doesn't usually matter too much if it gets minor details wrong. It's definitely one of the areas - like hacking - where it's a) tedious and b) insensitive to mistakes where AI absolutely shines.
Had a similar experience getting a niche app running under wine. The bot had to bring in a different open source renderer, patch dlls, adapt a mapping tool from a different chip architecture to partly map and modify the binary, crazy stuff. Alternatives exist but are expensive, this got it working in an hour when doing it myself would probably be 2 weeks.
Ditto (except not being an AI detractor): I used Claude and Codex to reverse engineer the proprietary protocol for controlling Devialet amplifiers and then build an iOS controller app to replace the manufacturer's abandoned official app.
The whole thing took about a day, spread out over a week or so. Without AI, I wouldn't have even started the project, because I couldn't spare the time it would have taken.
Are we either in a dangerous time where we'll run out of people that have weeks to months, and the resolution/boredom/ability to figure this sort of thing out?
Or are we in a really cool time where we've solved everything so much so many times we can focus on other things?
Tertiary question: If answer two, what the fuck is that?
Unfortunately this is a very misleading article and headline. I don't doubt the end result - it's useful that it works, but it's not "natively" and, unlike what some people assume, Claude didn't write a driver. It basically used HP's existing proprietary driver in a Linux VM on macOS, and just bridged that to macOS.
It also requires a root launcher that runs code from the user ~/.hp1008 dir, so security is weakened.
It's strange, because I have zero doubt in my mind that Claude could 100% genuinely reimplement the driver and port it to actually natively run on macOS, were it prompted to that way.
Wouldn't it have made more sense for Claude to suggest using the existing Linux-Airprint-VM project/product that already does this exact thing?
There's even a zero-install method via https://printervention.app where it runs that Linux VM isolated inside a WebUSB-capable browser. That website itself was posted right here on HN not too long ago.
I get that the LLM code assistant software prefers writing stuff, but constantly re-writing the same solution seems a bit inefficient.
So the critique from the other story holds true - it really is just running the Linux driver inside docker, and (perhaps) dressing it up as something more - though I note the claim on this page is walked back from the original 'writing the driver'. On the other hand, it really did get him printing from his Mac, so in this new LLM results based world we live in it did its job admirably.
Somehow, I'm not exactly sure why, I got creeped out by Claude's finishing line:
> Thanks for being such a game debugging partner through all the test pages. Enjoy printing, you and the family.
Maybe it's because my own LLM usage is very "Question > Answer" or "Do this > Agent does that" and I never say "Wow, that's crazy it works, thank you!" at the end or such, so I don't see that sort of things, but if I saw that regularly I'd turn me off so badly from using LLMs. I'm not exactly sure where this feeling is coming from though, it's relatively innocent but just feels so inauthentic, I'm guessing because it's simply a machine.
The way that you talk to it influences the way that it responds to you and it is not subtle. I don't want to hitch on to the "it's just really complicated autocomplete" bandwagon, but this is one of the ways that it does feel like that.
With voice dictation (wispr flow), I find it easier for me to talk naturally as if I'm talking to a friend. I'll sometimes give lengthy notes on context for a project, like why I want to do it, e.g. something for my wife to use.
So I find it common (and fine, I suppose) for Claude to reply using that context. "Let me know what your wife thinks of the app" etc.
Reminded me of when I had a Teletype ASR33 on AirPrint (https://github.com/hughpyle/ASR33/tree/master/cups). With LLMs that would have taken a half hour. It would have maybe been less fun? but there's a lot of time faffing around on PPD that I'll never get back.
Had a similar experience. I bought an ePaper display and a Pi 4 to run a calendar widget on. I got stuck because the open source project I was building off expected the previous generation of ePaper display, and the firmware had changed completely. I found the new firmware examples, but got stuck trying to get it to work. With Claude assisting we banged it out in two sessions of about 3 hours each.
codeberg.org/mjmvisser/infoframe if anyone’s interested.
I did a similar project for another make of printer, but used DS Flash and GPT-5.6-Sol, so it was effectively free ($2-$3 of Flash and maybe 5% of a monthly Max sub, so $10?)
This is awesome. I take it your plans for the next weekend include actually cleanrooming the driver so you can skip running it in a linux container? =P
Claude is great at that. I have a usb keypad with no linux version of the app to program it. Since its just a vial/qmk based, claude built me a linux version in qt/python.
Claude can do Linux drivers too. A friend bought a second-hand Intel Mac, installed Linux, found that a lot of the hardware didn’t work. It wasn’t very hard to get Claude to write those drivers.
If this could all finally solve, once and for all, printing and scanning issues it'd be lovely (btw there are entire businesses who's only raison d'etre is "installing printers at clients and fixing them when they stop printing").
But of course it's hard not to both marvel and lament (at) the fact that in the mid-1990s (so yup 30 years ago) I could:
nc 192.168.1.150 9100 < tiger.ps
And the native PostScript printer (also an HP laser btw: a LaserJet) would just start printing.
I know, I know, about garbled print jobs, pages of codes being printed, etc.
But still: it's hard to not at least wonder if some things haven't been lost. For a start printers with their own IP addresses were sweet (instead of a USB cable and, now, people setting up, say, a Pi just to expose a LAN IP for/to their printer). Then of course another talk could be had about the "quality" of modern day HP laser printers compared to what you'd get int the nineties.
I've always thought USB-only made no sense on a printer. If there was one device in your house that multiple computers (and phones, don't forget) would want to use simultaneously, it's a printer. I'll only buy a printer that has its own built in network connectivity. Infuriating to have to stick a Pi onto your printer just so it can do what should be basic, table-stakes functionality.
I was able to (through heavy Claude use) successfully reverse engineer a golf cart motor controller that is programmable over USB, but only was supported by a Windows application. Claude walked me through using ILSpy on the .NET assembly, using Wireshark to capture the protocol over USB, and to completely map out all of the functionality in the Windows application. The output was a portable C library and CLI program which, so far, has worked well.
I consider myself kind of an AI detractor but even I'll admit that the tool allowed me to do something it would have taken weeks-to-months to learn to do the hard way.
Had a similar thought today - maybe we could finally get Linux drivers for more HW...
And with the Linux Kernel being friendly to both LLM usage and a modern language, for some of us who don't know C, a huge barrier is lifted from being able to write device drivers.
Not a successful anecdote, but I have a Windows Hello compatible Kengsington fingerprint reader, and for some time I wanted to write drivers for Linux. Even without using C, it would have been a huge undertaking only to fail in the end; because Claude did much of the research and concluded that the device wouldn't work on Linux (can't remember why but it made sense). Then it suggested what could work.
Back in the day when dial-up modems were a "significant" market, the concept of "WinModems" came around. Minimum hardware, maximum software. If the sensor is good enough to actually work though, it probably won't be long before an agent can implement the driver, if it can't already.
I don't understand the technology enough to see why, but LLMs seem unusually skilled at reverse engineering proprietary software.
LLMs are good at producing what they/the public know.
In this case:
LLMs are also VERY good at transliteration, i.e., converting known-good Python to Rust.Basically, If you have a well-documented problem, the LLM is a shortcut to learning it yourself. LLMs fail when you have a novel or poorly documented problem. They also fail when you provide the LLM with terrible context or too much context.
IMO it's because they don't get burnt out by a lack of results.
After 5-6 consecutive approaches fail, I need a reason to think the next one might work out to stay motivated.
Claude will keep burning credits trying new approaches until something sticks. That's a huge advantage in a field where most of the things you try don't go anywhere.
LLMs seem to be trained to work very well against a goal, especially one it can verify against. I guess because it can easily know if it passed or failed, va other tasks where good/bad output is subjective
To some degree. But esp for drivers, you still need to know when they go wrong, and steer them right, or your code will either just not work or be an unmaintainable, not-upstreamable mess.
I don't think they're any more skilled at it than someone who knows how to reverse engineer stuff... But it is definitely a place where AI is amazing because reverse engineering is usually extremely time consuming and tedious. AI doesn't care about that.
It also has the benefit that it doesn't usually matter too much if it gets minor details wrong. It's definitely one of the areas - like hacking - where it's a) tedious and b) insensitive to mistakes where AI absolutely shines.
Had a similar experience getting a niche app running under wine. The bot had to bring in a different open source renderer, patch dlls, adapt a mapping tool from a different chip architecture to partly map and modify the binary, crazy stuff. Alternatives exist but are expensive, this got it working in an hour when doing it myself would probably be 2 weeks.
Ditto (except not being an AI detractor): I used Claude and Codex to reverse engineer the proprietary protocol for controlling Devialet amplifiers and then build an iOS controller app to replace the manufacturer's abandoned official app.
The whole thing took about a day, spread out over a week or so. Without AI, I wouldn't have even started the project, because I couldn't spare the time it would have taken.
Are we either in a dangerous time where we'll run out of people that have weeks to months, and the resolution/boredom/ability to figure this sort of thing out?
Or are we in a really cool time where we've solved everything so much so many times we can focus on other things?
Tertiary question: If answer two, what the fuck is that?
I've had good luck using AI to reverse-engineer Bluetooth comms for "smart" products with shitty apps.
Unfortunately this is a very misleading article and headline. I don't doubt the end result - it's useful that it works, but it's not "natively" and, unlike what some people assume, Claude didn't write a driver. It basically used HP's existing proprietary driver in a Linux VM on macOS, and just bridged that to macOS.
It also requires a root launcher that runs code from the user ~/.hp1008 dir, so security is weakened.
It's strange, because I have zero doubt in my mind that Claude could 100% genuinely reimplement the driver and port it to actually natively run on macOS, were it prompted to that way.
For the amount of electricity wasted by the LLM in the data center it would have been more efficient to buy a new printer that works out of the box.
Redditors actually believe this
Also, they seem to care about wasting electricity but doesn’t bat an eye of discarding a perfectly fine printer.
yup, clocked this in just the first few lines of the transcript.
I am sooo tired of this AI generated slop.
Wouldn't it have made more sense for Claude to suggest using the existing Linux-Airprint-VM project/product that already does this exact thing?
There's even a zero-install method via https://printervention.app where it runs that Linux VM isolated inside a WebUSB-capable browser. That website itself was posted right here on HN not too long ago.
I get that the LLM code assistant software prefers writing stuff, but constantly re-writing the same solution seems a bit inefficient.
But it wouldn’t have used so many tokens ;)
So the critique from the other story holds true - it really is just running the Linux driver inside docker, and (perhaps) dressing it up as something more - though I note the claim on this page is walked back from the original 'writing the driver'. On the other hand, it really did get him printing from his Mac, so in this new LLM results based world we live in it did its job admirably.
Somehow, I'm not exactly sure why, I got creeped out by Claude's finishing line:
> Thanks for being such a game debugging partner through all the test pages. Enjoy printing, you and the family.
Maybe it's because my own LLM usage is very "Question > Answer" or "Do this > Agent does that" and I never say "Wow, that's crazy it works, thank you!" at the end or such, so I don't see that sort of things, but if I saw that regularly I'd turn me off so badly from using LLMs. I'm not exactly sure where this feeling is coming from though, it's relatively innocent but just feels so inauthentic, I'm guessing because it's simply a machine.
The way that you talk to it influences the way that it responds to you and it is not subtle. I don't want to hitch on to the "it's just really complicated autocomplete" bandwagon, but this is one of the ways that it does feel like that.
With voice dictation (wispr flow), I find it easier for me to talk naturally as if I'm talking to a friend. I'll sometimes give lengthy notes on context for a project, like why I want to do it, e.g. something for my wife to use.
So I find it common (and fine, I suppose) for Claude to reply using that context. "Let me know what your wife thinks of the app" etc.
> Leave my family out of this!
https://peepshow.gifglobe.com/scene/?id=HAGUFD3NuzO4
I'd be willing to bet somewhere in that conversation he said family printer or something.
Seems an oddly specific thing to hone in on otherwise.
That's funny, 'Ctrl + F' for 'family' returns a lot of uses of that word in different contexts, so I guess it must have scored heavy eh
Reminded me of when I had a Teletype ASR33 on AirPrint (https://github.com/hughpyle/ASR33/tree/master/cups). With LLMs that would have taken a half hour. It would have maybe been less fun? but there's a lot of time faffing around on PPD that I'll never get back.
Claude Code is extremely "honest", and uses that word 10 times in that short transcript.
I find it uses “faithful” an awful lot. But it comes in waves - not at all for a few days and then 10 times in an hour.
Had a similar experience. I bought an ePaper display and a Pi 4 to run a calendar widget on. I got stuck because the open source project I was building off expected the previous generation of ePaper display, and the firmware had changed completely. I found the new firmware examples, but got stuck trying to get it to work. With Claude assisting we banged it out in two sessions of about 3 hours each.
codeberg.org/mjmvisser/infoframe if anyone’s interested.
my Brother dcp-t230 also doesn't have macos drivers and it's a usb only printer. if i ever get some tokens to burn, i would try the same.
I did a similar project for another make of printer, but used DS Flash and GPT-5.6-Sol, so it was effectively free ($2-$3 of Flash and maybe 5% of a monthly Max sub, so $10?)
i have a label printer that's in the same boat. I wonder how many tokens this convo was
It didn't write a driver. It used a linux driver. You don't need an LLM.
> my Brother dcp-t230 also doesn't have macos drivers and it's a usb only printer.
Same thing here brother: DCP-L2510D (laser printer + scanner).
Wife is on MacOS and cannot print/scan from there, so I'm the scanman.
I don't see anywhere in the post or the repo how much it cost him to do this in tokens.
someone already burned those tokens for you: https://github.com/farafonoff/Brother-DCP-T230-MacOS-driver
This is awesome. I take it your plans for the next weekend include actually cleanrooming the driver so you can skip running it in a linux container? =P
bro is going to need opus and a couple thousand dollars in tokens for something that _may_ work.
Claude is great at that. I have a usb keypad with no linux version of the app to program it. Since its just a vial/qmk based, claude built me a linux version in qt/python.
Claude can do Linux drivers too. A friend bought a second-hand Intel Mac, installed Linux, found that a lot of the hardware didn’t work. It wasn’t very hard to get Claude to write those drivers.
If this could all finally solve, once and for all, printing and scanning issues it'd be lovely (btw there are entire businesses who's only raison d'etre is "installing printers at clients and fixing them when they stop printing").
But of course it's hard not to both marvel and lament (at) the fact that in the mid-1990s (so yup 30 years ago) I could:
And the native PostScript printer (also an HP laser btw: a LaserJet) would just start printing.I know, I know, about garbled print jobs, pages of codes being printed, etc.
But still: it's hard to not at least wonder if some things haven't been lost. For a start printers with their own IP addresses were sweet (instead of a USB cable and, now, people setting up, say, a Pi just to expose a LAN IP for/to their printer). Then of course another talk could be had about the "quality" of modern day HP laser printers compared to what you'd get int the nineties.
I was digging into the history of PostScript engines inside laser printers and Adobe made tons of royalty money off of that for quite a long time.
That mid-1990s postscript, networked printer when new cost as much as a small car! The HP Laser 1000 was like $250 tops new.
I've always thought USB-only made no sense on a printer. If there was one device in your house that multiple computers (and phones, don't forget) would want to use simultaneously, it's a printer. I'll only buy a printer that has its own built in network connectivity. Infuriating to have to stick a Pi onto your printer just so it can do what should be basic, table-stakes functionality.
A usb controller is way less expensive than something that can run a TCP stack and the associated software.
Notably done on Opus 4.8.
Doesn’t every printer work with CUPS?
[dupe] Discussion, including activity from the dev https://news.ycombinator.com/item?id=49344643
See also: https://news.ycombinator.com/item?id=49344643
güzel bir çalışma olmuş