How We Wrote a Self-Hacking Game in C++ by Zachary Canann

For those interested in the nitty gritty details, the rest of this article will be about setting up some self-modifying code. It’s actually pretty easy.

Just a quick note, all code samples have been uploaded to: https://github.com/Squalr/SelfHackingApp

We’re going to leverage two libraries:
FASM, an assembler: https://github.com/ZenLulz/Fasm.NET
UDIS86, a disassembler: https://github.com/vmt/udis86

There’s a few catches as far as the implementation goes. We’ve got an assembler and disassembler. We find an instruction, and disassemble it. We change it to something else, and assemble it back into bytes. Now all we have to do is write those bytes to memory… and the program crashes.

Upon digging deeper, it turns out that the protections for the page of memorythat contain the code is marked as Execute only. It needs to be readable and writable. In Windows, this can be done using the VirtualProtect function in windows.h . In Unix, this is done via mprotect .

Below, we create a function called hackableRoutine(). Notice the line i += 60 . This is the instruction we are going to self-modify. There’s a few macros surrounding it, which simply get the start and end addresses of the code we want to hack. These are used to set up our HackableCode object, which is just a thin wrapper over FASM and Udis86.

At our program entry, we call the hackableRoutine() function once to initialize the hackableCode object. It returns 100, as you might expect from the code above.

Next, we update the hackableCode object and change it’s code to anything we want! In this example, we settle for a simple nop . As you might be able to guess, the second time we call hackableRoutine() , a value of 40 is returned! The i += 60 line has been effectively removed by self modifying code!

Here is my output, although this can change depending on the compiler:

100
mov eax, [ebp-0x2c]
add eax, 0x3c
mov [ebp-0x2c], eax
40

For those with a background in assembly, you may have noticed that 1 nop is far less bytes than the instructioni += 60 . The remaining bytes are filled with nop instructions automatically behind the scenes.

I’m not going to explain the implementation details around theHackableCodeclass — as stated before, it’s really just a thin wrapper over Fasm and Udis86. For reference, I’ll put the code for these at the end of this article.

One thing to note is that there is a limitation to this approach. Setting up the hackableCode object requires that the code be run at least once! This is not ideal for all situations. There should be a solution to this. If you find one, drop a comment below! If no C++ wizards beat me to it, I’ll post a follow-up when I figure it out.

Check out this project on Steam!

HackableCode.h:

HackableCode.cpp