Understanding Memory - Game Hacking

Question

I am trying to start learning how to code game cheats in C++. But at the moment I want to understand the layout of memory and etc - I have a few questions to ask and will use the game Assault Cube as reference. Please help me and explain anything in simple form. I am new.

1) Lets say the Image Base address of ac_client.exe is at 0x4000000 - does this simply means that the beginning of the process is allocated at that memory address?

2) Next is the Image Base + Offset (&ac_client.exe + 0x10F4F4) - does the offset mean it is taking you to a location or function inside the process from the starting point?

3) In Cheat Engine I loaded Assault Cube. I searched for my health value. I found the dynamic address of the health. Now I will need to find the static address, since there is no direct pointer to health, I click on “find what accesses this address” option - does this mean I am trying to find a function that is using or passing in my dynamic health variable?

4) After finding the static address for health value. I have found the offset which is 0xF8. Also ac_client.exe + 0x10F4F4 -> 0x50F4F4 - people say that 0x50F4F4 is the local player base class but how do I know this if I was not told this? Does this also mean all game variables are all in classes?

Still kind of confused could someone explain how it all works visually.

Answer 1

1) Lets say the Image Base address of ac_client.exe is at 0x4000000 - does this simply means that the beginning of the process is allocated at that memory address?

Yes, but more specifically, it's the base address of the PE (Portable Executable) once mapped into memory. So at the address base you have the PE header and then a lot of structures, then the sections of the executable, etc.

2) Next is the Image Base + Offset (ac_client.exe + 0x10F4F4) - does the offset mean it is taking you to a location or function inside the process from the starting point?

Technically this is called a RVA (Relative Virtual Address; it's relative to the base address of the module): there a difference between an offset (which applies to the flat file on the disk) and a RVA (which applies to the file once mapped in memory). Once an executable is mapped into the memory (though what is called the OS loader) it has a different "shape" than on the disk, so an offset is not the same thing as a RVA.

To answer your question, yes, it points somewhere in the module named ac_client.exe.

3) In Cheat Engine I loaded Assault Cube. I searched for my health value. I found the dynamic address of the health. Now I will need to find the static address, since there is no direct pointer to health, I click on “find what accesses this address” option - does this mean I am trying to find a function that is using or passing in my dynamic health variable?

Exactly.

I'm not familiar with Cheat Engine but this can be done in various ways:

1. Statically: by disassembling the code and searching for any cross reference which point to the location of interest. Basically, when the code is accessing the value you are searching for, it does it through some instructions which have a memory operand pointing directly (or not very far) to the interesting location.

2. Memory scanning: the engine search directly in the process address space for anything that points (or not very far) to the interesting location. If it happens to be in a code section, you have a match. Otherwise (e.g. somewhere else in the data section or in the heap) try to find any code location which points to this new location. rince and repeat until you find something.

3. A mix of the above.

4) After finding the static address for health value. I have found the offset which is 0xF8. Also ac_client.exe + 0x10F4F4 -> 0x50F4F4 - people say that 0x50F4F4 is the local player base class but how do I know this if I was not told this? Does this also mean all game variables are all in classes?

If the game is closed source, you have to reverse engineer it to understand the ins and outs of the game to be able to say this. It takes a lot of time, is difficult, and you never have the same 'names' that the original programmers intended. "Names" (class names, function names, variable names, etc.) do not make it to the final binary: you loose the ability to see class names and their locations.

There are still a few cases when you can recover those names, at least in C++ (e.g. when you have something called RTTI) or if symbolic information is available (game developers never ship debugging information except in a few cases).

In your case (as far as I can see the game is open source and in C++), you can compile the game for yourself with debugging support (technically for Windows it means symbolic support by producing a PDB when linking the executable). Then put the game into a symbolic debugger (e.g. Windbg) or disassembler then ask the tool what is the function / class lying at this precise offset / RVA. It really is simple as that when you have symbolic information.

Some languages (e.g. C#, Java) can be decompiled (!= disassembled), and you can retrieve directly all the names (classes, function, variables, etc.), unless the final binary is protected against decompilation.

Does this also mean all game variables are all in classes?

This is a rather tough question with a lot of ramifications: first, it depends on the language used. If it's an OO language then probably yes, except for global, static and local variables. Some languages don't have the concept of classes, so the memory layout of objects manipulated by the game might be totally different between a C game and a C++ one.

Another important point is that you might also not have the content directly in a class, but rather pointed to by a member of the class.

Let say you have a game in which the player have an inventory (so the class 'Player' has a variable member named 'inventory'), which will probably be managed by some kind of complex structure (e.g. an associative container or even something more complex). Since those complex structures are allocated dynamically by the game (e.g. new in c++) all the objects in the inventory end up on the heap but not directly in the class itself. The allocation is pointed to (not necessarily directly) by the "inventory" member but the objects in the inventory are elsewhere in memory.