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

The unexpected effectiveness of one-shot decompilation with Claude

blog.chrislewis.au

Post reply on HN
Print view View original

41–50 of 133 posts

Re: The unexpected effectiveness of one-shot decompilation with Claude

#41

Post by simonw »

sa1 wrote: post #37
jasonjmcghee wrote: post #36

Earlier quoted context omitted.

It would be "source available", if anything, not "open source". > An open-source license is a type of license for computer software and other products that allows the source code, blueprint or design to be used, modified or shared (with or without modification) under defined terms and conditions. https://en.wikipedia.org/wiki/Open_source Companies have been really abusing what open source means- claiming something is…

But clean room reverse engineered code can have its own license, no?

Yeah, I think it can. I'm reminded of the thing in the 80s when Compaq reverse engineered and reimplemented the IBM BIOS by having one team decompile it and write a spec which they handed to a separate team who built a new implementation based on the spec.

I expect that for games the more important piece will be the art assets - like how the Quake game engine was open source but you still needed to buy a copy of the game in order to use the textures.

Re: The unexpected effectiveness of one-shot decompilation with Claude

#42

Post by simonw »

saagarjha wrote: post #22
amelius wrote: post #7

Earlier quoted context omitted.

Makes sense because LLMs are quite good at translating between natural languages. Anyway, we're reaching the point where documentation can be generated by LLMs and this is great news for developers.

Documentation is one place where humans should have input. If an LLM can generate documentation, why would I want you to generate it when I can do so myself (probably with a better, newer model)?

I definitely want documentation that a project expert has reviewed. I've found LLMs are fantastic at writing documentation about how something works, but they have a nasty tendency to take guesses at WHY - you'll get occasional sentences like "This improves the efficiency of the system".

I don't want invented rationales for changes, I want to know the actual reason a developer decided that the code should work that way.

Re: The unexpected effectiveness of one-shot decompilation with Claude

#44

Post by ACCount37 »

saagarjha wrote: post #22
amelius wrote: post #7

Earlier quoted context omitted.

Makes sense because LLMs are quite good at translating between natural languages. Anyway, we're reaching the point where documentation can be generated by LLMs and this is great news for developers.

Documentation is one place where humans should have input. If an LLM can generate documentation, why would I want you to generate it when I can do so myself (probably with a better, newer model)?

That's great if those humans are around to have that input.

Not so much when you have a lot of code from 6 years ago, built around an obscure SDK, and you have to figure out how it works, and the documentation is both incredibly sparse and in Chinese.

Re: The unexpected effectiveness of one-shot decompilation with Claude

#45

Post by t_mann »

> The ‘give up after ten attempts’ threshold aims to prevent Claude from wasting tokens when further progress is unlikely. It was only partially successful, as Claude would still sometimes make dozens of attempts.

Not what I would have expected from a 'one-shot'. Maybe self-supervised would be a more suitable term?

Re: The unexpected effectiveness of one-shot decompilation with Claude

#46

Post by zdware »

saagarjha wrote: post #24

It's worth noting here that the author came up with a handful of good heuristics to guide Claude and a very specific goal, and the LLM did a good job given those constraints. Most seasoned reverse engineers I know have found similar wins with those in place. What LLMs are (still?) not good at is one-shot reverse engineering for understanding by a non-expert. If that's your goal, don't blindly use an LLM. People alrea…

Agree with this. I'm a software engineer that has mostly not had to manage memory for most of my career.

I asked Opus how hard it would be to port the script extender for Baldurs Gate 3 from Windows to the native Linux Build. It outlined that it would be very difficult for someone without reverse engineering experience, and correctly pointed out they are using different compilers, so it's not a simple mapping exercise. It's recommendation was not to try unless I was a Ghrida master and had lots of time in my hands.

Re: The unexpected effectiveness of one-shot decompilation with Claude

#47

Post by elitan »

simonw wrote: post #38

For anyone else who was initially confused by this, useful context is that Snowboard Kids 2 is an N64 game. I also wasn't familiar with this terminology: > You hand it a function; it tries to match it, and you move on. In decompilation "matching" means you found a function block in the machine code, wrote some C, then confirmed that the C produces the exact same binary machine code once it is compiled. The author's p…

helpful

Re: The unexpected effectiveness of one-shot decompilation with Claude

#48

Post by ashoeafoot »

tcdent wrote: post #40
rlili wrote: post #12

Makes me wonder if decompilation could eventually become so trivial that everything would become de-facto open source.

That's definitely a possible future abstraction and one are about the future of technology I'm excited about. First we get to tackle all of the small ideas and side projects we haven't had time to prioritize. Then, we start taking ownership of all of the software systems that we interact with on a daily basis; hacking in modifications and reverse engineering protocols to suit our needs. Finally our own interaction wi…

[dead]

Re: The unexpected effectiveness of one-shot decompilation with Claude

#49

Post by benmccann »

I used Gemini to compare the minimized output of the Rollup vs Rolldown JavaScript bundlers to find locations where the latter was not yet at the same degree of optimization. It was astoundingly good and I'm not sure how I would have been able to accomplish the task without an LLM as an available tool.

Re: The unexpected effectiveness of one-shot decompilation with Claude

#50

Post by amelius »

saagarjha wrote: post #22
amelius wrote: post #7

Earlier quoted context omitted.

Makes sense because LLMs are quite good at translating between natural languages. Anyway, we're reaching the point where documentation can be generated by LLMs and this is great news for developers.

Documentation is one place where humans should have input. If an LLM can generate documentation, why would I want you to generate it when I can do so myself (probably with a better, newer model)?

Because it takes time and effort to write documentation.

If people __can__ actually read undocumented code with the help of LLMs, why do you need human-written documentation really?

Post reply on HN