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 already know that you getting an LLM to write prose or code is bad, but it's worth remembering that doing this for decompilation is even harder :)
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.
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.
Companies have been really abusing what open source means- claiming something is "open source" cause they share the code and then having a license that says you can't use any part of it in any way.
Similarly if you ever use that software or depending on where you downloaded it from, you might have agreed not to decompile or read the source code. Using that code is a gamble.
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.
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 with software becomes entirely boutique: operating systems, firmware, user interfaces that we have directed ourselves to suit our individual tastes.
Yes, I believe it will. What I predict will happen is that most commercial software will be hosted and provided through "trusted" platforms with limited access, making reverse engineering impossible.
I've used LLMs to help with decompilation since the original release of GPT-4. They're excellent at recognizing the purpose of functions and refactoring IDA or Ghidra pseudo-C into readable code.
The article is a useful resource for setting up automated flows, and Claude is great at assembly. Codex less so, Gemini is also good at assembly. Gemini will happily hand roll x86_64 bytecode. Codex appears optimized for more "mainstream" dev tasks, and excels at that. If only Gemini had a great agent...
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 built around an obscure SDK from 6 years ago, and you have to figure out how it works, and the documentation is both incredibly sparse and in Chinese.
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.
Maybe documentation meant for other llms to ingest. Their documentation is like their code, it might work, but I don't want to have to be the one to read it.
Although of course if you don't vibe document but instead just use them as a tool, with significant human input, then yes go ahead.
I've been experimenting with running Claude in headless mode + a continuous loop to decompile N64 functions and the results have been pretty incredible. (This is despite already using Claude in my decompilation workflow).
This sounds interesting! Do you have some good introduction to N64 decompiliation? Would you recommend using Claude right from the start or rather try to get to know the ins and outs of N64 decomp?
This is super cool! I would be curious to see how Gemini 3 fares… I've found it to be even more effective than Opus 4.5 at technical analysis (in another domain).
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 already know that you getting an LLM to write prose or code is bad, but it's worth remembering that doing this for decompilation is even harder :)
Are they not performing well because they are trained to be more generic, or is the task too complex? It seems like a cheap problem to fine-tune.
Sounds like a more agentic pipeline task. Decompile, assess, explain.
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.
Makes me wonder if decompilation could eventually become so trivial that everything would become de-facto open source.
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 "open source" cause they share the code and then having a license that says you can't use any part of it in any way.
Similarly if you ever use that software or depending on where you downloaded it from, you might have agreed not to decompile or read the source code. Using that code is a gamble.
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.
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 with software becomes entirely boutique: operating systems, firmware, user interfaces that we have directed ourselves to suit our individual tastes.
This day will arrive.
And it will be great for retro game preservation.
Having more integrated tools and tutorials on this would be awesome.
I wonder when you're never going to run expensive software on your own CPU.
It'll either all be in the cloud, so you never run the code...
Or it'll be on a chip, in a hermetically sealed usb drive, that you plug in to your computer.
When the decompilation like that is trivial, so is recreation without decompilation. It implies the LLM know exactly how thins work.
Yes, I believe it will. What I predict will happen is that most commercial software will be hosted and provided through "trusted" platforms with limited access, making reverse engineering impossible.
This deserves a discussion
We're very far away from this.
I've used LLMs to help with decompilation since the original release of GPT-4. They're excellent at recognizing the purpose of functions and refactoring IDA or Ghidra pseudo-C into readable code.
How does it do on things that were originally written in assembly?
This is typically easier because the code was written for humans already.
Someone please try this on an original (early 1980s) IBM-PC BIOS.
More than an overview, a step by step tutorial on this would be awesome!
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.
The article is a useful resource for setting up automated flows, and Claude is great at assembly. Codex less so, Gemini is also good at assembly. Gemini will happily hand roll x86_64 bytecode. Codex appears optimized for more "mainstream" dev tasks, and excels at that. If only Gemini had a great agent...
I've been using Claude for months with Ghidra. It is simply amazing.
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 built around an obscure SDK from 6 years ago, and you have to figure out how it works, and the documentation is both incredibly sparse and in Chinese.
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.
I stumbled across a fun trick this week. After making some API changes, I had CC “write a note to the FE team with the changes”.
I then pasted this to another CC instance running the FE app, and it made the counter part.
Yes, I could have CC running against both repos and sometimes do, but I often run separate instances when tasks are complex.
Maybe documentation meant for other llms to ingest. Their documentation is like their code, it might work, but I don't want to have to be the one to read it.
Although of course if you don't vibe document but instead just use them as a tool, with significant human input, then yes go ahead.
Although with code it's implementing functions that don't exist yet and with documentation, it's describing functions that don't exist yet.
I've been experimenting with running Claude in headless mode + a continuous loop to decompile N64 functions and the results have been pretty incredible. (This is despite already using Claude in my decompilation workflow).
I hope that others find this similarly useful.
This sounds interesting! Do you have some good introduction to N64 decompiliation? Would you recommend using Claude right from the start or rather try to get to know the ins and outs of N64 decomp?
What game are you working on?
Last sentence of the first paragraph says it’s Snowboard Kids 2.
For his defense, it is missing a "Tell HN"
And it isn't always obvious when the commenter is the submitter (no [S] tag like you see on other sites).
whoops, I did indeed miss that this was OP
This is super cool! I would be curious to see how Gemini 3 fares… I've found it to be even more effective than Opus 4.5 at technical analysis (in another domain).
I've been waiting for decompilation to show up in this space.
Are there any similar specialized decompilation LLM models available to be used locally?
This is a refreshingly practical demonstration of an LLM adding value. More of this please.