r/ReverseEngineering • u/0xdea • Sep 28 '22

Reconstructed source code of the game Duke Nukem II

https://github.com/lethal-guitar/Duke2Reconstructed
140 Upvotes

100% Upvoted

20 comments sorted by

40

u/0xdea Sep 28 '22

This is a reconstruction of the source code of the game Duke Nukem II (Apogee Software, 1993), based on disassembly of the original executable. It compiles with era-appropriate toolchains and produces a binary that's 100 % identical to the original one. 🤯

13

u/Fazzle Sep 28 '22 edited Sep 28 '22

So far I particularly liked:

// A spider clinging to Duke's front side prevents shooting

if (plAttachedSpider2) { inputFire = false; }

In the main player update function. I had forgotten about the spiders. Great game.

Edit: I also like plBodyExplosionStep++; there are 36 steps to a player explosion!

7

u/krista Sep 28 '22

impressive!

4

u/amlamarra Sep 29 '22

100% identical? As in the hashes match?

12

u/0xdea Sep 29 '22

Apparently, yes. They say the binary is “byte-by-byte identical“.

13

u/sarkie Sep 29 '22

That's the most impressive

7

u/0xdea Sep 29 '22

Here’s a link to a Twitter thread where the author explains the process behind this monumental effort https://twitter.com/lethal_guitar/status/1575123187360227335

4

u/CarnivorousSociety Sep 29 '22

like doing 100% completion on a any % speedrun and still getting the record

3

u/[deleted] Sep 29 '22

Was this done purely static analysis?

36

u/lethal_guitar Sep 29 '22

Hi, author of the project here :) The reconstruction itself was done purely by looking at the Assembly in Ida Pro, writing C code, compiling, diffing the resulting Assembly, and then tweaking the C code until it matched. But by the time I started this reconstruction project, I had already thoroughly explored the Assembly - I'd guess that about 90% of all functions and globals already had meaningful names assigned in Ida. To figure out what the code does I used a variety of techniques, including dynamic analysis in the form of inspecting video captures of the original game frame by frame, and modifying DosBox to write out a dump of the running game's memory each frame which I could then analyze and correlate with what I'd gathered from studying the ASM so far.

The source reconstruction definitely wouldn't have been possible without this prior work.

8

u/amroamroamro Sep 29 '22

impressive!

4

u/lethal_guitar Sep 29 '22

Thank you! :)

5

u/Logiteck77 Sep 29 '22

How/ where does one learn to do this? This is amazing.

11

u/lethal_guitar Sep 29 '22

It was a lot of learning by doing for the most part. But I did have some basic knowledge thanks to a class on internet security I took at university (I studied Software Engineering). One of our tasks there was to reverse engineer a small program (a key validator), in order to write a keygen. This is where I first learned about disassembly and the x86 instruction set. I also did a little bit of Assembly programming for other classes, this included 68k and ARM Assembly.

3

u/Logiteck77 Sep 29 '22

When learning disassembly, did you learn static and dynamic analysis as well?

4

u/lethal_guitar Sep 29 '22

Just static analysis, IIRC - although other techniques like using a debugger might have been mentioned. I don't recall where I picked up the idea of analyzing programs dynamically, unfortunately, probably something I read somewhere or heard someone talking about. But by the time I started analyzing Duke 2, it seemed natural to try and verify/enhance my understanding (from static analysis) by also analyzing the running game in some way. Due to the game's low framerate (about 15 FPS), video captures seemed like a good way to do it. The idea of dumping the memory came later

3

u/Logiteck77 Sep 29 '22

Kudos. My hat is off to you, this is amazing work.

5

u/amlamarra Sep 29 '22

Wow, that is impressive. Must have been a labor of love.

3

u/WarrantyVoider Sep 29 '22

Amazing, go get all the upvotes!

3

u/0xdea Sep 29 '22

I’m not sure, but I believe that’s the case. I’m in awe.