Reimplementation and Decompilation

If you need help with something, this is the place to be.
Post Reply
theone_32
Posts: 2
Joined: Mon Aug 18, 2025 5:04 pm

Reimplementation and Decompilation

Post by theone_32 »

Hi everyone!
there is this old racing game from 1997. It's a simple, fast-paced, colorful, and quite fun arcade game.
For some unknown reason, this game means to me what Lego Island means to Matt, I guess. :lol:
Just kidding. I suppose there's some nostalgia effect, too — it reminds me of my high school years...

A few months ago, I decided I wanted to recreate this game to make it run on newer architectures, eventually porting it to my Android TV (don't ask...).
I started with Ghidra and reversed all the game file formats: geometries, textures, UI elements, scripts, fonts, sounds and so on.
Most of the data even had several different custom encryption mechanisms that took me a few days to decrypt, and only after I could finally figure out the actual file formats.
What I could not reverse through decompiling and debugging, I managed to figure out by altering game data and running the actual game to see what changed.
Once I had built a fairly extensive library of files specs and Python tools, I started a reimplementation project in C with OpenGL and SDL, recreating everything from the intro to menus to actual in-game play.
It looks quite nice in HD at 32bpp and 60fps. :D

But...

I am not satisfied with the current result, mostly because I can't replicate the exact gameplay, which is what made this game fun for me.
So.. I was considering of going back to ghidra and evaluating a decompilation instead.
Game executable is a simple MSVC 4.2 compiled exe, using DDRAW; ghidra already did a good job, apart of course the missing data structures that need a "human touch".
However, I am not familiar with the tools and techniques that could help with this task, especially in obtaining buildable code—possibly mixed ASM and C—as I progress in defining structures and renaming objects in Ghidra.

What is the state of the art? Which tools are preferred to generate buildable code, even while if it is not yet fully decompiled? And how can I progressively replace that code with the decompiled code I get from Ghidra?

Thanks, everyone! If anyone is interested in my work, I'll be happy to provide more details—just ask!
Last edited by theone_32 on Wed Aug 20, 2025 8:28 am, edited 1 time in total.
Halamix2
Posts: 18
Joined: Sat Dec 10, 2022 6:39 pm
Location: Poland
Contact:

Re: Reimplementation and Decompilation

Post by Halamix2 »

I know of some approaches to this:
  • You could create a CMake project that uses the exact MSVC 4 compiler (down to version of optimizing/non-optimizing one, and compile flags), and compile it that way; then use reccmp [1] (a tool that started as a part of Lego Island Decomp [2]) to compare original .exe functions to yours. In this scenario you might need to recreate a lot of functions to even see the game window at all, since we're not reusing any parts of the original exe nor hooking to it.
    • I'm also decompiling an old game called Stunt GP [2], and I've chose to simply start from main and reimplement functions one by one going as deep as possible; this might not be the most optimal solution, but for now I'll stick with that
  • You could create a .dll and inject functions you've recreated at the runtime. This way you can replace parts of the game as soon as possible, and still have a working game. I *think* RE3 GTA3 decomp used this technique [4].
  • anything in-between, maybe it's possible to join these two approaches
[1]: https://github.com/isledecomp/reccmp
[2]: https://github.com/isledecomp/isle
[3]: https://github.com/stuntkit/regp
[4]: https://github.com/hottabxp/re3, original repo was DMCA'd
theone_32
Posts: 2
Joined: Mon Aug 18, 2025 5:04 pm

Re: Reimplementation and Decompilation

Post by theone_32 »

Thank you very much for the input! I will definitely look into that reccmp tool.
However, I was wondering if there is a way to get a "buildable disassembly," and then replace assembly functions with C ones as you decompile them.
This way, you would have a matching, working executable from the start.
I’m not entirely sure, but I believe this is the approach used by the N64 decomp team.
Is there something like this already? If not, this could actually be an interesting idea for a new tool—I’ll need to investigate further :D
Halamix2
Posts: 18
Joined: Sat Dec 10, 2022 6:39 pm
Location: Poland
Contact:

Re: Reimplementation and Decompilation

Post by Halamix2 »

In C you can always use asm() to use raw assembly (or __asm if you're targeting x86 MSVC): https://en.cppreference.com/w/c/language/asm.html
In theory you could use that and replace asm functions with pure C ones; the main issue is you''d need to somehow convert what Ghidra/IDA gives you to something that could be compiled. One thin is splitting disassembly into functions, other is calling conventions. Some of the assembly might be automatically added to the function, like some PUSHes and POPs if you're passing any parameters to the functions. In fastcall they're passed in ECX, EDX and then on stack; but there are other conventions as well, like cdecl or stdcall, which uses other way of passing parameters around.

As long as you have a MSVC C/C++ project you shoudl be able to use it together with reccmp to not only convert functions one by one from asm to C, but also check how good the C counterparts match the original assembly.
Post Reply