# Battling The Eye: Exploring the Anti-Cheat Techniques of BattlEye

Mohamed Sabt

► To cite this version:

Mohamed Sabt. Battling The Eye: Exploring the Anti-Cheat Techniques of BattlEye. CheckMATE 2025 - Research on Offensive and Defensive Techniques in the Context of Man At The End (MATE) Attacks, Oct 2025, Taipei, Taiwan. pp.38-47, 10.1145/3733817.3762701. hal-05482209

HAL Id: hal-05482209

https://hal.science/hal-05482209v1

Submitted on 28 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Battling The Eye: Exploring the Anti-Cheat Techniques of BattlEye

Mohamed Sabt

mohamed.sabt@irisa.fr

Univ Rennes, CNRS, IRISA

Rennes, France

## ABSTRACT

The never-ending battle between cheaters and anti-cheat developers within the realm of multiplayer video games has led to the development of increasingly sophisticated countermeasures, including the implementation of kernel-level anti-cheat solutions. These solutions, designed to safeguard the integrity of games and maintain fair play, operate at the deepest levels of the operating system, employing complex algorithms and system-level monitoring to detect and prevent cheating behaviors. Unfortunately, these defenses are mostly undocumented, and their effectiveness is still ill explored in literature.

This paper delves into the inner working of BattlEye; a Windows kernel-level anti-cheat solution. Our study involves dissecting BattlEye architecture through both dynamic and static reverse-engineering methods. Based on our insights, we examine various bypass techniques to evade detection and subvert the enforced defenses. We leverage these techniques to, for instance, persistently write arbitrary values to the game process without being banned or detected. Finally, we show the effectiveness of our bypass by developing a full Proof of Concept on a BattlEye-protected game, giving an advantage to the player even in a multiplayer session.

## CCS CONCEPTS

* Security and privacy → Software reverse engineering; Digital rights management.

## KEYWORDS

Reverse-Engineering Anti-Cheat BattlEye.

**ACM Reference Format:**

Mohamed Sabt. 2025. Battling The Eye: Exploring the Anti-Cheat Techniques of BattlEye. In *Proceedings of the 2025 Workshop on Research on Offensive and Defensive Techniques in the Context of Man At The End (MATE) Attacks (CheckMATE '25), October 13–17, 2025, Taipei, Taiwan*. ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/3733817.3762701

## 1 INTRODUCTION

*Historical background.* Game cheating is all but new. In the 1990s, curious and passionate game players started to edit the memory content of their games in order to gain an advantage or modify the game properties. However, these modifications only affected the single-player mode of these games [1]. With the emergence of

multiplayer games in the 2000s and the surrounding competition in the 2010s, a community of players started to develop sophisticated cheats, thus breaking the equality of chances with other players. Unlike piracy in video streaming, game cheats are not illegal in most countries, with the notable exception for China and South Korea. This situation forced video game editors to add security mechanisms in their games, to avoid the massive leaving of honest players being sick of the abundance of cheaters [24]. These mechanisms are called *Anti-Cheat* software. An anti-cheat monitors the player's activity during a game session, and in case of a suspicious cheat, it kicks or bans a player of this session, or even of the game itself [29]. By cheat, we mean third-party changes to games that are intended to offer an advantage to one player over the others. This involves changes to the core executables and the dynamic link libraries of a game. Video game publishers have the option to either internally develop their anti-cheat solutions, exemplified by Valve's VAC [33] and Epic Games' *Easy Anti-Cheat* [10], or opt for outsourcing to prebuilt third-party anti-cheat solutions like BattlEye [4] and SARD [28], since the development process of this kind of solutions requires specialized expertise to identify cheaters.

*Types of Anti-Cheat software.* We only focus on client-side anti-cheat solutions on PC (as opposed to server-based ones or mobile ones) for two reasons. First, both static and dynamic analysis can be more easily carried out on systems that primarily run locally. Second, despite mobile games being leading the gaming market [38], PC games are typically more prone to cheating due to the open and modifiable nature of the platform. Therefore, PC anti-cheat measures are often more sophisticated than their mobile counterparts.

In today PC gaming landscape, Windows OS reigns supreme [31], serving as the platform of choice for the majority of PC gamers, prompting anti-cheat developers to prioritize it during development. Anti-cheat software are divided into two main categories: user-land anti-cheat and kernel-land anti-cheat. The first one is a program running in the operating system's user space to recognize cheat patterns. This type of anti-cheat is quite easy to bypass [15], since the program is subjected to the actions of the kernel when the software is an executable running in user-land. By writing and inserting a custom driver into the kernel, the cheater may directly interfere with the game from the kernel, thus rendering ineffective any anti-cheat solely concerned about what happens in the user space.

The second type of anti-cheat, which is more sophisticated (and is mainly available on Windows), is the kernel-level anti-cheat. As its name implies, this software, in addition to its user-space client running during playtime, runs in the kernel space as a driver and is able to monitor a huge variety of events occurring on the machine.

Please use nonacm option or ACM Engage class to enable CC licenses
This work is licensed under a Creative Commons Attribution 4.0 International License.
*CheckMATE '25, October 13–17, 2025, Taipei, Taiwan*
© 2025 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-1906-6/2025/10
https://doi.org/10.1145/3733817.3762701

<figure><img src="image_2.png" /></figure>
In particular, they block programs and drivers that they believe contain security vulnerabilities. In order to efficiently control the game process without interfering with the player's gaming experience and the system stability, a careful development of such drivers is essential in order to avoid blocking benign drivers (e.g., refer to the recent controversy over Riot's Vanguard [34]). Depending on the video game editor and the game, the anti-cheat driver may only be loaded when the game executable is running like in the case of BattlEye. Nevertheless, in other cases, the anti-cheat software (e.g., Vanguard of Riot Games [25]) may continue to be active even if the game is not running. Such solutions raise significant privacy concerns, regarding the balance between security and user privacy in gaming environments [16].

**Motivations.** In 2022, the PC gaming market size was estimated at $50.23 billion and expected to reach $116.9 billion by 2030 [12]. Thus, the number of anti-cheat solutions is constantly increasing. However, very little is currently known about the internal working of anti-cheat software. This is, in part, purposeful because of anti-cheat solutions' desire not to be compromised by technically savvy cheaters that can undo what protections do. This is a textbook example of security through obscurity, which is widely assumed by the related gaming tech. For instance, Riot Games head of anti-cheat, Phillip Koskinas, argues that secrecy about anti-cheat internals is essential [26]. The unfortunate consequence is that the leveraged anti-cheat techniques are not well understood, beyond a tiny part of the cheating community. Thus, little public literature was published in this domain. We believe that it is important for both users and games to study the claimed security guarantees of anti-cheat solutions beyond marketing bubbles. In contrast to [9], our methodology is to go vertical, and provide in-depth analysis of one selected anti-cheat software to clearly identify inherent weaknesses of the applied protections, thereby encouraging novel reflections on this domain. Regarded as the most effective, the trend is to deploy kernel-level anti-cheat solutions, hence they become our target.

