Learning Game Hacking: Developing Cheats with a Simple Example

Types of Cheats and Their Tactics

There are different types of cheats, which can be categorized into several groups.

• External – cheats that operate in a separate process. If we conceal our external cheat by loading it into the memory of another process, it transforms into a hidden external.
• Internal – cheats that integrate into the game’s process using an injector. After being loaded into the game’s memory, the entry point of the cheat is triggered in a separate thread.
• Pixelscan – a type of cheat that utilizes the screen image and patterns of pixel placement to extract necessary information from the game.
• Network proxy – cheats that employ network proxies to intercept client-server traffic, allowing them to retrieve or modify necessary data.

There are three primary tactics for modifying game behavior.

• Game Memory Modification: Utilizing the operating system’s API to locate and modify memory sections that contain desired information, such as health or ammunition.
• Player Action Simulation: The application replicates player actions by clicking the mouse in predetermined locations.
• Game Traffic Interception: The cheat intervenes between the game and the server to intercept data, gathering or altering information to deceive either the client or the server.

Most modern games are developed for Windows, so our examples will focus on this platform.

Creating a Game in C

It’s best to discuss cheats in practice. We’ll create our own small game to practice on. I’ll be developing the game in C#, but I will try to align the data structure as closely as possible to a C++ game. In my experience, it’s quite easy to cheat in games written in C#.

The game’s premise is simple: you press Enter and you lose. Not exactly fair rules, right? Let’s try to change them.

Let’s Dive into Reverse Engineering

We have the game’s file, but instead of examining the source code, we will analyze the application’s memory and behavior.

Each time Enter is pressed, the player’s life decreases by 15. The initial amount of life is 100.

We will study memory using Cheat Engine. This application is used to search for variables within an application’s memory and also serves as a good debugger. Let’s restart the game and connect Cheat Engine to it.

The first step is to generate a list of all occurrences of the value 85 in memory.

Press Enter, and the life points will be set to 70. We will filter out all other values.

That’s the value we need! Let’s modify it and press Enter to verify the result.

The issue is that after restarting the game, the value will be located at a different address. It makes no sense to filter it out every time. You need to use AOB (Array Of Bytes) scanning.

Each time the application is opened, due to Address Space Layout Randomization (ASLR), the structure that describes the player will be located at a new address. To find it, you must first identify a signature. A signature is a set of unchanging bytes within the structure that can be used to search through the application’s memory.

After pressing Enter a few times, the number of lives changed to 55. Let’s find the relevant value in memory again and open the region where it’s located.

The highlighted byte marks the beginning of our int32 number. 37 00 00 00 represents the number 55 in decimal form.

I’ll copy a small region of memory and paste it into a text editor for further analysis. Now, let’s restart the application and find the same value in memory again. We’ll copy the same memory region and paste it into the text editor once more. The goal is to start comparing these to identify the bytes near this signature that remain constant.

Let’s check the bytes before the structure.

As you can see, the highlighted bytes have not changed, which means you can try using them as a signature. The smaller the signature, the faster the scanning process. A signature like 01 00 00 00 is likely to appear too frequently in memory. It’s better to use 03 00 00 01 00 00 00. To begin, let’s find it in memory.

The signature has been found, but it repeats. A more unique sequence is needed. Let’s try ED 03 00 00 01 00 00 00.

To confirm uniqueness, we will achieve the following result:

We need to determine the offset from the signature to obtain its starting address, rather than the address for lives. For now, let’s save the found signature and set it aside for a bit. Don’t worry, we’ll come back to it later.

The Lifecycle of External Cheats

External cheats employ the OpenProcess function to obtain a handle to the target process, allowing them to make necessary code changes (patching) or to read and modify variables within the game’s memory. The functions ReadProcessMemory and WriteProcessMemory are used for memory modification.

Since dynamic data allocation in memory makes it difficult to record the needed addresses and access them consistently, you can use the AOB (Array of Bytes) scanning technique. The lifecycle of an external cheat looks like this:

• Locate the process ID.
• Obtain a handle to this process with the necessary permissions.
• Find memory addresses.
• Apply patches if needed.
• Render the GUI, if there is one.
• Read or modify memory as needed.

Creating an External Cheat for Your Game

C# uses the P/Invoke technology to call WinAPI functions. To start working with these functions, you have to declare them in your code. I will be using ready-made declarations from pinvoke.net. The first function to be used is OpenProcess.

The next function is ReadProcessMemory.

Now, let’s discuss the memory reading function WriteProcessMemory.

We are faced with a problem: to find a pattern, it’s necessary to gather all the memory regions of a process. For this, we need a function and a structure. The function is VirtualQueryEx:

Structure MEMORY_BASIC_INFORMATION:

Now it’s time to start coding the actual cheat. First, let’s locate the game.

Next, we’ll open the file descriptor for our game.

Let’s integrate all of this into the initial code.

We’ll find the process ID, then obtain its handle, and if necessary, display an error message. The implementation of CriticalError(string) isn’t that important.

After this, we can move on to pattern searching in memory. We’ll create a general class containing all the functions needed for working with memory, which we’ll call MemoryManager. Then, we’ll create a class called MemoryRegion to describe a memory region. The MEMORY_BASIC_INFORMATION structure includes a lot of unnecessary data that should not be passed on, so I’ve extracted these into a separate class.

This is all we need: the starting address of the region, its size, and its protection settings. Now, how do we obtain all the memory regions? Let’s find out.

1. Retrieve information about the memory region at address zero.
2. Check the status and protection of the region. If everything is fine, add it to the list.
3. Retrieve information about the next region.
4. Check and add it to the list.
5. Repeat the cycle.

