Development Journey on Game Decompilation Using AI
How you can use AI to decompile a game — A Hands-On and Ongoing Study
Hey, I’m Macabeus. In this post, I’ll share my development journey using AI to decompile old games and explore my personal research in this fun field!
Spoiler: At the end of the 3rd chapter, you'll learn how it was built:
Talk
Prefer watching over reading?
You might enjoy my talk “Retro Game Decompilation Using AI”. It’s a good introduction to this fascinating topic and how AI can play a helpful role.
Game decompilation?
In few words, decompilation is the process of translating a low-level code into a higher-level one. For example, from assembly to C.
You might know it from popular reverse engineering tools like IDA Pro and Ghidra:
But, for this post, whenever I mention decompilation, I'm talking about matching decompilation. This more specific term means that we want to write a higher-level code that, when compiled, matches exactly to the target assembly, while also being human-readable.
The decompiler in Ghidra and similar tools is primarily useful for reference. It helps when analyzing the assembly, but it’s not suitable for producing high-level source code that, when compiled, generates an identical binary.
Having high-level, readable C code that produces the exact binary as the original one enables us to give a second life to an old game. Once the code becomes readable, it opens the door to exploration, customization, and new possibilities!
For example, one of the first major games to be fully decompiled was Super Mario 64, which paved the way for incredible community projects, like porting it to PC and running it in high definition. You can read more about it here.
It's worth mentioning that while decompilation can be a means to an end, as explained above, a major reason why some people dive into it is simply because it’s intrinsically fun. It's like solving a massive puzzle with thousands of pieces. That said, it’s important to enjoy the process, because if you don’t, you’ll likely burn out long before reaching the finish line.
The beginning of the journey
I’ve always enjoyed game reverse engineering. One of my first projects was a level editor for Klonoa: Empire of Dreams. As a next step, I thought it would be exciting to try decompiling this game itself! Of course, before diving into such a big task, I needed to actually learn how game decompilation works, and helping in an ongoing project would be a good approach.
To get started, I decided to contribute to the decompilation of Sonic Advance 3 (GitHub), since it's also a GBA game like the Klonoa one and it has many pending functions easy to decompile.
For my first pull request, I worked on decompiling an enemy called Marun. I chose this module based on guidance from the project’s main contributors, who pointed out that enemy code in SA3 tends to follow similar patterns. That meant I could look at previously decompiled enemies as references, making it a solid starting point.
At first, I followed the same approach as the other contributors: using decomp.me, creating a scratch, and manually decompiling the assembly code. But it was tough going. I'm not fluent in C or assembly, so this task required a lot of context and intuition that I don't have yet.
Matching Decompilation 101: What does “scratch” mean?
A scratch refers to a piece of work. It includes the target assembly from the game, your higher-level code, and the current assembly generated by compiling your code.
After a while, I got thinking: “Maybe I can use AI to assist with decompilation. After all, this process involves a lot of pattern matching, that is precisely what AI is good at.”
I selected a function that consisted mostly of simple, repetitive instructions and decided to try using a basic prompt on the latest Claude Sonnet version at this point (early Jan 2025): Sonnet 3.5. To my surprise, the AI generated a code that achieved a 96% match on the first attempt! You can check out the scratch and the chat. While the output still needed refinement to be truly human-readable, hitting 96% right away provides a fantastic starting point to decompile the function.
Matching Decompilation 101: What does "match" mean?
When we are talking about matching decompilation, “% match” means how close is your current assembly with the target assembly, given an assembly differ algorithm.
The goal is to achieve 100% match (i.e., the C code compiles to exactly the same target assembly) and to have a readable C code.
Then, I focused on prompt refinement for the next functions:
I looked for similar decompiled functions in other enemies to use as examples, especially if they called the same internal functions as the one from
Marunthat I want to decompile.Alongside those examples, I also included relevant context in the prompt, such as the
Marunstructs and any other important definitions.
Unfortunately, despite multiple attempts, I wasn’t able to replicate a result as good as the 96% match. It started to feel like that first result might have just been a lucky outlier...
But then, on January 20th, something promising happened: DeepSeek released their R1 model, the first publicly available reasoning model that was free to use. I tested it right away, and the results were impressive, much better than what I got with Sonnet 3.5.
For example, with this prompt, DeepSeek returned a code with a 74% match. And the fix was simple: just replacing memset with CpuFill16 brought it up to a 100% match!
From my experience decompiling the Marun module, DeepSeek R1 consistently outputs a code with at least a ~60% match.
Beyond just providing a good kickstart, it also helped me refine the code, either by improving the match rate or by improving readability while keeping the matching rate. For example, it helped me to avoid a goto.
Of course, the AI code isn't perfect. One recurring issue was the lack of macros. It's expected: it doesn’t inherently know about project-specific macros unless they’re included in the prompt or provided somewhere else, and since macros don’t appear in assembly, they’re easy to miss. I also lacked full context about the project myself, so I didn’t always realize when a macro was missing to include in the prompt. During the code review, this was one of the main areas flagged for improvement.
I started to work on decompiling the Marun module on 6th January, and, working on it only in my spare time, the PR was finally merged on 31st January, equivalent to 0.3% of the total progress on SA3.
AI + decomp.me
After achieving the 100% match for the Marun module, I started working on adding AI into decomp.me. My goal was to engage more folks on it and enhance the AI workflow for decompilation. Some features, such as automatically providing good examples to include in prompts, are only practical with a deeper integration.
Since I was primarily using AI to kickstart new scratches, I designed the UX around that specific use case (you can see a demo video here). After some feedback on the pull request, the UX was redesigned to a chat-based approach. However, the PR wasn’t merged because it’s still unclear exactly how users would benefit it and friction to start with it, specifically because it requires the users to enter a paid API key from an AI provider.
Now, though, we have a promising new technology: the Model Context Protocol (MCP). With MCP, it might be possible to add AI support to decomp.me in a more seamless and user-friendly way.
There are cases as using MCP + Ghidra, for example, which can be an inspiration on how to add MCP to a decompilation tooling. We are going to check it later!
Final Thoughts
From this first experience, a few key takeaways stand out:
I've been testing AI in a very specific context: decompiling an enemy module from Sonic Advance 3.
In this narrow use case, AI proved to be incredibly effective! It gave me a strong starting point for many functions, and even with my limited fluency in C and assembly, I was able to decompile an entire module fairly quickly.
That said, this was likely a very AI-friendly scenario. I had other modules that were already decompiled and similar to the one that I was working on, which allowed me to include in the prompt high-quality examples. Also, since the GBA is an older console, the compiler is also simpler and more predictable.
To apply this workflow to more modern games, more research and tooling will be needed. For example: fine-tuning models for a specific console or game data, automating the inclusion of various relevant examples, or integrating AI through protocols like MCP to provide structured, contextual assistance.
That’s all for now! As you can see, there is a big room for improvement and opportunities here. It's exciting that we always have news on the AI field that may be useful for this challenge.
My ultimate goal is to decompile fully a game using only AI. Ambitious? Definitely. Fun? Definitely too! Let’s make it happen! 😄
Follow me on Twitter and Bluesky to be along my progress on this research. I'm also streaming on Twitch this work on matching decompilation using AI. I’m also active on the decomp.me’s Discord server, my username is bmacabeus.
im confused so you took something you didn't know how to do, said ai got 96% immediately on its first try (and this percent lights up your human reward function happily), and your takeaway is that ai is cool and great for this? not that someone who maybe does know what they're doing couldn't also get from 0-96 in 30 seconds?