I wonder if LLMs are useful in reconstructing a real compilable game that reverse engineers all functions.
No, not in the sense that I want to shove "AI" into everything vibe coding, but that I seems to me that those PDBs are insanely valuable artifacts for data sourcing and doing posttrainings for.
We have all those variable names, and perhaps a little bit of optimization change such as the control flow, and the hard inverse problem of figuring out if likely/unlikely's effect on branch predictor, that means guessing the likely/unlikely without knowing real code on the code generated by compiler and the general feature of the CPU of that era, and sometimes even guessing the compiler version right too, since new versions of compiler may have better optimization down the line.
This I would say is something that even the best compiler wizard can't really do, but LLM is ruthless and reluctant on trying, until they find one.
Of course, things like vtable and structure layouts/paddings is almost impossible to truly reverse. Not even human, even LLM would struggle.
Designing/generating those assets is an incredible amount of work, it's the value-add on top of an engine that a game studio spends most of their budget on. Game reimplementations like this one get their own asset-sets sometimes, but it's rare and usually happens long after the game is working
The blog post does not explain the kisak naming, although I have a vague feeling I know what this is a reference to, especially with the avatar. Hit me like a flashbang when I opened HN today and saw it, so I just wanted to say hi. And great job on the server, of course.
Honestly such decomp projects are the place where LLM agents help the most, I have a similar one for a 1999 game which started from the agent renaming all functions, globals in the IDA DB, adding types and function signatures. After the database was basically 100% annotated, it was exported, made compilable with the same compiler as the original game. Then after some fixes (basically all being IDA decompilation bugs) it became playable.
Having the same compiler helps, and I also have a binary matching workflow, but matching functions 100% is a huge token sink due to compiler optimizations, so I just had agents review functions one by one for differences, clean up decompiler artifacts and possible semantic bugs, and mark functions as reviewed. So the raw matching % is really low even though the game already works.
It does help that the game's native part is quite small, only 1.5k pure C functions in 700KB of code. Although with LLMs as long as you have enough usage, it's only a matter of time even for huge codebases.
As the LLM I used GPT 5.5, then 5.6 Sol, I trust GPT models the most for reverse engineering, they're very thorough.
It's nice that these people started using LLMs (mentioned in https://lwss.github.io/Kisak-Black/), although IDA MCPs are worse than CLI-based options, and I wouldn't trust Claude models that much for this work. It seems like the work started in 2025 when those models weren't good enough for that, but they absolutely are now.
Decomps are one of those repetitive, mostly non creative tasks that I think humans shouldn't spend their valuable time on, maybe only to guide or clean up. If you have an older favorite game, chances are, you can fully decompile and reimplement it with enough tokens :)
I wonder if LLMs are useful in reconstructing a real compilable game that reverse engineers all functions.
No, not in the sense that I want to shove "AI" into everything vibe coding, but that I seems to me that those PDBs are insanely valuable artifacts for data sourcing and doing posttrainings for.
We have all those variable names, and perhaps a little bit of optimization change such as the control flow, and the hard inverse problem of figuring out if likely/unlikely's effect on branch predictor, that means guessing the likely/unlikely without knowing real code on the code generated by compiler and the general feature of the CPU of that era, and sometimes even guessing the compiler version right too, since new versions of compiler may have better optimization down the line.
This I would say is something that even the best compiler wizard can't really do, but LLM is ruthless and reluctant on trying, until they find one.
Of course, things like vtable and structure layouts/paddings is almost impossible to truly reverse. Not even human, even LLM would struggle.
Some well written devblogs are also available:
Hmm, that's pretty strange how it came with gpl license.
It's derived from Jedi Academy's source code which is licensed under GPL.
Indeed, I don't think that a decompilation is clearly licensable like that..
Why? Nominally an anti TiVo clause is attractive for a community server, no?
Never seen GPL disclosed with a BIG logo before (it's a good logo!)
> Copy COD4 Game files to bin/(BUILD_TYPE)/* (Don't try to cherry-pick them, small files like localization.txt are needed)
Would be great to have a version where the game assets are designed/generated somehow and it's already to be tested, even if the experience is worse.
Designing/generating those assets is an incredible amount of work, it's the value-add on top of an engine that a game studio spends most of their budget on. Game reimplementations like this one get their own asset-sets sometimes, but it's rare and usually happens long after the game is working
The blog post does not explain the kisak naming, although I have a vague feeling I know what this is a reference to, especially with the avatar. Hit me like a flashbang when I opened HN today and saw it, so I just wanted to say hi. And great job on the server, of course.
How was this done?
https://lwss.github.io/Kisak-Black/#ai-debugging
Reverse-engineering from PDBs, working on top of a GPL codebase. COD4 is built on id tech.
https://lwss.github.io/
Honestly such decomp projects are the place where LLM agents help the most, I have a similar one for a 1999 game which started from the agent renaming all functions, globals in the IDA DB, adding types and function signatures. After the database was basically 100% annotated, it was exported, made compilable with the same compiler as the original game. Then after some fixes (basically all being IDA decompilation bugs) it became playable.
Having the same compiler helps, and I also have a binary matching workflow, but matching functions 100% is a huge token sink due to compiler optimizations, so I just had agents review functions one by one for differences, clean up decompiler artifacts and possible semantic bugs, and mark functions as reviewed. So the raw matching % is really low even though the game already works.
It does help that the game's native part is quite small, only 1.5k pure C functions in 700KB of code. Although with LLMs as long as you have enough usage, it's only a matter of time even for huge codebases.
As the LLM I used GPT 5.5, then 5.6 Sol, I trust GPT models the most for reverse engineering, they're very thorough.
It's nice that these people started using LLMs (mentioned in https://lwss.github.io/Kisak-Black/), although IDA MCPs are worse than CLI-based options, and I wouldn't trust Claude models that much for this work. It seems like the work started in 2025 when those models weren't good enough for that, but they absolutely are now.
Decomps are one of those repetitive, mostly non creative tasks that I think humans shouldn't spend their valuable time on, maybe only to guide or clean up. If you have an older favorite game, chances are, you can fully decompile and reimplement it with enough tokens :)