Once we have the regions, we will scan them for the pattern we need. The pattern consists of two types of segments: known and unknown (changing byte). For example, 00 ?? ?? FB. We’ll create an interface to describe these segments.

Now let’s describe the section that has a known byte.

Let’s do the same thing with the second type.

Now let’s parse the pattern from the string.

As done previously, check the type of pattern part, parse it if necessary, and add it to the list. It’s important to verify the functionality of this method.

Now we need to teach our MemoryManager to read memory.

Initially, I wrote an elegant function using Linq to scan memory. However, its execution was quite slow. Then, I rewrote the method without using that technology, and everything worked much faster. The result of the optimized function:

The result of the original function:

Now, let me share some wisdom gained at this stage: don’t be afraid to optimize your code. Libraries don’t always offer the fastest solutions. Here’s the original function:

Revised function: just use Array.Copy().

This function searches for a pattern within a memory region. The following function utilizes it to scan the entire process’s memory.

Let’s add two functions for reading and writing a 32-bit number from memory.

Everything is now set up for pattern detection and writing the main cheat code.

Locate the pattern in memory, then find the player’s lives address.

Reading the number of lives:

Why not give the player almost infinite lives?

And once again, we’re counting player lives for demonstration purposes.

Checking

Let’s start our cheat, and then launch the game.

Let’s try pressing Enter in the “game.”

The cheat is working!

Creating Your First Code Injector

There are many ways to make a process load our code. You can use DLL Hijacking, or SetWindowsHookEx. However, we’ll start with the simplest and most well-known function — LoadLibrary. LoadLibrary makes the target process load the library by itself.

We will need a handle with the necessary permissions. Let’s start preparing for the injection. First, we’ll ask the user for the name of the library.

Next, we will ask the user for the process name and find its ID.

This code will have issues with processes that have the same name.

Now let’s move on to the first injection method.

Implementing LoadLibrary Injection

Let’s start by examining how this type of injector works.

1. First, it reads the full path to the library from the disk.
2. It converts the path into a string.
3. Then we retrieve the address of LoadLibraryA(LPCSTR) using GetProcAddress(HMODULE, LPCSTR).
4. Allocates memory for the string within the application and writes the string there.
5. Afterwards, it creates a thread at the LoadLibraryA address, passing the path as an argument.

To proceed, you need to specify the imports: OpenProcess, ReadProcessMemory, WriteProcessMemory, GetProcAddress, GetModuleHandle, CreateRemoteThread, and VirtualAllocEx.

First, we need to open a handle with full access to the process.

Let’s convert our string into bytes.

Next, you need to allocate memory for this string.

A process handle handle is passed to the function, with _MAX_PATH as the maximum path size in Windows, which is 256. We specify that the memory can be written, read, and executed. Then, we write a string into the process.

Since we’ll be using the LoadLibraryA function to load the library, we need to obtain its address.

Everything is ready to start the injection process. All that remains is to create a thread in the remote application:

The injector is ready, but we will only test it after developing a simple library.

Building the Foundation for an Internal Cheat

Let’s switch to C++! We’ll start with the entry point and a simple message using the WinAPI. The entry point of a DLL should accept three parameters: HINSTANCE, DWORD, and LPVOID.

• HINSTANCE — refers to a library instance.
• DWORD — indicates the reason for the entry point call (loading and unloading of the DLL).
• LPVOID — a reserved value.

Here’s what an empty library entry point looks like:

Let’s start by examining why the entry point is being invoked.

The fdwReason argument will be DLL_PROCESS_ATTACH if the library has just been attached to the process, or DLL_PROCESS_DETACH if it is in the process of being unloaded. For testing purposes, let’s display a message:

Now we can test the injector and this library. Run the injector and enter the names of the library and the process.

Now let’s write a simple class using the singleton pattern for cleaner code.

Now for the code itself: the default constructor and the singleton pattern.

Here’s a simple entry point code.

I must say that the next part took the most time. One small mistake led to a huge waste of time. However, I’ve learned from it and will explain where such an error can occur and how to detect it.

We need to identify a pattern within the game’s memory. To achieve this, we will first iterate through all the memory regions of the application and then scan each of them. Below is an implementation for retrieving the list of memory regions, but it only applies to our own process. I have previously explained how it functions.

For each identified region, this code calls the function find_pattern_in_range, which searches for a pattern within that region.

Initially, the function parses the pattern.

Then the scanning process begins.

I used a vector of int to store pattern data, where -1 indicates that any byte can be present. I did this to simplify and speed up the pattern search without having to convert the same code from an external cheat repeatedly.

Now a few words about the error I mentioned earlier. I kept rewriting the pattern search function until I decided to take a look at the memory region search function. The issue was that I was comparing the memory protection completely incorrectly. Here’s the initial version:

The code was designed to accept only pages with readable/executable memory and readable/writable/executable memory. All other types of pages were ignored. The code was then modified to the following:

This function has started identifying all the necessary memory pages.

I discovered this error when I started checking memory pages in the application using Process Hacker and Cheat Engine. My pattern was in one of the very first memory regions with execution protection, which is why it was never found.

Now, having identified the pattern, we can store it in our class field.

After this, the function internal_cheat::run() will be called, which is responsible for executing all the cheat features.

We simply retrieve the player’s life address from our pattern and set it to the maximum value (INT_MAX) every 100 milliseconds.

Testing Our Cheat

Launch the game and inject the library.

Let’s try pressing the Enter key a couple of times.

Our lives haven’t changed and everything is working perfectly!

Summary

Any element of a game that is processed on our computer can be modified or even removed. Unfortunately or fortunately, gaming companies don’t always prioritize anti-cheat measures, which opens the door for us, the cheaters.