**Focus of the study.** In this paper, we chose to focus on the BattlEye anti-cheat; a kernel-level anti-cheat released in 2004 that is loaded when the game executable is launched. As a matter of fact, BattlEye constitutes a middle ground between user-land anti-cheat solutions and the kernel-level ones permanently loaded and running. In addition, BattlEye is leveraged by several widely-played games, such as Fortnite (of Epic Games), Destiny 2 (of Bungie) and PlayerUnknown's Battlegrounds (of PUBG Corporation). In [9], BattlEye-protected games were ranked high regarding their protection effectiveness, which results in raising the price of their cheats. We do not aim to exhaustively dissect all the defensive techniques employed by BattlEye. Our purpose is to shed lights on the inherent weaknesses of the used techniques by suggesting methods to bypass them. We argue that the scope of our work is not limited to BattlEye, since anti-cheat techniques are shared among other solutions, including Ricochet and Easy-Anti-Cheat [5, 13].

**Summary of Contributions.** Our work aims at pushing this topic forward, as we believe that stakes are high regarding anti-cheat. Our paper intends to fill this lack of public research by providing the first security analysis of BattlEye. Here, all our insights are obtained by performing reverse engineering of the BattlEye driver, rather

than reading confidential documentations through non-disclosure agreement (NDA). Moreover, we show that a deep understanding of BattlEye can allow attackers to easily bypass its enforced memory protection without requiring to defeat sophisticated mechanisms. This is worrisome because many games rely on BattlEye, or other similar anti-cheat engines, to protect against cheating [3]. Any harm to this technology can lead to huge financial losses. The scope of our work is deconstructed into 2 research questions:

(1) What and how effective are the leveraged kernel-based techniques in a state-of-the-art anti-cheat solution?

(2) How easy can we still bypass them?

In this work, our scope implies that Windows is the running environment. Our approach was to begin with a manual analysis to gain insights into the internals of the used anti-cheat techniques. Then, we identify weaknesses that can be leveraged to bypass the protection of the anti-cheat engine. We prove the effectiveness of our bypass techniques by implementing a full Proof of Concept (PoC) that tampers with the memory of some BattlEye-protected game to our benefit during a game session. We timely report all our findings to the concerned parties, and discuss potential mitigation. Our contributions are the following:

* We reverse-engineer BattlEye on Windows. In particular, we explore its different anti-cheat methods leveraging Windows kernel security mechanisms.

* We identify some design weaknesses in the BattlEye architecture allowing an attacker to run a malicious unsigned driver despite BattlEye. Then, we show how this malicious driver can tamper with a protected game without being detected through external and internal cheat mechanisms.

* Based on our knowledge, we implement a full PoC to make the player in the Unturned game unusually strong. For instance, in a multiplayer session, we give the player the ability to swim underwater without any damage, or in single-player session, our player becomes invincible by maintaining max life.

