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

The long tail of LLM-assisted decompilation

blog.chrislewis.au

Post reply on HN
Print view View original

11–20 of 31 posts

Re: The long tail of LLM-assisted decompilation

#11

Post by _aavaa_ »

m463 wrote: post #10
nemo1618 wrote: post #7

IMO this is one of the best use cases for AI today. Each function is like a separate mini problem with an explicit, easy-to-verify solution, and the goal is (essentially) to output text that resembles what humans write -- specifically, C code , which the models have obviously seen a lot of. And no one is harmed by this use of AI; no one's job is being taken. It's just automating an enormous amount of grunt work that…

> And no one is harmed by this use of AI; no one's job is being taken what about: see cool app, decompile it, launch competing app. (repeat)

Decompiling seems like the hard way to go here. Lots of clones pop up for popular games and apps all the time. I don't think you need to go down the decompile route to achieve that.

Re: The long tail of LLM-assisted decompilation

#12

Post by suprjami »

bri3d wrote: post #6

Claude is doing the decompilation here, right? Has this been compared against using a traditional decompiler with Claude in the loop to improve decompilation and ensure matched results? I would think that Claude’s training data would include a lot more pseudo-C C knowledge than MIPS assembler from GCC 2.7 and C pairs, and even if the traditional decompiler was kind of bad at N64 it would be more efficient to fix bad…

Not Claude, but there are open-weight LLMs trained specifically on Ghidra decomp and tested on their ability to help reverse engineers make sense of it:

https://huggingface.co/LLM4Binary/llm4decompile-22b-v2

There's also a dataset floating around HF which is... I think a popular N64 decomp to pseudo-C? Maybe the Mario one?

Re: The long tail of LLM-assisted decompilation

#14

Post by qingcharles »

OptionOfT wrote: post #2

I'm really excited about this, especially for games for which the source code was lost like Red Alert 2.

Me too. I'm going to be reverse-engineering Elite PC (original version) and I can't help but think the source is lost. The developer seems to have totally dropped off the face of the Earth. I've contacted others who might know and nobody knows where they are.

Even the game I was a developer on which was published by Eidos in ~1998 is probably lost source. I can't think that anyone has the Visual Source Safe database backup CDs lying around, but I could be wrong.

Re: The long tail of LLM-assisted decompilation

#15

Post by qingcharles »

nemo1618 wrote: post #7

IMO this is one of the best use cases for AI today. Each function is like a separate mini problem with an explicit, easy-to-verify solution, and the goal is (essentially) to output text that resembles what humans write -- specifically, C code , which the models have obviously seen a lot of. And no one is harmed by this use of AI; no one's job is being taken. It's just automating an enormous amount of grunt work that…

And the renaming of all the variables from the auto-gen ones into something human readable was always a thankless task which LLMs are really good for.

Re: The long tail of LLM-assisted decompilation

#16

Post by lstodd »

qingcharles wrote: post #14
OptionOfT wrote: post #2

I'm really excited about this, especially for games for which the source code was lost like Red Alert 2.

Me too. I'm going to be reverse-engineering Elite PC (original version) and I can't help but think the source is lost. The developer seems to have totally dropped off the face of the Earth. I've contacted others who might know and nobody knows where they are. Even the game I was a developer on which was published by Eidos in ~1998 is probably lost source. I can't think that anyone has the Visual Source Safe database…

You mean 1991 Elite Plus? The whole series has been reverse-engineered to death and back. Maybe you mean some other game?

Anyway, for those old titles I don't think not having source is that much of a problem. I participated in two reimplementations of 1994 XCOM : UFO2000 and OpenXcom, helped the 1oom project (first Master of Orion) and I don't think having original source would have helped much.

Re: The long tail of LLM-assisted decompilation

#17

Post by sestep »

bri3d wrote: post #6

Claude is doing the decompilation here, right? Has this been compared against using a traditional decompiler with Claude in the loop to improve decompilation and ensure matched results? I would think that Claude’s training data would include a lot more pseudo-C C knowledge than MIPS assembler from GCC 2.7 and C pairs, and even if the traditional decompiler was kind of bad at N64 it would be more efficient to fix bad…

One of the other PhD students in my department has an NDSS 2026 paper about combining the strengths of both LLMs and traditional decompilers! https://lukedramko.github.io/files/idioms.pdf

Re: The long tail of LLM-assisted decompilation

#18

Post by seddonm1 »

measurablefunc wrote: post #8
amelius wrote: post #4

Does this technique limit the LLM to correctness-preserving transforms?

Like all things related to LLMs, semantic correctness is left as an exercise for the reader.

I delivered a talk at Rust Sydney about this exact topic last week:

https://reorchestrate.com/posts/your-binary-is-no-longer-saf...

I am able to translate multi-thousand line c functions - and reproduce bug-for-bug implementation

Re: The long tail of LLM-assisted decompilation

#19

Post by measurablefunc »

seddonm1 wrote: post #18
measurablefunc wrote: post #8

Earlier quoted context omitted.

Like all things related to LLMs, semantic correctness is left as an exercise for the reader.

I delivered a talk at Rust Sydney about this exact topic last week: https://reorchestrate.com/posts/your-binary-is-no-longer-saf... I am able to translate multi-thousand line c functions - and reproduce bug-for-bug implementation

Decompilation does not preserve semantics. You generally do not know whether the code from the decompiler will be compiled to semantically equivalent binary that you initially decompiled.

Re: The long tail of LLM-assisted decompilation

#20

Post by seddonm1 »

measurablefunc wrote: post #19
seddonm1 wrote: post #18

Earlier quoted context omitted.

I delivered a talk at Rust Sydney about this exact topic last week: https://reorchestrate.com/posts/your-binary-is-no-longer-saf... I am able to translate multi-thousand line c functions - and reproduce bug-for-bug implementation

Decompilation does not preserve semantics. You generally do not know whether the code from the decompiler will be compiled to semantically equivalent binary that you initially decompiled.

My test harness loads up the original DLL then executes that in parallel against the converted code (differential testing). That closes the feedback loop the LLM needs to be able to find and fix discrepancies.

I'm also doing this on an old Win32 DLL so the task is probably much easier than a lot of code bases.

Post reply on HN