The Hunt for the Lost Compiler: Humble Beginnings

You know that feeling when you finish a major life milestone, like exams, and suddenly have too much free time? Most people go on vacation or play games, whatever. I watched a MattKC video about reverse engineering Lego Island and thought, “Yeah, I could do that.”

What a great way to wind down after real intense time…

My target? 3DWalker. An old project from around 2016 made by my friend Sandy.

(Both project name and my friend’s name is changed, as he would literally kill me otherwise ;p)

My goal was simple: I didn’t just want to decompile it, I wanted to create a build environment that produces a byte-accurate replica of the original executable. If I could get the assembly to match 1:1, I could flex with it (what else can you do with a fully reverse engineered shitty OpenGL project from 2016?).

I dragged one of my friends into this. He had already tried RE-ing it years ago and gave up because, and I quote, “it was very much goto hell” But he had a semi-working build.

I didn’t want “semi-working.” I wanted perfection. I wanted to have the same code (or at least a close equivalent) that produced this legendary binary back all those years ago.

The Setup

First step: finding the tools. The game uses SDL2, Assimp, and GLEW. But not the versions you download today. I wish! We are traveling back to the golden age: 2016. (Everything back then was so simple, go look up some summer 2k16 playlist or smth)

I needed GCC 8.2.0. Ubuntu 18.04 didn’t have it. 18.10 did, but good luck finding repos for that. I started pulling my hair out almost immediately.

Dependency hell is real. I tried using Meson, but Meson has standards, and this codebase does not. Meson refused to work with the ancient compiler flags I needed. So, naturally, I did the most logical thing a sane developer would do: I wrote a TypeScript script that generates a Bash script to run the compilation commands.

It actually worked. Sort of. But then libogg started screaming that it couldn’t find a 16-bit type on my platform. (actually, many more libraries didn’t want to work with me)

The Time Machine

It wasn’t just the compiler. I had to guess the exact version of every library Sandy used. My logic was flawless: The first devlog video of the game was uploaded in May 2016. Therefore, every single dependency had to be older than that date because, let’s be honest, Sandy wasn’t the type to update his libraries once they worked.

I pinned down Assimp to version 3.2.0 and GLEW to 1.13.0. Simple, right? Wrong. Version 3.2 didn’t offer pre-built binaries, so I had to build it from source. My build came out to a chonky 15MB. Sandy’s original DLL was a delightful 5.4MB. I spent hours staring at CMake flags, wondering if he used some secret stripping technique or if I was just bad at this. (Spoiler: I was probably just bad at this).

Trashing the binary

I decided to stop guessing what I actually need and look at the evidence. I grabbed the original 3DWalker.exe and threw it into a hex editor and objdump to see what compiler Sandy actually used.

I was expecting something standard. Maybe a nice MSVC build? (I’ve started with mingw to get something going)

Nope.

GCC: (GNU) 4.8.3. Shit.

Okay, calm down, 4.8.3. Simple enough. Sandy is a Windows user, so he probably used Code::Blockscocks. Code::Blocks usually bundles the TDM-GCC compiler.

I went on a spree. I downloaded every version of Code::Blocks released between 2013 and 2017. I built “Hello World” in all of them just to check the compiler signature.

• Code::Blocks 13.12? GCC 4.7.1. Too old.
• Code::Blocks 16.01? GCC 4.9.2. Too new.

Where the hell did he get 4.8.3? It’s like a lost media compiler.

Ubuntu Hypothesis

Then I noticed something weird in the binary’s vendor strings. The way the compiler identified itself… it didn’t look like TDM-GCC. It looked like the GCC you get from a Linux package manager.

Did he build this on Linux? In 2016 ? (This is especially interesting because afaik he was still an avid Windows user, just starting to dip his toes into Linux).

One of my people suggested he might have used Ubuntu or Xubuntu back then. I checked the repo history for Ubuntu.

• Ubuntu 14.04 (Trusty Tahr) shipped with MinGW-w64 v3.something… and GCC 4.8.2.
• Ubuntu 16.04 jumped straight to GCC 5.3.1.

We were close. 4.8.2 is almost 4.8.3. Maybe he updated it?

I went full archeologist. I started digging through Fedora archives (they had 4.8.3!). I searched through ancient mailing lists. I even found a prebuilt MinGW toolchain hosted on Google’s Android source tree that was exactly 4.8.3.

I was creating Docker containers running Ubuntu 14.04, patching repo lists to point to archived servers that were throwing 503 errors because I was basically DDoS-ing them looking for a specific .deb file. I considered buying a bootleg “Ubuntu 14.04 Full Repo DVD” from a Polish auction site just to see if the package was on the disc.

Desperation is a hell of a drug.

I got it!

I finally found it. ubuntu_14_04-mingw64-gcc-4.8.4.

Wait, 4.8.4?

Here’s the stupidest part: On Ubuntu 14.04, if you updated the system GCC, it would sometimes cause the MinGW cross-compiler to report itself weirdly because of how it was linked. I managed to produce a build where the compiler claimed to be the version I needed. (Without changing the version via build options)

I had done it. I had a Docker container with the Holy Grail: a working build environment that matched the timestamps and versions of 2016. I felt like a genius. I had solved the puzzle.

I loaded up the original binary one last time to check some things. I scrolled through the strings, looking for debug paths, just to see where Sandy kept his project files.

C:\Users\Pc.

It was Windows.

It was Windows the whole time.

He didn’t use any Linux machine to build it. He didn’t use some obscure distro. He just had a messy Windows install with a random MinGW version he probably downloaded from a shady SourceForge link, and I just spent four days digital dumpster-diving through Debian archives for absolutely nothing.

I’m going to bed. Next time, we will try to build this on Windows.

P.S. Not actually for nothing, because I found numerous official compilations of GCC 4.8.3 for Fedora and other distros. So I guess I was somewhat successful in the archeology department.