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

121–130 of 133 posts

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

#121

Post by tails4e »

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…

Why not follow decompilation like ghidra does, rather than guess, compile, compare? It seems more sensible to actually decompile.

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

#122

Post by jasonjmcghee »

seba_dos1 wrote: post #105
jasonjmcghee wrote: post #60

Earlier quoted context omitted.

No it is not. There is no license in that repository. Relevant: https://github.com/orgs/community/discussions/82431 > When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other c…

There is a license: https://github.com/djyt/cannonball/blob/master/docs/license.... ...but it's very clearly not an open source license.

ah thanks, you're right - I didn't think to look in subfolders. genuinely never seen a license in a subfolder before.

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

#123

Post by jfjfnfjrh »

tails4e wrote: post #121
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…

Why not follow decompilation like ghidra does, rather than guess, compile, compare? It seems more sensible to actually decompile.

Because decompilation does has functions and variables that are nonhuman parsable ... I.e. func_1223337377 with variables a b c d

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

#124

Post by govping »

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…

We've been using LLMs for security research (finding vulnerabilities in ML frameworks) and the pattern is similar - it's surprisingly good at the systematic parts (pattern recognition, code flow analysis) when you give it specific constraints and clear success criteria.

The interesting part: the model consistently underestimates its own speed. We built a complete bug bounty submission pipeline - target research, vulnerability scanning, POC development - in hours when it estimated days. The '10 attempts' heuristic resonates - there's definitely a point where iteration stops being productive.

For decompilation specifically, the 1M context window helps enormously. We can feed entire codebases and ask 'trace this user input to potential sinks' which would be tedious manually. Not perfect, but genuinely useful when combined with human validation.

The key seems to be: narrow scope + clear validation criteria + iterative refinement. Same as this decompilation work.

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

#125

Post by thelittleone »

reactordev wrote: post #89

I’ve been having fun sending Claude down the old school MUD route, giving it access to a SMAUG derivative and once it’s mastered the play, give it admin powers to create new play experiences. I stayed away from decompilation and reverse engineering, for legal reasons. Claude is amazing. It can sometimes get stuck in a reason loop but will break away, reassess, and continue on until it finds its way. Claude was murder…

I'd enjoy watching. A new category of eSports.

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

#127

Post by lomase »

ACCount37 wrote: post #3

If you aren't using LLMs for your reverse engineering tasks, you're missing out, big time. Claude kicks ass. It's good at cleaning up decompiled code, at figuring out what functions do, at uncovering weird assembly tricks and more.

If it is so good at it where are all those decompilation projects?

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

#128

Post by lomase »

viraptor wrote: post #66

Yeah, it works great for porting as well. I tried it on the assembler sources of Prince of Persia for Apple ii and went from nothing to basics being playable (with a few bugs but still) on modern Mac with SDL graphics within a day.

I can also make a port of Prince of Persia, and faster than a LLM:

https://github.com/NagyD/SDLPoP

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

#129

Post by simonw »

Animats wrote: post #116
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…

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. They had access to the same C compiler used by Nintendo in 1999? And the register allocation on a MIPS CPU is repeatable enough to get an exact match? That's impressive.

There's a note about that:

> Snowboard Kids 2 was written in C and compiled to MIPS machine code. The compiler was likely GCC 2.7.2 based on the instruction patterns [3]

The footnote is interesting: https://blog.chrislewis.au/using-coding-agents-to-decompile-...

> This is mostly just guesswork and trying different variations of compiler versions and configuration options. But it isn’t as bad as it sounds since the time period limits which compilers were plausibly used. The compiler arguments used in other, similar, games also provide a useful reference.

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

#130

Post by big-and-small »

TheAceOfHearts wrote: post #104
rlili wrote: post #12

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

If progress continues, someday it'll be possible to generate the source code for any binary and make a native port to any other platform. Some companies might be upset, but it'll be a huge boon for game and software preservation.

While "native" is always questionable it was possible long ago without actually ever having source code. E.g back in 2024 there was ARM port of StarCraft 1 for OpenPandora. Just "dumb" x86 decompilation and then building against Wine for ARM.

https://hackaday.com/2014/07/31/playing-starcraft-on-an-arm/

https://pyra-handheld.com/boards/threads/starcraft.73844/

Post reply on HN