Hacker News Reader

Comment by ryandrake | Hacker News Reader

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.

View on HN

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

Are you planning to develop this in the open somewhere. I would be more than interested to have that davinci capability as well

Not sure yet. Maybe! I put those notes online so someone else could continue Claude’s work. Or get another agent to plug away at it.

"I only got it to proof of concept.... I'm sure with time"

this is AI psychosis. LLMs by design product plausible output -- it ALWAYS seems like you just need a little more time. That's why the junkies are up all night playing with these things, and yet the next industrial revolution has NOT arrived. if this is the singularity where is my clothes folding bot, my cold fusion, and my cure for all cancers?

Please do not post about things the bot almost did. Nobody cares. When you COMPLETE something with the bot you can post. The rest is delusions.

The proof of concept works. You can use aac audio in resolve on Linux. It hasn’t been polished or productised, but it’s demonstrably working. If I got to this point on my own, I’d be very satisfied that I could finish the job.

That would be a justifiable inference in that case. But you didn't get to this point on your own. You haven't learned the knowledge you would have learned getting to this point on your own. Claude didn't either; generally speaking, it doesn't learn. So it may be misleading to reason by analogy to the counterfactual where you had gotten to this point on your own. Claude may or may not be able to finish the job. You won't know until you try.

> Claude may or may not be able to finish the job. You won't know until you try.

Yes, it’s weak evidence. Not proof. That is why I was quite explicit about what it has and hasn’t accomplished.

In my time with it, Claude seems fine at finishing up projects. And I’ve done enough reverse engineering to have a reasonably firm understanding of the outstanding work. I predict that Claude will have no problem finishing this up with some more guidance and tokens. You can of course have your own opinion, but I think it’s a bit much to claim I’m suffering from ai psychosis for having this expectation of its capabilities.

Not knowing you, I would not claim that you are suffering from AI psychosis. You seem to imply that I have made such a claim, but I have not.

This isn’t “AI psychosis”. Stop this. Stop corrupting the definition of “psychosis” by pretending that “AI psychosis” can just be used as a descriptor for anyone that thinks that an LLM can do a thing that you don’t think it can. Any use of the term “AI psychosis” in all but the strictest sense is a huge red flag that someone’s objection is based on philosophical or political grounds, and your objection is a textbook example of that.

Most big tech use LLMs to write most if not all of their code in current year. I have many negative things to say about it but if you think LLMs with a good harness can’t make anything that works you’re plain wrong. We’re shipping AI authored code to prod every day and it does the thing. Or maybe the psychosis goes so deep I’m just imagining all this and I’m actually unemployed

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.

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.

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.

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.

Kinda sounds like you are finally realizing the dream of XML and DTD envisioned 25 years ago.

Exactly! Not to mention the belated realization of the so-called "expert systems" we were promised back in the 80s. Better late than never.

Please consider writing a blog post on this project!

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.

I had a discussion about this with a friend recently. I was using an LLM with a serial console that it wrote to allow us to share a connection to a Z80 computer running CP/M. I was having trouble with the assembler, it wouldn’t assemble in user 1 of a particular disk, so I asked the LLM for help. It debugged ASM.COM and the BDOS, walked through the source compared to memory dumps, basically banging its head on the wall for an hour or more, until it finally figured out and verified that my disk had a bad block. I never would have put in that much effort to find the root cause of the problem.

As an analogy, you're not going to cut your lawn by hand at the speed and slow pace that the smallest and weakest lawn mowing robot does. You're not going to cut your lawn with kitchen scissors. But the LLM will, metaphorically, be perfectly happy to cut your lawn with kitchen scissors as long as it has enough time/tokens to keep cranking away at it.

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

Unless you're on consumption billing.

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.

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.

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.

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

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.

LLMs don't get as mentally exhausted by trying repeated tedious things as a human will. Same general idea as, imagine if you as a human typing into a keyboard had to manually fuzz test software in a pre-LLM era vs. how fuzz testing is actually done.

That's actually pretty simple.

Reverse engineering isn't so much hard as it is exhausting.

LLMs simply don't care about exhaustion.

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.

Ugh - thanks for that memory. Worked tech support for Microsoft at that time - we’d try but often the recommendation was to buy a real modem (“But it’s so much more expensive!” - “Yes, but it works….”)

Well good news... er... the opposite actually....

>Additional Old Linux Drivers Face Removal Due To Noise From AI/LLM Coding Agents

https://www.phoronix.com/news/Linux-Retiring-Moxa-Driver

They're being removed due to a lack of maintenance. If anyone cared about that hardware and fixed the bugs, surely they would be kept.

Don't know much about driver maintenance but if it is working why remove it?

What I read in the link was that it was removed because LLM was making suggestions to improve the code/bring it up to modern standards but since it was rarely used no-one wanted to review it not that it was buggy.

>In recent months we have seen a lot of old kernel code removed stemming from that AI/LLM noise.

This is the opposite of what my parent was hoping to see, extended support for old/obscure hardware because we have LLM.

Because more-or-less all code in the kernel increases the attack surface and makes general security improvements more difficult. Removing code of all types makes maintainability easier, so old, unmaintained code is an easy sell for removal.

>This is the opposite of what my parent was hoping to see, extended support for old/obscure hardware because we have LLM.

That would only happen if the linux project was happy to accept LLM-generated fixes without human review - which they aren't. If human review is necessary, then unleashing LLMs to produce fixes and improvements to thousands of linux drivers is a detriment, not a benefit. The amount of code would just be too much, and reviewers would be swamped.

Maybe wiimotes will finally work on the Apple silicon bluetooth stack as they already do on Windows and Linus.

This might help; haven’t tried it myself. https://github.com/dolphin-emu/WiimotePair

I recently reverse engineered a binary in a system image of Fabrice Bellard's JSLinux [1]. When given just the binary and asked to reverse engineer, Claude Sonnet quickly identified that some utility functions looked like some Fabrice's (yes, Claude mentioned his name without more hints than the binary) library code, so that helped me to guide Claude to fetch some original source code from a Fabrice project (tinyEMU) to use in the reversed project. That allowed to reach a reverse C file that contains just the original part.

[1]: https://github.com/dolmen/JSLinux-utils/blob/main/export_fil...

ChatGPT 5.6 helped me to fully reverse engineer save file format for a relatively-known game, and write a working serializer/deserializer to edit in-game currency. Reverse engineering is something I've always wanted to learn but now I am starting to question if it is worth learning manual reverse engineering at this age when AI can do it for us.

Now we are curious what game it is

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.

i looked those up, that's pricey gear. is that a similar app abandonment like with Sonos deprecating and moving to newer protocols?

Sort of. The company released a new model and deprecated its older ones. It’s still possible to control the amps with the (really neat) physical remote.

Doing something similar with audio equipment. I have an older USB midi controller that doesn’t seem to have official support. Claude helped bring it back to life!

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.

Yes! If only humanity limited the use of this tech to these kind of things where it make sense...

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

Firmware is a lot harder for a whole host of reasons but it is possible / I've done it.

The odds of success go up a LOT when the stock firmware is easy to extract and reverse engineer.

The easiest path is when you get access to a firmware update distribution.

This reminds me to have a look at the latest update I installed in my car for my navigation system and which is installed via an USB key.

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.

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.

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

Programmers enjoy problem solving and coding, but wishing to have problems solved isn't the same thing and only satisfying if it wasn't something that was going to get done otherwise. Wishing products into existence is more of a PM dream

Reply on news.ycombinator.com