5 minute read

In high school and later in university I had what most people would consider a rather odd hobby: video game hacking. More precisely, I was into creating cheat codes for Playstation games that would, for example, make you invincible against enemy attacks or allow you to drive through walls in your favorite racing game. However, I’m not talking about the kinds of cheat codes that can be activated by entering secret passwords or pressing controller buttons in a particular sequence. I’m talking about modifying the game’s data and program code at runtime by reverse engineering its mechanics.

In the late 90s and early 2000s, you could buy off-the-shelf cheat devices for Playstation 1 (PSX) and Playstation 2 (PS2), like the Xploder and CodeBreaker. Those devices worked by injecting a small program into memory between booting the console and starting a game. That program would then be running in the game’s background with full access to its memory. It was relatively easy for cheat devices to “freeze” things like energy points, ammo, money, etc. by constantly writing the same values to certain memory addresses (protections such as ASLR were unheard of at the time).

Cheat devices like the Xploder/Xplorer could be connected to the parallel I/O port of the PSX

Best of all, the first cheat devices for PSX let you find your own cheat codes. This process boiled down to dumping the game’s RAM to a PC (via printer cable) where it could be searched and compared with other dumps by special “trainer” software. We did all of this on – hold your breath – Windows 98. There was a hex editor with a live view of the game’s memory; you could manipulate bytes and see the effect instantly. You could also set breakpoints, which was by far my favorite feature as it made for very sophisticated cheat codes – so-called assembly hacks that would overwrite game logic. Over the years, I’ve created thousands of codes this way.

The powerful X-Link trainer software for PSX

When the golden age of PSX hacking was over, something bad happened: all of a sudden, companies stopped sharing their tools and started encrypting everything. It was unfortunate, but at the same time, it provided an opportunity for me to improve my limited programming and reverse engineering skills. So it happened that we wrote our own software for hacking PS2 games. Along the way, we cracked about anything we could get our hands on, from proprietary encryption schemes to anti-cheat protections.

All of this was a ton of fun. As a matter of fact, it’s how I got into computers and programming in the first place. But it’s more than that, much more. Here are 10 things I learned from hacking video games, most of them only obvious in hindsight:

  1. Programming. I taught myself the C programming language to write my first “proper” hacking tools. All the cool kids were using it for low-level system stuff. This was also when I became a fan of command-line tools. (These days, I dig Go and Rust, probably for similar reasons.)

  2. Bits and bytes. Video game hacking helped me understand: hexadecimal numerals, Boolean algebra, binary formats such as ELF, memory layout of executables, interrupts, breakpoints, assemblers, disassemblers, hex editors, and a ton more.

  3. Cryptography. Poking around the Xploder PSX code encryption was my first experience in cryptography. I figured out where the device stored the unencrypted codes in RAM and did a dumb brute-force attack to break the different schemes. Since then, I’ve been fascinated by crypto.

  4. Networking basics. The PS2 comes with an Ethernet port/adapter, which is what we used to transfer memory dumps to a PC using a simple client-server implementation. I had to learn the basics of TCP/IP, DNS, network programming, etc. to achieve that.

  5. GNU/Linux. Writing code for game consoles usually involves cross-compiling under a Linux-y environment. That’s how I was introduced to gcc, bash, make, grep, and other GNU utilities – first on Windows via Cygwin and MinGW, later on Ubuntu.

  6. Open source. I remember how a hacker called Parasyte made the source code of his tools available to the public. I learned so much from his C code that I started open sourcing my programs in the same way. Homebrew made sure I always had a plethora of side projects going on. I also enjoyed the social side of open source and bulletin boards.

  7. Version control. Subversion, Mercurial, Git. I tried them all. If I remember correctly, I was among the first who moved homebrew over to GitHub. Using GitHub and other platforms also sparked my interest in writing good documentation.

  8. Curiosity. I believe that my strong desire to know or learn something partially stems from tinkering with video games back in the days.

  9. Freedom. Another important motivator. I deliver my best work when I have the freedom to accomplish tasks my way. I learned this early on. But there’s also freedom in the sense that I was convinced that game hacking had to be free. No code encryption. No proprietary formats. An end to control.

  10. Grit. I used to spend weeks reverse engineering a video game or cheat device. Today, I still enjoy solving tricky technical problems over a long period – without losing myself in details.

I didn’t put this list together as a means to brag – it’s not that impressive anyway. No, I mainly wrote this for nostalgia (remembering the good old days) and introspection (trying to understand myself better).

While times have changed – I barely pick up a game controller anymore – I probably wouldn’t be the software engineer I am today if it wasn’t for game hacking. In fact, I may not even be a programmer at all. It still amazes me how such a geek hobby ultimately turned into a lifelong passion and career.

In 2009, I did a Q&A with the founder of GameHacking.org. While some of the discussed topics might not make sense to someone who has never hacked Playstation games, I think the interview still provides a bit more context. Back in the days, I used the nickname misfire. Naming is hard.