Back in the glory days of late 90’s early 00’s, back when nu-metal was getting to its peak, and we as teenagers were caffeinated off Mountain Dew and jamming to favorite band appearances on MTV’s show the Farmclub.com hosted by Matt Pinfield.
In this era of history, we had color-coded RCA cables from our consoles jacked into the TV. I can recall the living room TV not even having RCA jacks and having to use a coax adapter just to get my N64 to appear on the screen! WILD. If I have totally lost you already, don’t worry, these days were 3 decades ago 😒. Over the years, we have been able to relive that nostalgia of retro video games in creative ways. Whether by original hardware, or, more widely popular these days, via emulation. This requires separate pieces of software, such as the ROM, which can be described as a digital copy of the game cartridge. Then, there is the emulator, the other piece of software required, and that is what pretends to be the console, recreating the original hardware all as software on the PC, therefore the ROM thinks it’s running on a real N64. Pretty neat stuff really, as the idea of converting hardware to software has taken over several industries, for several generations.
So, if that’s true, and we have been playing all these first party games on PC since late 90’s, then what’s going on now? Why is this blog-worthy today? There’s new shift in the effort of getting first party games to run on the PC, and the exciting part of this new shift is that it aims to cut out the emulator software entirely. The game isn’t pretending to run on an N64 anymore, it’s running directly on your PC, like any other application. That’s the shift that makes this worth discussing.
At this point, you might be thinking, “we’ve been reverse engineering software for decades!” True! But not at this rate. The big decomp projects teams (SM64, Ocarina of Time, Perfect Dark) know this better than anyone. Their work was done through years of painstaking reverse engineering, hand-matched assembly to C, function by function. Now AI is accelerating what used to take years.
So, now that we have more games being decompiled, and more variety of the same games being decompiled, what does that mean? Well, if we were all just going to grab the same source, compile it, and run the same game, then what’s the point? The point is that once you have compilable C code, we can change it. And people are. We are already seeing retro games recompiled with ray tracing, uncapped framerate, improved lighting, and even online multiplayer features added. Truly amazing stuff. But… are there dangers? If so, what are the dangers?
The Fingerprint That Falls Apart
Let’s start by talking about fingerprinting files. We have a system that helps ensure a file has not been tampered with. By hashing a ROM file, we get a specific value based on the contents of that file, no matter the actual name of the file. So, this process ensures someone grab a ROM file from somewhere and verify it was not corrupted, tampered, etc. This worked well in this scenario, as only a few actual decomps existed, and it was easy to verify.
Now, however, with all the new versions of decompiled games creates a hash nightmare. Let’s say hypothetically we have two people who recompiled the same game. Will those hashes match? Very unlikely, as all it takes is one character, variable, function to be different to produce different file hashes. If one copy has an extra feature that the other copy does not, that will change the hash value as well. Maybe a victim downloads a copy of a recently recompiled game that comes with 4K, DLSS, uncapped framerate, and unknowingly, access to their personal computer! YIKES! Can’t make such a statement without proof of concept though, so get your favorite black hoodie on, because we abouts to build one.
Towards the end of the N64 era, Rare dropped a gem game, “Perfect Dark”. This game required a special hardware upgrade called the “Expansion Pack” that provided the console an extra… 4MB of RAM… FOUR… MEGABYTES… and it cost us. Oh yea, we shelled out ~$30 for something that could hold like, 1 mp3 file. Mid 2024, at The Game Awards, was the first time I became aware of a Perfect Dark 2, a friggin sequel announced 20+ years later. It may not be Battletoads or Double Dragon, which deserve their own resurrecting, but it blew my mind to see something come up from so long ago getting a sequel. I was hyped. But then, literally one year later, the sequel was cancelled, and I was crushed. So, in the spirit of Perfect Dark, it was selected to be the vehicle of this demonstration.
Once we track down the desired files and get them downloaded, the directory would probably look something like this:
All the tools needed to compile the game and run on Windows OS, skipping the emulator entirely. We’ll do a normal build quick and ensure this is true, and that the game can run.
No loading a ROM into the emulator needed, running like a native Windows PC game. Perfect, perfect Dark. Ok, now on to our next test. The next goal is to see if we can embed some code that does some that we want it to do. Something easy, like, launching the calculator application. We have all the source code, so now to figure out where we want our code to sit.
Looking into the src folder, there’s a ton of C source code here. Thousands of lines of code exist just within the C files here, so it should be easy to tuck in some extra lines of code here somewhere. Now only to decide where a good place is! We could dig in deep, look for some kind of specific condition, maybe on game start, game exit, when a button is pressed, when the player dies, or even better, hide it in some kind of online interaction code. In this demo though, just going to throw our code into the video.c file. Somewhere towards the bottom, a bit hidden and XOR encrypted for funzies.
Recompile, and test to see if the calculator application automatically launches when we run the game again.
It worked! It launched fast, and the game loaded over it, might have missed it if you blinked! Ok, now to expand off that last goal. Turn that calculator code into real real remote access.
Enter the C2
For our next trick, we’re loading up ol’ trusty Sliver as our C2. One of our favorite features of this framework is just how well custom stagers work to pop a session. Let’s dial it up. For this, we’re dropping in some custom process hollowing C code. With a Sliver HTTP server stood up, and a proper implant parameter, we’re ready to access.
Perfection! Perfection-Dark-Hacked! WOOO. As much fun as we have provided these kinds of research and writeups, we hope this helps spread awareness of the risks. Now that we have three separate compiled versions of the game, we can check out the hash comparisons discussed earlier.
All different. Just to prove that someone can decompile, or grab a pre-compiled source code, claim to add in a feature, or even do add in a feature, add some malicious code, compile and share. Would you know? Would you review thousands of lines of code for something suspicious?
That’s a wrap! Now we are ALL PREPARED in case SOME MAAAJJJOR CONSOLE EXCLUSIVE GAME RELEASE COMES OUT, oh, idk, SOON, like MID-ish NOVEMBER, and we ALLLLL WANT TO PLAY IT ON PC, we will MAYBE think twice about downloading the recompiled PC version … right? RIGHT? 🤣🤣🤣
Thanks for stopping by! Join us next time for more hackery beezzkneesss!
P.S. RIP Perfect Dark 2, they done did you wrong 😭