Development Journey on Game Decompilation Using AI

How you can use AI to decompile a game — A Hands-On and Ongoing Study

May 20, 2025

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!

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:

Ghidra. The assembly is on the left, while the corresponding decompiled code is on the right.

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.

The beginning of the journey

A level editor for **Klonoa: Empire of Dreams** — but with decompilation, could we go beyond just editing levels?

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 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 neither 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.

decomp.me screenshot of a scratch. Left to right: source code generated by Claude Sonnet 3.5, target assembly from SA3, and the current assembly produced from the source.

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 Marun that I want to decompile.
Alongside those examples, I also included relevant context in the prompt, such as the Marun structs 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

Proposed AI panel for decomp.me, with a prompt builder + chat

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! 😄