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.
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.
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
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.
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.
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?)
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.
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.
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've had good luck using AI to reverse-engineer Bluetooth comms for "smart" products with shitty apps.
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
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.
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.
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
> Leave my family out of this!
https://peepshow.gifglobe.com/scene/?id=HAGUFD3NuzO4
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.
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?)
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 have a label printer that's in the same boat. I wonder how many tokens this convo was
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
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.
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.
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.
güzel bir çalışma olmuş
[dupe] Discussion, including activity from the dev https://news.ycombinator.com/item?id=49344643
See also: https://news.ycombinator.com/item?id=49344643