Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude writing a macOS driver for my obscure HP printer built only for Windows

twitter.com

Post reply on HN
Print view View original

131–140 of 241 posts

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#131

Post by mjg59 »

IshKebab wrote: post #112
ryandrake wrote: post #86

Earlier quoted context omitted.

I don't understand the technology enough to see why, but LLMs seem unusually skilled at reverse engineering proprietary software.

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) tedio…

My experience is that they're better than me at a lot of the process, so probably worse than someone who's a full time reverse engineer but as good as or better than most. They'll definitely get some small details wrong that would derail the entire thing, so having some skills that are pretty much "This smells wrong" helps a lot, but I think for many scenarios they'll unblock someone who has little RE experience.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#132

Post by josephg »

squibonpig wrote: post #116
ryandrake wrote: post #76

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…

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.

Last week I had Claude add support for aac audio to davinci resolve on Linux, just by patching the binary. It did almost exclusively with gdb and objdump, patching about 5 functions over an hour or two.

I only got it to the proof of concept stage. The patch adds aac but breaks flac support in the process. And it only works for aac in mp4 container files. But I’m sure with a bit of time we could make a patch which works everywhere and is additive only.

I say ‘we’ - I barely helped. Almost all the work was done by Claude.

Here’s Claude’s report, if anyone wants to build on this work:

https://claude.ai/code/artifact/87d38c2e-9ecb-4066-90cf-e0b2...

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#133

Post by cracell »

antihero wrote: post #124
ryandrake wrote: post #76

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…

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?

More the second.

For programmers this is the equivalent of when accountants got spreadsheets. We can just tell the machine what to do without manually performing all the steps.

Some programmers enjoyed the code writing more than the problem solving though.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#134

Post by netsharc »

Tiberium wrote: post #73

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.

Ah, 2026... When the "tech write up" on page 1 of "Hacker News" is some genius selling an LLM creating a VM as "wrote a driver".

OP should probably add this to his list of accomplishments on LinkedIn...

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#135

Post by qingcharles »

perching_aix wrote: post #115
Tiberium wrote: post #73

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 that way.

Agreed.

I bought some cheap host-managed SATA drives the other day that the BIOS can't see and Windows won't recognize. I asked Claude to write a Windows app so I can use them, and it resisted at first, but then gave up and wrote it and they now work great.

It had to implement the entire stack of bare-metal drive functions over SATA and a whole new filesystem to go with it.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#136

Post by CamperBob2 »

mmh0000 wrote: post #99
ryandrake wrote: post #86

Earlier quoted context omitted.

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 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…

Don't sell in-context learning short. Right now I'm waiting on Claude to wrap up the latest of a half-dozen extensive changes to XML files for a fairly-obscure (and obsolete) closed-source electronics CAD program. I am pretty sure it doesn't know anything about these files besides what's in the XML .DTD file (which I also gave it.)

This is a very novel, reasonably-poorly-documented problem, and so far it has batted 1.000.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#137

Post by SchemaLoad »

IshKebab wrote: post #112
ryandrake wrote: post #86

Earlier quoted context omitted.

I don't understand the technology enough to see why, but LLMs seem unusually skilled at reverse engineering proprietary software.

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) tedio…

Also verifiable. LLMs shine when they can know when the task is completed correctly. Otherwise they will finish and hand over something that's wrong.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#138

Post by SchemaLoad »

eggnet wrote: post #127
ryandrake wrote: post #76

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…

I wonder how hard it would be to create various firmware updaters for drives or other devices.

I'd be cautious here because you very easily could brick the hardware. For writing a PC driver it's a lot safer since you can just fail repeatedly until it works.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#139

Post by jasonfarnon »

ryandrake wrote: post #86
sinpif wrote: post #79

Earlier quoted context omitted.

Had a similar thought today - maybe we could finally get Linux drivers for more HW...

I don't understand the technology enough to see why, but LLMs seem unusually skilled at reverse engineering proprietary software.

It's LLMs' generalist skills. I think reverse engineering is usually hard when you're in an unfamiliar domain. Eg I've never programmed a videogame or windows application but I'm trying to crack one. On the other hand if you know the domain, and know what the programmers' intentions must be in any given block of code, it's often straightforward. There are no unfamiliar domains for LLMs, including it seems proprietary software.

Re: Claude writing a macOS driver for my obscure HP printer built only for Windows

#140

Post by scoot »

Rebelgecko wrote: post #81
ryandrake wrote: post #76

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…

I've had good luck using AI to reverse-engineer Bluetooth comms for "smart" products with shitty apps.

I've recently done the same for a Bluetooth LED matrix display, then took it a step further assembling my own hardware (ESP32 controller and RGBIC matrix) to have control over the firmware for features that weren't possible with the off-the-shelf device.

None of this would have been possible (or at least practical from a time-value perspective) for me to do without Claude driving the whole exercise.

Post reply on HN