* Our code of the kernel module is available online<fnref n="1" />, for reproducibility purposes, and to assist future work on this topic. However, because of legal issues, none of the cheating Agent{Client/DLLs is provided.

**Responsible Disclosure.** Our findings have been timely reported to BattlEye. Our work piques their interest, especially Bastian Suter, BattlEye's CEO, leading to discussion over our different attacks. Our proposed mitigation is leading to changes that are integrated in the new versions of BattlEye, at least to detect our internal cheat. To guarantee fair play, we only ran our PoC on a temporary Steam account that was deleted once we have finished our experimentation. We also provide enough information to Bastian Suter, so that any cheater using our PoC would be immediately banned.

**Related Work.** Explicit academic research of different anti-cheat methods is relatively sparse [27]. This might be due low academic interest in the topic because academia considers it as “ad-hoc” hacks without any long-term insight. It might also be due to the secrecy of the private sector about their technology. To address users’ mistrust, companies, such as Riot Games, have published blog posts and

<footnote n="1">¹https://zenodo.org/records/17037068</footnote>
talks about their anti-cheat systems on a general level [17]. Many websites, such as Secret Club, Hachmag and UnknownCheats, detail various attempts to reverse-engineer proprietary anti-cheat systems. Posts are mostly published under nicknames to avoid facing any legal consequence of the game companies. Our paper attempts to address this lack of offensive public research. More importantly, our approach, which partially overlaps with some these non-academic sources, intends to complete them. Indeed, in 2024, Collins et al. [9] explore cheats forums in attempt to draw a survey for client-side anti-cheat solutions. They show in their study that most vulnerabilities come from shortcomings in some user-land code detecting, for instance, debugging and virtualization. Our approach does not only differ in methodology, but also goes systematic and shows an interesting insight: the security of kernel anti-cheat solutions is reduced to the Windows security feature of Driver Signature Enforcement (DSE). In other words, despite their complexity, anti-cheat can be systematically bypassed whenever DSE can be bypassed, seriously raising the question of their value.

Recently, the rampant cheating ends up by piquing the interest of the academic community. Karkallis et al., in ESORICS 2021 [14], studies the underground communities of cheaters. This paper motivates our work by drawing a connection between cheaters and malware developers due to financial incentive and similarity of goals, thereby illustrating the potential for technical overlap. While the Master's thesis Lehtonen [27] provides valuable resources to compare different anti-cheat methods, Anwar et al. [2] go further and design CHEATFIGHTER to defend against widespread cheating. Their insights were obtained by empirically analyzing 86 cheaters. Our identified cheat is not detected by their tool, showing that it presents novel techniques.

The closest work to our approach is the project access-noseh [11]. It consists of a DLL and a driver. The DLL is injected into Cheat Engine [8] to intercept calls made by Cheat Engine to the Windows API. To initiate this process, an unsigned driver must be loaded into the system before injecting the DLL. The driver is responsible for intercepting API calls and reconstructing them, particularly used in the case of calls to OpenProcess. Through this approach, the driver helps with the provision of a process handle from the kernel to Cheat Engine. This method, known as system call hooking, represents a sophisticated, yet effective, mean of evading callbacks. Similar to our approach, a prerequisite for its success is the necessity to maliciously disable DSE before starting the anti-cheat.

# 2 WINDOWS SECURITY FEATURES

## 2.1 BSOD and PatchGuard

A prominent protection in Windows OS is the Blue Screen of Death (BSOD). This feature was implemented to stop the operating system in case of a critical error. To prevent more damage, the kernel enters a special routine that will throw the infamous blue screen and shutdown Windows. Various conditions can lead to a BSOD, such as hardware failures, issues with device drivers or unexpected events in the kernel memory. The BSOD is strongly related to another kernel security feature of Windows OS called PatchGuard. This undocumented feature, which consists in a highly obfuscated code residing in the kernel, was developed by Microsoft to prevent third-party applications or drivers from accessing and modifying

the Windows kernel. PatchGuard periodically checks the integrity of the structures of the kernel, but also elements of the CPU like special registers. If anything unusual is detected, such as tampering with the kernel memory without proper allocation, the system is stopped immediately thanks to BSOD.

## 2.2 Driver Signature Enforcement

In Windows, the privilege levels are split into four rings. They refer to the hierarchical levels of access control within the operating system, ranging from Ring 0 (kernel mode) with the highest privileges to Ring 3 (user mode) with the lowest privileges, effectively managing system resources and security boundaries. Drivers operate in the kernel space (Ring 0), meaning that they have access to the full system, up to the limit of what PatchGuard allows. As a consequence, drivers must be developed cautiously to avoid system instability and BSOD. As driver code is executed in the kernel space, a user may load its own driver into the system and perform malicious activities. However, the Windows Driver Signature Enforcement (DSE) [18] prevents this scenario from happening. This feature ensures that only drivers signed by Microsoft are loaded into the kernel, therefore reducing the attack surface for the attacker who must find vulnerabilities in legitimate signed drivers. Note that discovering flaws in signed drivers remains a popular method for executing kernel exploitation on Windows. This adversarial model is called the *Bring Your Own Vulnerable Driver* (BYOVD).

## 2.3 Virtualization-Based Security

Since Windows 10, Microsoft strongly enhanced the kernel security with the Virtualization-Based Security (VBS) features [19]. By using hardware virtualization and the Windows hypervisor, an isolated virtual environment is created to become the root-of-trust of the system. This model assumes that the kernel may be compromised, for instance with a vulnerable signed driver. Thus, all critical components of the kernel reside in this secure virtual environment, isolated from the non-secure part of the kernel where drivers operate. This set of features consequently enhanced the security of Windows OS. However, because of the added virtualization layer, VBS has a visible impact when it comes to gaming performances. Very often, video game players remove this solution to retrieve the highest gaming performance, resulting in less security.

## 2.4 Windows Callbacks

The Windows kernel callbacks are a mechanism that allows the kernel to notify registered components or drivers about specific events or conditions, thereby enabling various system-level interactions and customizations. Many security solutions implemented as a kernel driver such as Endpoint Detection and Response (EDR) or game anti-cheat leverage the kernel callbacks to monitor the system activity and detect any unusual or unwanted behavior on a specific target process or the whole system.

Several steps are necessary to activate a callback on the system. The developer must first write a routine that will be triggered by the system when a specific event happens. The possible events to monitor may be about process or thread creation, image loading (executable, DLL, driver), registry key setting, getting a handle on a process, and other events listed by Microsoft. Then, the developer
must use specific functions to register their callbacks into the system. The following functions take a first parameter containing a pointer to the routine that is called when the corresponding event occurs:

```
PsSetCreateProcessNotifyRoutine,
PsSetCreateThreadNotifyRoutine, PsSetLoadImageNotifyRoutine.
```

The security design is different with `ObRegisterCallbacks`, which is associated with the process, thread and desktop handle management. In the context of game cheating, the cheater is often interested in reading and (over-)writing the game memory to alter internal variables to their advantage. To this end, cheaters may use the Windows API `OpenProcess` function by specifying the access mask required to perform a memory reading or writing. The function will return an object called a handle allowing the user to interact with the process. This handle contains the access mask authorized by the Security Reference Monitor, the kernel component in charge of managing the access rights. By passing a list of callback routines to the `ObRegisterCallbacks` function, the anti-cheat driver can define the type of handle operations in the `OB_OPERATION_REGISTRATION` structure for a given object type:

```c
typedef struct _OB_OPERATION_REGISTRATION {
    POBJECT_TYPE              *ObjectType;
    OB_OPERATION               Operations;
    POB_PRE_OPERATION_callback  PreOperation;
    POB_POST_OPERATION_callback PostOperation;
} OB_OPERATION_REGISTRATION;
```

The field `ObjectType` specifies the type of object involved in the routine, whether it is a process, a thread or a desktop handle operation. The field `Operations` is linked with the two types of handle operations: a creation or a duplication. The handle creation occurs when a user requests a handle to a process or creates a process whereas the handle duplication must be explicitly asked by the user through the Windows API `DuplicateHandle` function. Finally, the `PreOperation` (resp. `PostOperation`) field contains a pointer to the routine that is called before (resp. after) the processing of the handle operation. In the case of anti-cheat kernel driver, the `PreOperation` routine would start by checking if the created or duplicated handle is linked with the game process. Then, the routine will check the requested access mask of the handle to remove the `PROCESS_VM_READ`, `PROCESS_VM_WRITE` and `PROCESS_VM_OPERATION` rights originally requested by the user, respectively responsible for the memory reading and writing operations in a process.

## 3 METHODOLOGY AND THREAT MODEL

We chose to work in a cheater adversarial model, which is similar to the DRM one [22], that involves an attacker with full control of their device. This allows reverse-engineering to understand the inner-working of an anti-cheat solution, before identifying and exploiting weaknesses allowing to bypass enforced protection. The technical context is essentially based on Windows 11 (23H2), up to date at the time of the writing. Considering the cheater adversarial model, all the removable Windows security features, including Windows Defender and Virtualization-Based Security are disabled. In addition, the Windows vulnerable block list is also disabled. This feature prevents the user from installing signed vulnerable

drivers with known critical vulnerabilities allowing kernel memory operations and privileged code execution.

We run BattlEye through *Unturned* [32], a survival game. The latter is also used fully updated (version 3.23.12). Because BattlEye verifies that it is not running in a virtual machine or that debug ports are not opened (cf. Section 4), a dedicated Windows-machine is used for our practical experimentation. The choice of the *Unturned* might seem peculiar, compared to *Fortnite* by example. First, for legal reasons, we did not target a high-stake game with an active esport scene. Second, the game still receives much positive feedback on Steam. We also argue that our findings hold regardless of the target game, since we study a pre-built third-party anti-cheat solution.

It is worth noting that the cheater model presents distinct features compared to the DRM one: we assume that the cheater have no choice, but to run an unaltered copy of Windows. In addition, while game cheats are not signed by Microsoft, the anti-cheat module is signed, allowing it to run in the kernel.

In follows, we focus on the reverse-engineering of the kernel driver used by BattlEye, then find exploitation paths and finally implement bypasses that enable cheats on the game.

## 4 REVERSING THE BATTLEYE ANTI-CHEAT

We start our analysis by performing reverse-engineering of BattlEye in order to dissect the inner-working of this “made in Germany” anti-cheat solution, before identifying and exploiting weaknesses allowing to bypass enforced protection. Unlike work on specialized (underground) forums, such as secret.club, we focus on memory protection ensured by the kernel. Below, we present our findings.

### 4.1 Overview

The BattlEye anti-cheat is composed of three main elements:

(1) `BEService.exe`: This user-land service communicates with the BattlEye server.

(2) `BEDaisy.sys`: This is the kernel driver dropped on disk when the game is launched. It is deleted when the game process is killed.

(3) `BEClient.dll`: This DLL is loaded into the game process memory and interacts with the kernel driver to detect suspicious cheat behaviors.

The first analysis conducted on the driver revealed the use of anti-reverse-engineering techniques on the binaries. The presence of huge data segments, the abundance of subroutines, as well as the lack of imports, strings and assembly clarity suggest, as we will confirm, the use of a virtualization tool *VMProtect* [36]. In addition, we noticed in the import the `FltGetRoutineAddress` function, showing that the driver is a minifilter, which is a driver class that exposes a framework to implement security features. We rely on an open-source tool called *NoVmp* [6] to de-virtualize the binary and reconstruct a driver similar to the original one. By looking at the strings of this new driver, we found the names of well-known Windows API function and Windows Driver Framework functions. There are still few imports due to the fact that the driver imports its functions using the `MmGetSystemRoutineAddress`, a kernel function used to retrieve the address of a function name passed in parameters.
```c
NTSTATUS SetCallbacks() {
    WaitForSingleObject(0x1400161d8, 0, 0, 0, 0);
    OB_callback_REGISTRATION *CallbackRegistration;
    CallbackRegistration->Version = 0x20100;

    OB_OPERATION_REGISTRATION OperationRegistration[2] = { {0}, {0} };
    OperationRegistration[0].ObjectType = PsProcessType;
    OperationRegistration[0].Operations = OB_OPERATION_HANDLE_CREATE |
                                          OB_OPERATION_HANDLE Duplicate;
    OperationRegistration[0].PreOperation = obPreOperationCallback;
    OperationRegistration[1].ObjectType = PsThreadType;
    OperationRegistration[1].Operations = OB_OPERATION_HANDLE_CREATE |
                                          OB_OPERATION_HANDLE Duplicate;
    OperationRegistration[1].PreOperation = obPreOperationCallback;

    CallbackRegistration->OperationRegistration = OperationRegistration;
    NTSTATUS status = ObRegisterCallbacks(CallbackRegistration, 0x140016130);
    return status;
}
```

<caption>Figure 1: Rebuilt function used to set the object callbacks.</caption>

## 4.2 Registered Callbacks

By disassembling and decompiling the de-virtualized driver, we are able to retrieve the registered callbacks of the driver. Indeed, by diving on the `DriverEntry` function, the registration functions about process/thread creation and image loading are visible, as well as their associated routines. We also found the `ObRegisterCallbacks` function used for handle monitoring.

**Object Register callbacks.** Unfortunately, the output of the de-virtualization process remains hard to read. For the sake of clarity, we rebuilt a clean function on Fig.1. The `OperationRegistration` field of the `OB_callback_REGISTRATION` structure was initialized with an array of two `OB_OPERATION_REGISTRATION` structures for the processes (`PsProcessType`) and threads (`PsThreadType`) object types. The two structures contain the same `PreOperation` routine and are triggered because of a handle creation or a handle duplication event (the value 3 represents both events according to the Microsoft documentation). The routine `obPreOperationCallback` is the two-parameter function which will be used as the routine. The second parameter is a `OB_PRE_OPERATION_INFORMATION` structure containing the desired access mask of the handle requested by the user. This value is changed via a bitwise mask to modify the rights of the final handle sent back to the user. The decompiled code below shows this rights strip as mentioned in Section 2.4.

```c
if (((((int8_t) ObPreOperationInfo ->KernelHandle) & 1) ==
0) {
    int64_t process_handle = PsGetCurrentProcessId();
    if (r14 != 0) {
        *(uint32_t*) Parameters = *(uint32_t*)
            Parameters & 0xffffffff5;
    }
}
```

**Load Image callback.** The image loading callback routine performs several checks on the PE (Portable Executable) structure of any executable, DLL or driver that should be loaded. The PE format is the Windows standard one for executable and library files. Combined with dynamic analysis, our experiments show that we cannot load any driver even signed when the anti-cheat is active. This is because the routine checks some metadata in the PE structure to detect the loading of vulnerable drivers in order to fight against the widely spread technique of loading vulnerable signed drivers. In the file header part of the PE format, the field `TimeStamp`

contains the compilation timestamp of the binary in the epoch format. The routine compares the timestamp of the loaded image to a hard coded array of denlisted vulnerable drivers PE timestamps.

## 4.3 Kernel Modules Checks

In its `DriverEntry` function, `BEDaisy.sys` verifies the integrity of certain critical kernel modules. The `win32k.sys`, `win32kfull.sys` and `win32kbase.sys` modules are used for managing the user interface. The `dxgkrnl.sys` module manages the graphics-related tasks in the Windows kernel. Other modules, including `hal.dll`, `ACPI.sys` and `pci.sys`, are responsible for the communication between the operating system and the hardware. The hardware interaction modules are essentially checked to detect the presence of hardware cheats that provide direct access to physical memory (DMA). By verifying the integrity of certain modules, the anti-cheat is able to detect the potential hardware cheat devices, and then bans the player in case of a successful detection.

## 4.4 Anti-Debug Techniques

We saw that `BEDaisy.sys` is virtualized to hinder or slow down static analysis. In addition, the driver employs several anti-debugging and anti-VM techniques to counter dynamic analysis via a kernel debugger for instance. One still plausible solution to understand the behavior of the BattlEye anti-cheat might rely on the use of a virtual machine with a debug port opened to debug the VM via a kernel debugger and access to the driver elements residing in the kernel. However, as mentioned in Section 4.3, the driver verifies the hardware devices thanks to some kernel modules. A kernel debugging session requires the opening of an additional device to ensure the connection between the host and the target. This kind of device is detected and the VM in which BattlEye is running will be shut down. We conducted several tests on various hypervisors like Hyper-V, VMWare or VirtualBox and the crash of the virtual machine was noticed each time.

Furthermore, the driver utilizes special instructions to detect the presence of a VM. Notably, the driver leverages the cpuid instruction with the value `0x40000000`. If the system is running in a VM, the instruction returns the hypervisor vendor signature in ill-configured hypervisors (e.g., hvpp, Hyperplatoform). Another uncommon used instruction is `xgetbv`. This special instruction must be handled carefully by a hypervisor, otherwise a crash will occur. Executing this instruction repeatedly in a short amount of time allows the detection of hypervisors, since such instructions are relatively cheap on real hardware whereas in a virtualized environment they run slower due to the overhead incurred by an introspective engine. Further insights about this technique can be found in [30].

# 5 BYPASS MEMORY PROTECTION

## 5.1 Intuition and Approach

After digging into the inner-working of `BEDaisy.sys`, we are able to determine the scope of the verification and runtime controls performed by the anti-cheat. The driver checks the memory of all processes running in the system, the created and duplicated handles on processes and threads, the loaded binaries and the integrity of important kernel modules that ensure the stability of
the game. However, there is no clear evidence in the de-virtualized
driver about any global verification on all modules loaded into
the kernel (probably to avoid system instability or privacy issues).
Consequently, a custom driver loaded before the anti-cheat may
not be rejected. Thus, our subsequent exploitation path is focused
on the creation of a custom driver that will be inserted before the
anti-cheat launch to tamper with the kernel space.

All our bypass techniques implemented in this study are generic and based on unsigned drivers that will interact from the user-land with a client. Using a kernel driver is the easiest way to interact with kernel objects without being monitored by BattlEye nor PatchGuard (cf. Section 2.1). In game cheating, a cheat may be considered as an internal or external cheat. An external takes advantage of memory read/write primitives to modify the game's internals. This type of cheat is more challenging to build. This is due to the fact that a deep understanding of the game's internals is necessary in order to find relevant data to read or write. This implies another reverse-engineering effort. However, these cheats only transfer memory, so they are easier to implement than the other type of cheat: the internal cheat. The latter focuses on injecting modules (mostly DLLs) into the game to tamper with the game engine. Such cheats need to be developed cautiously to avoid crashes when tampering with the game engine.

One major obstacle to our approach is to be able to install our unsigned driver, especially that this requires Driver Signature Enforcement (DSE) to be disabled in the running Windows environment. However, this service is necessary for the BattlEye anti-cheat system. In addition, DSE is a security mechanism for 64-bit versions of Windows that forcibly checks the program singing certifications for all loadable kernel drivers. One might suggest a two-step attack: (1), disable DSE (based on our threat model), and install the cheater driver, then (2) re-Enable DSE, and run BattlEye that will ignore previously installed drivers.

The naive implementation of this attack is not possible because
a system reboot is needed whenever the DSE status is modified
through the Boot Configuration Data (BCD) [37]. Therefore, we
need to maliciously enable/disable DSE, which we explain below.

## 5.2 Bypassing the DSE

The bypass of DSE (cf. Section 2.2) is essential in order to successfully insert an unsigned driver into the system without any reboot. As this step is out of the scope of this study (namely anti-cheat techniques), our presentation does not cover all details.

In a nutshell, maliciously disabling DSE implies loading a vulnerable signed driver to execute arbitrary code. The goal of this code is to locate and patch a variable named `g_CiOptions` that resides in the Windows kernel mode library `ci.dll`. This variable indicates the state of DSE on the system, the value `0` associated to a disabled DSE and the value `6` associated to an enabled DSE. Several open source projects were developed to patch the DSE. We chose to use DSE-Patcher [7]. This application has a simple graphical interface allowing us to choose between several vulnerable drivers to modify DSE. After choosing one driver, the corresponding code is triggered to insert the driver while exploiting its vulnerabilities to patch the `g_CiOptions` variable. In order to successfully load the vulnerable drivers, the Microsoft vulnerable driver block list needs to be disabled. Indeed, these drivers are often used for kernel

exploitation, hence their appearance in the vulnerable driver block
list. This is why, as mentioned in our threat model, this security
feature was disabled.

The bypass works on a Windows environment when disabling
the following security features: Windows Defender (DSE-Patcher
is detected as a malicious software), the Windows vulnerable driver
list and importantly VBS. With the Virtualization-Based Security
features activated, the *ci.dll* module resides in the secure part of the
kernel, isolated from the device drivers, and its memory page will
be set as read-only. As a consequence, when the vulnerable driver
attempts to overwrite this variable, VBS detects an unauthorized
operation on a read-only memory page. Then, the system launches
a BSOD with the following error code: *ATTEMPTING WRITE TO
READONLY MEMORY*. Below, we describe our cheats.

## 5.3 External Cheat: A Kernel Driver to Manage the Game Memory

Leveraging the DSE bypass technique (cf. Section 5.2), we succeeded in installing our attacker driver and then running BattlEye. As noticed, the BattlEye anti-cheat solution protects the game memory from the user space by registering callbacks, but it does not interfere with a custom driver loaded before the anti-cheat. This allows our driver to take advantage of the kernel space to avoid the anti-cheat detection. In the external cheat, our purpose is to read/write the virtual memory of a process game protected by BattlEye.

Technically, we leverage an undocumented function<fnref n="2" /> exposed in the Windows kernel to copy virtual memory from a process to another inside the kernel space. The call of this function is not detected by any callback. The function signature is presented in Appendix A (A.1). The `MmCopyVirtualMemory` function copies a memory region of `BufferSize` located at the virtual address `SourceAddress` from a process `SourceProcess` to a memory region located at the virtual address `TargetAddress` in the process `TargetProcess`. We rely on this function to craft a simple proof of concept that includes a client residing in user mode and a driver inserted in the kernel space before launching the anti-cheat. The client interacts with the driver through to two `IOCTLs`, one used to read the memory of the game process and one to write this memory. In both cases, the driver calls the `MmCopyVirtualMemory` function to ensure the memory transfer between a buffer defined on the client side and the targeted memory region in the game process.

*Memory reading.* In order to read the memory of a targeted process, the driver needs to receive some information from the client, which is sent through the `DeviceIoControl` function used to communicate with a driver thanks to `IOCTLs`. The client needs to specify the `IOCTL` associated with the memory reading operation and passes a `READ_MEMORY` structure:

```c
typedef struct _READ_MEMORY {
    ULONG ProcessId;
    ULONGLONG addressSrc;
    PVOID addressDst;
    ULONG size;
} READ_MEMORY;
```

The field `addressDst` is the address of the buffer defined in the client to which we copy size bytes from the address `addressSrc`

<footnote n="2">²found here: https://pastebin.com/eBTYxnnj</footnote>
in the virtual memory space of the targeted process identified by the ProcessId field. After the client's request, the driver receives the structure and needs to first retrieve the EPROCESS structure of the targeted process that will be used as an argument for the MmCopyVirtualMemory function. In order to achieve that, the PsLookupProcessByProcessId function is called with the PID of the target process as the first argument. The next step is to call KeReadVirtualMemory to perform the reading operation (presented in Appendix A in A.2):

Ultimately, the MmCopyVirtualMemory function is called to copy the memory of size Size located at addressSrc from the targeted Process to the client process at TargetAddr. The process structure of the client is retrieved with the PsGetCurrentProcess function that returns the EPROCESS structure of the thread calling the driver. In this case, the threads belong to the client querying the driver to perform the memory reading operation.

Finally, the driver terminates the Input/Output query associated with the client. Now, the targeted memory region of the game is in a buffer defined in a process residing in user mode.

*Memory writing.* The memory writing operation differs on a few points. The structure passed to the driver by the client is essentially the same.

The EPROCESS structure of the targeted process is retrieved similarly as for reading. However, this time the driver leverages another function called KeWriteVirtualMemory to accomplish the writing operation. The only difference with KeReadVirtualMemory resides on the arguments passed to the copy function MmCopyVirtualMemory.

For this operation we aim to copy memory content at addressSrc that we control from the client process to the targeted game process. Thus, the SourceProcess argument is now the result of PsGetCurrentProcess to get the process structure of the client. As an example, this feature may be used to copy a single byte defined in the client to the location of a relevant game variable, such as the player's life in the game to reset this life to a chosen one-byte value.

## 5.4 Internal Cheat: Patch the Callbacks

As mentioned, the BattlEye anti-cheat solution protects the game memory from user space by registering callbacks and preventing handle writes, as well as disabling the loading of shared libraries in the game. The first mechanism responsible for managing unprivileged handles is ObRegisterCallbacks. It registers a pre/post-operation callback when a game process, thread, or desktop handle is opened or duplicated. The second mechanism, PsSetLoadImageNotifyRoutine, registers a callback that triggers when an image is mapped into the game.

The registered callbacks from ObRegisterCallbacks are represented by a struct called OB_callback_ENTRY, stored in a linked list called CallbackList. The structure of OB_callback_ENTRY has been reversed [35] (a simplified definition is given in Appendix A).

If the targeted object affected by the callback is a process of object type PsProcessType, it will have registered callbacks to

notify when handles on a process are created/duplicated. As mentioned before, BEDaisy removes write permissions on the specified handles. We can find the BEDaisy.sys module by inspecting the PreOperation and PostOperation fields and determining whether the corresponding routines belong to the module. Thus, we disable the callback by setting the Enabled field of the OB_callback_ENTRY structure to false. For the system, the callback is still registered, but its corresponding routines will not be called by the kernel. As a result, the memory protection guaranteed by callbacks can be completely bypassed.

As for libraries loading, PsSetLoadImageNotifyRoutine stores the callback routine in the array PspLoadImageNotifyRoutine. To disable a particular routine in the array, the goal is to set the handles in the PspLoadImageNotifyRoutine array to zero. The load image callback array is still present, but the targeted routines are now unreachable because their handle has been set to NULL.

Another method to bypass this callback is to simply avoid triggering it. Indeed, this type of callback is usually triggered by the use of the standard Windows API LoadLibrary function in case of a DLL injection for instance. However, the steps performed in this function may be done manually by the user. This process is called manual mapping injection. It maps every component of a valid chosen PE file into a targeted process virtual memory space to reach the same result as the LoadLibrary function. Consequently, the system has no idea that an image has been loaded into a process and the callback will not be triggered. Various manual mappers exist and can be used to bypass the BattlEye load image callback. We did not implement this approach.

# 6 EXPERIMENTAL EVALUATION

Both external and internal cheat approaches were tested on the working environment detailed below. In our adversarial model, we considered that a bypass is successful in case of a visible tampering with the game that should have been blocked by the anti-cheat solution such as memory operations.

## 6.1 Experimentation Setup.

The experiments are conducted on Windows 11 (23H2), up to date at the time of the writing, with an Intel(R) Core(TM) i7-10510U and 16 GB of RAM. We run BattlEye through Unturned [32], a survival game. The latter is also used fully updated (version 3.23.12). Because BattlEye verifies that it is not running in a virtual machine or that debug ports are not opened (cf. Section 4), a dedicated Windows-machine is used for our practical experimentation. The choice of the Unturned might seem peculiar, compared to Fortnite by example. First, for legal reasons, we did not target a high-stake game with an active esport scene. Second, the game still receives much positive feedback on Steam. We also argue that our findings hold regardless of the target game, since we study a pre-built third-party anti-cheat.

## 6.2 Evaluation of External Cheat.

To implement the external cheat proof of concept, we started by spotting the memory location of the game process. With ProcessExplorer from the SysInternals Suite [21], we found the PID of the game process as well as the base address of the executable. By performing a reading operation on the first bytes starting from this
address, we were able to see the magic bytes of a PE file, which cor-
responds to the MZ characters. The arguments passed to the client
are the PID of the process, the address to perform the operation,
the size of memory to handle and the operation (in this case 0 for
memory reading). The first bytes sent by the driver to the client's
buffer are 0x4d 0x5a, which are the magic bytes of a PE file.

After reading the game memory and finding the life variable
of the player, we crafted a client whose goal is to make a request
every half-second to overwrite this variable with the max value
100, resulting in an invincible hero in the game. However, this life
cheat only works on the single player mode, as most of critical
variables reside on the server side in a multiplayer session. In this
context, we also succeeded in cheating by modifying the variable
associated with the oxygen rate of the player, used to determine
how much time the player is able to swim underwater without being
damaged. This modification is not as crucial as the life modification
in a game session but may still give an advantage to the player. In
our experiments, we maintain our cheat in the same session for
several minutes, and the BattlEye anti-cheat solution did not detect
anything. To sum up, we were also able to cheat on multiplayer
sessions, despite sensitive variables being protected on the server.

## 6.3 Evaluation of Internal Cheat

To assess the internal cheat proof of concept, we attempted to inject
a DLL into the *Unturned* game with BattlEye enabled. Initially, we
disabled the *BEDaisy.sys* registered object callbacks via a loaded
kernel driver, using a similar method as the external cheat part.
If we try to inject a DLL path into the game process memory to
load it later, a virtual memory allocation error is returned due to
the handle rights strip performed by the callback of *BEDaisy.sys*.
However, after setting the *Enabled* field of this callback to *False*,
the injection is performed without errors because as the callback
was not triggered the handle obtained on the game process is not
stripped from its memory writing right. We may use an additional
tool to verify the success of the operation. In this case we launched
*VMMAp* [20], a memory analysis tool from the SysInternals Suite to
verify that the string was actually injected into the game memory.

Once we obtained a handle on the game, we explored two methods to bypass the PsSetLoadImageNotifyRoutine function. The first method involved manual library loading. The second one implied patching PspLoadImageNotifyRoutine to be able to employ traditional DLL injection by calling the Windows API LoadLibrary function without being blocked by the anti-cheat solution. With both methods, we bypass BattlEye and gained the ability to read and write the game memory from user-land. However, thanks to our disclosure, attempts to create a functional DLL result in crashing the game, since BattlEye now detects callback deactivation.

# 7 DISCUSSION

## 7.1 Other Bypass Techniques

In the initial phase of our investigation, we focused on identifying
the availability of public bypass methods. Our primary objective
was to be functionally compliant with Cheat Engine [8], a widely
recognized open-source cheating software allowing reading and
writing of the game memory. Cheat Engine offers additional capa-
bilities, such as DLL injection or execution of LUA scripts. However,
Cheat Engine is not effective against the BattleEye anti-cheat.

## 7.2 Threats to Validity

A threat to validity of our work is that our cheating PoC, for legal
issues, was performed only on one game, minimizing the impact of
our contributions in case BattlEye offers per-game customization.
The reasons why this does not limit the scope of our contributions
are twofold. First, we only focused on the proactive (mainly client-
side) component of BattlEye, and it is quite unlikely that the studied
anti-cheat techniques are only active for a subset of them. We did
not consider the reactive (mainly server-side) system of BattlEye
that can be customized per game. Second, the bypassed techniques
are not limited to BattlEye, as shown in [5, 13].

## 7.3 Possible Mitigation

*Secure Boot and Early Launch Anti-Malware.* Secure Boot is a protection technique that creates a trusted chain of components at the start of the machine, from the firmware to the kernel initialization. This well-known mechanism is used to prevent malicious code from being executed before the system startup. By verifying the signatures of critical components such as the bootloader, the kernel and critical drivers, Secure Boot ensures that only trusted software is executed in the different boot phases. In the context of anti-cheat software, the activation of Secure Boot prevents harmful drivers from being loaded before and during the system startup, thus avoiding any tampering with the anti-cheat kernel driver. This technique is employed by Vanguard and EA Anti-Cheat, even though it raises security concerns on the gaming community [34].

Early Launch Anti-Malware (ELAM) is a feature introduced by
Microsoft to allow anti-malware software to start before third-party
applications. It lies on specific drivers initialized before other boot
start drivers to control that they do not contain malicious code.
If an Anti-Malware driver detects the presence of malicious code
inside a third-party driver, the execution is blocked, and the system
will be notified that this driver launching was stopped.

*Memory Paging Security.* Another important mitigation is the implementation of security measures on the paging system, as seen in other anti-cheat systems such as Vanguard [39]. These systems protect critical game regions by intercepting context swaps and establishing an allowlist of specific threads authorized to access their cloned CR3 register. This register contains a physical memory address pointing towards the page table directory of the current process. In other words, any virtual address to physical address translation performed relies on the value of the CR3 register. This mitigation would have prevented us from reading the game memory from our custom application, as it is not in the allowlist.

# 8 CONCLUSION

In this paper, we explored the undocumented closed-source BattlEye
with several of its anti-cheat techniques on Windows. Based on the
gained insights, we identify how to bypass its protection through
rather simple and generic methods, showing inherent weaknesses
to such anti-cheat solutions. We validate our findings by implement-
ing a full Proof of Concept that allows an attacker to persistently
cheat by tampering with the memory of a BattlEye-protected game
from the kernel. Hopefully, this paper would encourage and foster
research about the evolving landscape of anti-cheat techniques. A
promising future work is to find trusted drivers that inadvertently provide gadgets to the MmCopyVirtualMemory function from user-land, as illustrated by the EchOh-No! vulnerability [23]. This, or more generally any “security-hole as a service”, can be used to bypass kernel anti-cheat without installing malicious drivers.

## ACKNOWLEDGMENTS

This work received funding from the French National Research Agency (ANR) under the France 2030 program under the project REV (grant agreement No. ANR-22-PECY-0009).

## REFERENCES

[1] Andrew Tarantola. 2019. A brief history of cheating at video games. https://www.engadget.com/2019-06-15-a-brief-history-of-cheating-at-video-games.html.

[2] Md Sakib Anwar, Chaoshun Zuo, Carter Yagemann, and Zhiqiang Lin. 2023. Extracting Threat Intelligence From Cheat Binaries For Anti-Cheating. In *RAID. ACM*, 17–31. https://doi.org/10.1145/3607199.3607211

[3] Avatar photoSerif Pilipovic. 2024. Every game with kernel-level anti-cheat software. https://levvvvel.com/games-with-kernel-level-anti-cheat-software/.

[4] BattlEye. 2024. The Anti-Cheat Gold Standard. https://www.battleye.com/.

[5] byte2mov. 2024. ricochet-disabler. https://github.com byte2mov/ricochet-disabler.

[6] Can Bölük. 2020. NoVmp. https://github.com/can1357/NoVmp.

[7] Cesusius. 2024. DSE Patcher. https://github.com/Cesusius/Dse-Patcher.

[8] Cheat Engine. 2023. Cheat Engine. https://www.cheatengine.org/.

[9] Sam Collins, Alex Poulopoulos, Marius Muench, and Tom Thothia. 2024. Anti-Cheat: Attacks and the Effectiveness of Client-Side Defences. In *Checkmate@CCS. ACM*, 30–43. https://doi.org/10.1145/3689934.3690816

[10] Easy Anti-Cheat. 2024. Don't Bear with the Cheaters. https://www.easy.ac.

[11] Github. 2020. access - noseh. https://github.com/btbd/access.

[12] Grand View Research. 2018. Gaming PC Market Size & Trends. https://www.grandviewresearch.com/industry-analysis/gaming-pc-market-report.

[13] iPower. 2020. CVEAC-2020: Bypassing EasyAntiCheat integrity checks. https://secret.club/2020/04/08/eac_integrity_check_bypass.html.

[14] Panicos Karkallis, Jorge Blasco, Guillermo Suarez-Tangil, and Sergio Pastrana. 2021. Detecting Video-Game Injectors Exchanged in Game Cheating Communities. In *ESORICS (1) (Lecture Notes in Computer Science, Vol. 12972)*. Springer, 305–324. https://doi.org/10.1007/978-3-030-88418-5_15

[15] LevitatingBusinessMan's blog. 2023. Why Anti-Cheat needs kernel drivers. https://blog.levitatiing/articles/6.

[16] Anton Maario, Vinod Kumar Shukla, A. Ambikapathy, and Purushottam Sharma. 2021. Redefining the Risks of Kernel-Level Anti-Cheat in Online Gaming. In *2021 8th International Conference on Signal Processing and Integrated Networks (SPIN)*. 676–680. https://doi.org/10.1109/SPIN52536.2021.9566108

[17] Michael VanKuipers. 2018. Riot's Approach to Anti-Cheat. https://technology.riotgames.com/news/riots-approach-anti-cheat.

[18] Microsoft. 2023. Driver Signing. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing

[19] Microsoft. 2023. Virtualization-based Security (VBS). https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs.

[20] Microsoft. 2023. VMMap v3.4. https://learn.microsoft.com/fr-fr/sysinternals/downloads/vmmap.

[21] Microsoft. 2024. Sysinternals Suite. https://learn.microsoft.com/fr-fr/sysinternals/downloads/sysinternals-suite.

[22] Gwendal Patat, Mohamed Sabt, and Pierre-Alain Fouque. 2022. Exploring Widevine for Fun and Profit. In *SP (Workshops). IEEE, 277–288*. https://doi.org/10.1109/SPW54247.2022.9833867

[23] protocol. 2023. EchOh-No! a Vulnerability and PoC demonstration in a popular Minecraft AntiCheat tool. https://ioctl.fail/echo-ac-writeup/.

[24] Rich Stanton. 2016. Have hackers and cheaters ruined The Division on PC? https://www.theguardian.com/technology/2016/apr/26/hackers-cheats-ruined-the-division-pc-ubuntu.

[25] RIOT Games. 2024. RIOT Games. https://www.riotgames.com.

[26] Ryan K. Rigney. 2024. The Gamers Do Not Understand Anti-Cheat. https://www.pushtotalk.gg/p/the-gamers-do-not-understand-anti-cheat.

[27] Samuli Lehtonen. 2020. Comparative Study of Anti-cheat Methods in Video Games. Master's thesis. University of Helsinki. http://hdl.handle.net/10138/313587

[28] SARD. 2024. SARD Anti-Cheat. https://www.sard.ac/.

[29] Sean Murray. 2018. Plagued By Cheaters, PUBG Has Banned 13 Million Players So Far. https://www.thegamer.com/pubg-cheaters-13-million/.

[30] Secret Club. 2020. BattlEye hypervisor detection. https://secret.club/2020/01/12/battleye-hypervisor-detection.html.

[31] STEAM. 2024. Steam Hardware & Software Survey: February 2024. https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam.

[32] STEAM. 2024. Unturned. https://store.steampowered.com/app/304930/Unturned.

[33] STEAM. 2024. Valve Anti-Cheat (VAC) System. https://help.steampowered.com/en/faqs/view/571A-97DA-70E9-FF74.

[34] Tyler Wilde. 2020. The controversy over Riot's Vanguard anti-cheat software, explained. https://www.pcgamer.com/the-controversy-over-riots-vanguard-anti-cheat-software-explained.

[35] Vergilius. 2024. Vergilius. https://www.vergiliusproject.com/.

[36] VMProtect Software. 2024. Advanced {code} security made simple and reliable. https://vmpsoft.com/.

[37] Windows Server. 2023. bcedit. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bcedit.

[38] WIRED. 2019. A billion new players are set to transform the gaming industry. https://www.wired.com/story/worldwide-gamers-billion-players/.

[39] Xyrem. 2023. In-depth analysis on Valorant's Guarded Regions. https://reversin.g.info/posts/guardedregions/.

# A FUNCTION SIGNATURES

## A.1 MmCopyVirtualMemory

NTSTATUS NTAPI MmCopyVirtualMemory
(

PEPROCESS SourceProcess,
PVOID SourceAddress,
PEPROCESS TargetProcess,
PVOID TargetAddress,
SIZE_TBufferSize,
KPROCESSOR_MODE PreviousMode,
PSIZE_T ReturnSize
)

## A.2 KeReadVirtualMemory

NTSTATUS KeReadVirtualMemory (PEPROCESS Process,
PVOID addressSrc,
PVOID TargetAddr,
SIZE_T Size)

NTSTATUS status = STATUS_SUCCESS;
SIZE_T Bytes = NULL;
// Copy the virtual memory of the target
// to the virtual memory of the client
__try {
    MmCopyVirtualMemory (Process,
                          addressSrc,
                          PsCurrentProcess(),
                          TargetAddr,
                          Size,
                          KernelMode,
                          &Bytes);
    return STATUS_SUCCESS;
}
__except (EXCEPTION_EXECUTE_HANDLER) {
   DbgPrint("Memory read failed \n");
    status = GetExceptionCode();
    return status;
}

## A.3 OB_callback_entry

typedef struct OB_callback_entry_t {
    LIST_ENTRY CallbackList;
    _OBJECT_TYPE .CallbackList
    OB_OPERATION Operations;
    BOOL Enabled;
    OB_callback_entry *Entry;
POOBJECT_TYPEObjectType;
POB_PRE_OPERATION_callback PreOperation;
POB_POST_OPERATION_callback PostOperation;

KSPIN_LOCK_Lock;
} OB_callback_entry;