Howdy mr skid,
If you thought you can learn game hacking to get an unfair advantage, this is not the right blogpost for you. If you are genuinly interested in getting a more in depth insight into the art of game hacking and defending alias anti cheating, then you can buckle up, since your are in for a treat. We will walk trough common and widespread techniques of how to perform game hacking and how to detect those actions step by step.
What is Game Hacking?
We need to clearly define this term, we are not talking about cheat codes, easter eggs or abusing bugs. We are talking about actually manipulating the games memory, network traffic or game files in order to gain an unfair advantage. We will even focus on the most important part of game hacking, manipulating or reading the games memory, where valuable information about the games and players are stored.
Why are we not further diving into packet editing, AI cheats or game file manipulation? Finding a way to intercept, decrypt/recrypt and manipulate the games network communications is a very rare occasion and we should not solely rely/focus on this. In addition many server sided validations render any obvious malicious manipulations useless. But keep in mind that manpulating anti cheat network communications can help bypassing anti cheats for example, if the server doesn't recieve a detection of X, it can't ban us for example. We will also not cover plenty of other detection vectors like overlay usage, for example if a topmost transparent window is created to draw the wallhack onto, it could easily be enumerated by an anti cheat, therefore attackers hijack other common overlays like nvidia or try to use ingame drawing functionalities. We are also simply not covering AI cheating, since its mostly very bad and technically not as interesting, they only detection vector on the techincal side is the detection of manipulated mouse input, from a vulnerable driver or kmbox. (Hardware tool which sends manipulated mouse commands)
Why is memory so important?
In the games memory many important informations are stored, since not everything can be handled server sided, for example the world positions of ingame entities like players, theire health, viewangles of our own entity and so on. With reading these values we basically can obtain the actual Locations of all entities and manipulate our own viewangles and so on. Game hackers will programm a cheat software, which reads the memory within an infinite loop, calculate the world -> screen coordinates and draw enemies onto theire screen, which is called ESP or Wallhack. In addition they can also adjust theire own viewangles or mouse position to the enemies position, which essentially is an aimbot.
Lets start...
1 Reading/Writing memory the easy way - External Memory access
ATTACKING
An Attacker can open a Process Handle and perform standard Memory Reads / Writes at a certain Address within the memory, to obtain or overwrite its data.
With these basic Functions attackers can obtain any information they want from a game process, the only "challenge" is to reverse engineer the actual interesting memory addresses. Therefore signatures or offsets are created, to achieve some sort of redundance to avoid having to reverse the actual address every game restart. Offsets being the offset of the base address of the actual process which is read/written to in memory.
DEFENDING
Defenders will implement solutions to detect access to memory or components related to it. For example can one detect any open handles to a process and block or just "detect" and suspend them. This is done with basic Windows API Functions like NtQuerySystemInformation with the SystemHandleInformation parameter. In addition defenders can setup memory page guards with virtual protect windows function, to prevent memory reads/writes onto certain regions, from an external poiont of view this works great, but once an attacker is operating from within a process its rendered useless since the page guard drops automatically after first trigger, we can only monitor access to the guarded pages with setting up exception handling and monitoring.
ATTACKING
The Attackers are mad that creating a direct handle to the games process fails or is detected, but they figured that hijacking an already open and valid handle with the correct granted access works too. Attackers can also enumerate handles and can just inject/abuse another process and its handle to perform the memory interactions. With injecting I mean a basic DLL manual map injection into another process for example.
DEFENDING
Wow the defenders are astonished by the creativity of the attackers, they can now not trust any other process and we could implement our own injections and monitorings to all required external processes and block anything with the common "zero trust policy". This job just got incredibly hard. We need to deeply monitor any open handles to our game process and verify the granted access rights periodically, in addition we need to verify the handles and external processes integreties. We can also start implementing heuristic and behavioral detections for abnormal handle counts, access patterns which could indicate handle hijacking attempts etc.
2 Reading/Writing memory in house - Internal Memory access
ATTACKING
Attackers love to directly DLL inject into our process to make use of all our resources and game functionalities. Theire cheats can work on a much more detailed level and with a highly increased efficency. They basically step into our livingroom and sit right next to us or within us in memory. This allows them easily to disable protected pages and modfiy the games memory however they want.
DEFENDING
We can try to detect the attempt of injecting a dll / library, check / search for a dll sitting in our livingroom or monitor certain function calls to detect intruders. We start of with hooking certain windows API functions like basic LoadLibrary, LdrLoadDll, NtMapViewOfSection to monitor for suspicious activity. Hooking important functions can immensily help monitoring activities within our process, but within usermode we are immensily limmitied within our specific process access scope. We can periodically scan our loaded dll's with EnumProcessModules or a simmilar function to list loaded modules and validate their paths and signatures. If a dll was manually mapped we can also just scan our memory and perform integrity checks, which sounds easier then done. I will just list some buzzwords of options we have, which all can work but also could easily be bypassed. Scan memory for PE headers with VirtualQuery for example, check for missing imports and export directories, analyze memories protection flags like look for PAGE_READWRITE, which are unusual and could indicate an manual mapped executeable memory section, check for unusual memory regions and characteristcs, analyze threads and thread start addresses, which might not be in usual memory region, direct integrity checks on loaded modules etc.
ATTACKING
The job of an attacker is to identify the counter measures and swim around them, within usermode its basically a cat and mouse game but only experienced game hackers find new ways of bypassing counter measures. The thought process of an attacker is to find alternative and uncommon / unknown ways of access the memory , injecting a dll for example or hiding memory within a process for example. With finding new alternative solutions potential counter measures do not work on them.
DEFENDING
Simmilar to the attacker defenders also regularly reverse engineer theire attackers softwares to learn everything about theire new techniques of doing certain actions. Thats why the anti cheat company battleeye is actively looking for reverse engineers.
3 Reading/Writing from kernel- Kernel Memory access
ATTACKING
Attackers got sick of the cat and mouse game and moved to kernel, from kernel attackers can basically hook any system function and implement theire own memory functions which are completly invisible from usermode access scope. For example an attacker can hook vulnerable system drivers (theres alot) and abuse them to perform its actions.
DEFENDING
The only chance a usermode programm has, is to identifiy actual written changes made to the games memory, but reads are untraceable. We can try to come up with other detection vectors like detecting overlays or signatures of cheating software, but with polimorphic code, unique builds and maybe also from kernel rendered overlays, we need to surrender. OR WE COMEBACK stronger with our kernel driver. With also having full access to the system we can also hook any sysfunction, we can enumerate other kernel drivers or also enfore strict rules of no test signed / unsigned drivers allowed which forces attackers to sign theire drivers. (Basically either costs much money and getting a free/leaked certificate is hard so once detected its hard to obtain a new one) We can also enforce secure boot, TPM and more which makes many not well developed drivers unuseable.
ATTACKING
Attackers feel a lil dizzy after the huge change of such an intrusive coperate anti cheat but they react with manually mapping the driver with kdmapper, which allows them to use unsigned drivers on a normal non testmode system. In addition they can also just make sure theire driver loads before the anti cheat driver, which gives them the edge over any anti cheat driver due too it being able to perform actions before any anti cheat driver is loaded, like spoofing hardware components, already placing hooks to malform function return data for example etc. basically rendering the anti cheat driver useless.
DEFENDING
Defending anti cheat drivers have an edge over malicious drivers due too their "official" signed nature and they can most of the time load before any malicious drivers when the operating system is working as intended. Windows for example has ELAM in place, and early launch anti-malware feature and is obviously also trying to prevent malicious drivers/rootkits. Its as easy as just setting Startype BOOT_START for example within the driver INF file.
With our newly gained power we can now also just actually globally hook system functions and monitor any memory related functions, enumerate any processes etc.
ATTACKING
The Attackers main goal now against other kernel anti cheats is to load before the anti cheat driver or find 0 day exploits, which is rather unlikely. Attackers used EFI bootkits to execute low level code before the operating system even fully loads, which makes it rather hard for anti cheat drivers to do anything against it if its not known. At such a level an attacker can possibly manipulate its hardware ID's, disable/manipulate PatchGuard, hide Systemthreads from other processes etc.
DEFENDING
The cat and mouse game continues... but anti cheat developers have an edge over attackers due too the operating system working with them against malicious actors.
4 Reading/Writing from external hardware- Direct Memory Access devices
ATTACKING
If you thought you can learn game hacking to get an unfair advantage, this is not the right blogpost for you. If you are genuinly interested in getting a more in depth insight into the art of game hacking and defending alias anti cheating, then you can buckle up, since your are in for a treat. We will walk trough common and widespread techniques of how to perform game hacking and how to detect those actions step by step.
What is Game Hacking?
We need to clearly define this term, we are not talking about cheat codes, easter eggs or abusing bugs. We are talking about actually manipulating the games memory, network traffic or game files in order to gain an unfair advantage. We will even focus on the most important part of game hacking, manipulating or reading the games memory, where valuable information about the games and players are stored.
Why are we not further diving into packet editing, AI cheats or game file manipulation? Finding a way to intercept, decrypt/recrypt and manipulate the games network communications is a very rare occasion and we should not solely rely/focus on this. In addition many server sided validations render any obvious malicious manipulations useless. But keep in mind that manpulating anti cheat network communications can help bypassing anti cheats for example, if the server doesn't recieve a detection of X, it can't ban us for example. We will also not cover plenty of other detection vectors like overlay usage, for example if a topmost transparent window is created to draw the wallhack onto, it could easily be enumerated by an anti cheat, therefore attackers hijack other common overlays like nvidia or try to use ingame drawing functionalities. We are also simply not covering AI cheating, since its mostly very bad and technically not as interesting, they only detection vector on the techincal side is the detection of manipulated mouse input, from a vulnerable driver or kmbox. (Hardware tool which sends manipulated mouse commands)
Why is memory so important?
In the games memory many important informations are stored, since not everything can be handled server sided, for example the world positions of ingame entities like players, theire health, viewangles of our own entity and so on. With reading these values we basically can obtain the actual Locations of all entities and manipulate our own viewangles and so on. Game hackers will programm a cheat software, which reads the memory within an infinite loop, calculate the world -> screen coordinates and draw enemies onto theire screen, which is called ESP or Wallhack. In addition they can also adjust theire own viewangles or mouse position to the enemies position, which essentially is an aimbot.
Lets start...
1 Reading/Writing memory the easy way - External Memory access
ATTACKING
An Attacker can open a Process Handle and perform standard Memory Reads / Writes at a certain Address within the memory, to obtain or overwrite its data.
C++:
//with OpenProcess and a valid process id we can open a process handle
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
//with passing a buffer pointer and the process handle we can read the process memory at a certain address
ReadProcessMemory(hProcess, address, &buffer, sizeof(T), nullptr)
//Simmilarly for writing process memory
WriteProcessMemory(hProcess, address, &value, sizeof(T), nullptr)With these basic Functions attackers can obtain any information they want from a game process, the only "challenge" is to reverse engineer the actual interesting memory addresses. Therefore signatures or offsets are created, to achieve some sort of redundance to avoid having to reverse the actual address every game restart. Offsets being the offset of the base address of the actual process which is read/written to in memory.
DEFENDING
Defenders will implement solutions to detect access to memory or components related to it. For example can one detect any open handles to a process and block or just "detect" and suspend them. This is done with basic Windows API Functions like NtQuerySystemInformation with the SystemHandleInformation parameter. In addition defenders can setup memory page guards with virtual protect windows function, to prevent memory reads/writes onto certain regions, from an external poiont of view this works great, but once an attacker is operating from within a process its rendered useless since the page guard drops automatically after first trigger, we can only monitor access to the guarded pages with setting up exception handling and monitoring.
ATTACKING
The Attackers are mad that creating a direct handle to the games process fails or is detected, but they figured that hijacking an already open and valid handle with the correct granted access works too. Attackers can also enumerate handles and can just inject/abuse another process and its handle to perform the memory interactions. With injecting I mean a basic DLL manual map injection into another process for example.
DEFENDING
Wow the defenders are astonished by the creativity of the attackers, they can now not trust any other process and we could implement our own injections and monitorings to all required external processes and block anything with the common "zero trust policy". This job just got incredibly hard. We need to deeply monitor any open handles to our game process and verify the granted access rights periodically, in addition we need to verify the handles and external processes integreties. We can also start implementing heuristic and behavioral detections for abnormal handle counts, access patterns which could indicate handle hijacking attempts etc.
2 Reading/Writing memory in house - Internal Memory access
ATTACKING
Attackers love to directly DLL inject into our process to make use of all our resources and game functionalities. Theire cheats can work on a much more detailed level and with a highly increased efficency. They basically step into our livingroom and sit right next to us or within us in memory. This allows them easily to disable protected pages and modfiy the games memory however they want.
DEFENDING
We can try to detect the attempt of injecting a dll / library, check / search for a dll sitting in our livingroom or monitor certain function calls to detect intruders. We start of with hooking certain windows API functions like basic LoadLibrary, LdrLoadDll, NtMapViewOfSection to monitor for suspicious activity. Hooking important functions can immensily help monitoring activities within our process, but within usermode we are immensily limmitied within our specific process access scope. We can periodically scan our loaded dll's with EnumProcessModules or a simmilar function to list loaded modules and validate their paths and signatures. If a dll was manually mapped we can also just scan our memory and perform integrity checks, which sounds easier then done. I will just list some buzzwords of options we have, which all can work but also could easily be bypassed. Scan memory for PE headers with VirtualQuery for example, check for missing imports and export directories, analyze memories protection flags like look for PAGE_READWRITE, which are unusual and could indicate an manual mapped executeable memory section, check for unusual memory regions and characteristcs, analyze threads and thread start addresses, which might not be in usual memory region, direct integrity checks on loaded modules etc.
ATTACKING
The job of an attacker is to identify the counter measures and swim around them, within usermode its basically a cat and mouse game but only experienced game hackers find new ways of bypassing counter measures. The thought process of an attacker is to find alternative and uncommon / unknown ways of access the memory , injecting a dll for example or hiding memory within a process for example. With finding new alternative solutions potential counter measures do not work on them.
DEFENDING
Simmilar to the attacker defenders also regularly reverse engineer theire attackers softwares to learn everything about theire new techniques of doing certain actions. Thats why the anti cheat company battleeye is actively looking for reverse engineers.
3 Reading/Writing from kernel- Kernel Memory access
ATTACKING
Attackers got sick of the cat and mouse game and moved to kernel, from kernel attackers can basically hook any system function and implement theire own memory functions which are completly invisible from usermode access scope. For example an attacker can hook vulnerable system drivers (theres alot) and abuse them to perform its actions.
DEFENDING
The only chance a usermode programm has, is to identifiy actual written changes made to the games memory, but reads are untraceable. We can try to come up with other detection vectors like detecting overlays or signatures of cheating software, but with polimorphic code, unique builds and maybe also from kernel rendered overlays, we need to surrender. OR WE COMEBACK stronger with our kernel driver. With also having full access to the system we can also hook any sysfunction, we can enumerate other kernel drivers or also enfore strict rules of no test signed / unsigned drivers allowed which forces attackers to sign theire drivers. (Basically either costs much money and getting a free/leaked certificate is hard so once detected its hard to obtain a new one) We can also enforce secure boot, TPM and more which makes many not well developed drivers unuseable.
ATTACKING
Attackers feel a lil dizzy after the huge change of such an intrusive coperate anti cheat but they react with manually mapping the driver with kdmapper, which allows them to use unsigned drivers on a normal non testmode system. In addition they can also just make sure theire driver loads before the anti cheat driver, which gives them the edge over any anti cheat driver due too it being able to perform actions before any anti cheat driver is loaded, like spoofing hardware components, already placing hooks to malform function return data for example etc. basically rendering the anti cheat driver useless.
DEFENDING
Defending anti cheat drivers have an edge over malicious drivers due too their "official" signed nature and they can most of the time load before any malicious drivers when the operating system is working as intended. Windows for example has ELAM in place, and early launch anti-malware feature and is obviously also trying to prevent malicious drivers/rootkits. Its as easy as just setting Startype BOOT_START for example within the driver INF file.
With our newly gained power we can now also just actually globally hook system functions and monitor any memory related functions, enumerate any processes etc.
ATTACKING
The Attackers main goal now against other kernel anti cheats is to load before the anti cheat driver or find 0 day exploits, which is rather unlikely. Attackers used EFI bootkits to execute low level code before the operating system even fully loads, which makes it rather hard for anti cheat drivers to do anything against it if its not known. At such a level an attacker can possibly manipulate its hardware ID's, disable/manipulate PatchGuard, hide Systemthreads from other processes etc.
DEFENDING
The cat and mouse game continues... but anti cheat developers have an edge over attackers due too the operating system working with them against malicious actors.
4 Reading/Writing from external hardware- Direct Memory Access devices
ATTACKING