I’ve been hard at work on Squally, a game in C++ to teach hacking. However, this creates a small problem: If we want to publish the game on Steam, then we can’t force people to download hacking tools first. Our solution? Put the tools inside the game, and let the game hack itself.

This had another unintended consequence. If the game hacks itself, then we need some low-level control over the game — and for that, we need a low-level language. C# and Unity were no longer an option, so we had to start looking at some C++ options.

We narrowed it down to two options. The first option we considered was Unreal Engine. Unfortunately, this engine is not very great for 2D games. Also, Unreal takes 5% of game revenues, which does not make sense if it does not add value. For these reasons, we settled on a lesser known engine called Cocos2d-x.

To emulate real hacking tools, there are only two things that we needed. First, a disassembler for converting the raw machine code into human-readable x86 assembly (or at least hacker-readable). The second thing we need is an assembler to do the opposite.

With these two tools, we effectively have a game that can read and write its own code. We just have to tell the game exactly where to look, which we will explore later.

Reversing a healing spell in Squally, by changing `inc` to `dec`.

Of course by letting users rewrite the code in assembly, the user can easily crash this game! But as any hacker knows, crashing things is just part of the job.

However, there are some cool ways to mitigate this. One option is to save the state of the program (registers/stack) before the hackable region of code, and restore it after it executes to prevent silly mistakes.