Guide – Anticheat Battleye Bypass Overview
Download Guide – Anticheat Battleye Bypass Overview for FREE
Battleye Hypervisor Detection
The cat and mouse game of game-hacking continues to fuel the innovation of exploitation and mitigation. The usage of virtualization technology in game-hacking has exploded ever since copy-pastable hypervisors such as Satoshi Tanda’s DdiMon and Petr Beneš’ hvpp hit the scene. These two projects are being used by most of the paid cheats in the underground hacking scene, due to their low barrier of entry and extensive documentation. These releases have with high certainty sped up the hypervisor arms race that is now beginning to show its face in the gamehacking community. Here’s what the administrator at one of the worlds largest game-hacking communities, wlan, says about the situation:
With the advent of ready-made hypervisor solutions for game hacking it’s become unavoidable for anti-cheats such as BattlEye to focus on generic virtualization detections
The reason hypervisors are so wide-spread now is because of recent developments in kernel anti-cheats leaving very little room for hackers to modify games through traditional means. The popularity of hypervisors could be explained by the simplicity of evasion, since virtualization enables you to more easily hide information from the anti-cheat, through mechanisms such as syscall hooks and MMU virtualization.
BattlEye has recently implemented a detection of generic hypervisors such as the previously mentioned platforms (DdiMon, hvpp) using time-based detection. This detection aims to spot abnormal time values in the instruction CPUID. CPUID is a relatively cheap instruction on real hardware, and will generally only require two hundred cycles, where as in a virtualized environment it may take up to ten times as long due to the overhead incurred by an introspective engine. An introspective engine is not like any real hardware which just performs the operation as is expected, it monitors and conditionally changes the data returned to the guest based on arbitrary criteria.
Fun fact: CPUID is commonly used in these time based detection routines because it is an unconditionally exiting instruction as well as an unprivileged serializing instruction. This means that CPUID acts as a ‘fence‘ and ensures that instructions before or after it are completed and makes the timing independent of typical instructions reordering. One could use instructions like XSETBV which also unconditionally exits, but to ensure independent timing would need to use some sort of FENCE instruction so that no reordering occurs before or after that would affect the timings reliability.
BattlEye communication hook
To combat masses of video game hackers, anti cheat systems need to collect and process a lot of information from clients. This is usually usually done by sending everything to the servers for further analysis, which allows the attackers to circumvent these systems through interesting means, one of them being hijack of the communication routine.
If an anti cheat is trying to detect a certain cheat by, for example, the name of the process that hosts the cheat code, it will usually parse the entire process list and send it to the server. This way of outsourcing the processing prevents cheaters from reverse engineering the blacklisted process names, as all they can see is that the entire process list is sent to the anti cheat server. This is actually becoming more and more prevalent in the anti cheat community, which raises some serious privacy concerns, simply due to the sheer amount of information being sent to a foreign server.
BattlEye, one of the world’s most installed anti cheats, uses such a routine to send data to their master server over UDP. This function is usually referred to as battleye::send or battleye::report (as in my previous articles). It takes two parameters: buffer and size. Every single piece of information sent to the BattlEye servers is passed through this function, making it very lucrative for hackers to intercept, possibly circumventing every single protection as the game can’t report the anomalies if a hacker is the middleman of communcations. Few cheat developers are actively using this method, as most of them lack the technical skills to reverse engineer and deobfuscate the dynamically streamed modules that BattlEye heavily relies on, but in this post i will shed some light on how this communication routine is being actively exploited, and how BattlEye has tried to mitigate it
How Escape from Tarkov ensures game integrity
Game-hacking is an always-changing landscape, and this requires anti-cheat developers to innovate and implement unique, unidentified detection mechanisms. In this article I will shed some light on the mysterious routines that are getting hundreds of cheaters banned in Escape from Tarkov. So let’s start from the beginning.
Escape from Tarkov (herein “Tarkov”) runs on the game engine Unity through Mono, which opens up for some interesting security issues that game-hackers can abuse to gain an advantage while playing. First of all, the Unity game assemblies are very hard to integry-check when they’ve been JIT-compiled. This is because you can’t simply store a hash value1 of the code, as the JIt-compiled methods might differ depending on what processor features are enabled.
This leaves the anti-cheat developers in a tough spot. It is not possible to ensure the integrity of JIT-compiler functions without either:
- Initialising before the game does then hooking the responsible JIT-engine. This hook can be used to cache hashes for all compiled functions for later comparison
- Resorting to alternative ways for ensuring game integrity, like checking image metadata.
While Tarkov actually has integrity checks (simple file hashing) in their Battlestate Games launcher application, this is trivial to patch out of the executable by opening the launcher executable in a tool likednSpyand simply removing the entire thing. The fact that this integrity check (internally called “consistency check” in the launcher) was so easy to circumvent, enabled thousands of cheaters to simply patch the game assembly on disk. This could include features such as “wallhack”, “no recoil” et cetera.
It seems like Battlestate Games got tired of this vulnerability, and to fix it, they likely called up the developers of the commercial anti-cheat BattlEye, which they’ve been utilizing for quite some time now. This article will explore a previously-unknown anti-cheat module that is being dynamically streamed and executed to Tarkov players circa 15-20 minutes into their raids.
Cracking BattlEye packet encryption – Escape From Tarkov
Recently, Battlestate Games, the developers of Escape From Tarkov, hired BattlEye to implement encryption on networked packets so that cheaters can’t capture these packets, parse them and use them for their advantage in the form of radar cheats, or otherwise. Today we’ll go into detail about how we broke their encryption in a few hours.
Analysis of EFT
We started first by analyzing Escape From Tarkov itself. The game uses Unity Engine, which uses C#, an intermediate langauge, which means you can very easily view the source code behind the game by opening it in tools like ILDasm or dnSpy. Our tool of choice for this analysis was dnSpy.
Unity Engine, if not under the IL2CPP option, generates game files and places them under GAME_NAME_DataManaged, in this case it’s EscapeFromTarkov_DataManaged. This folder contains all the dependencies that the engine uses, including the file that contains the game’s code which is Assembly-CSharp.dll, we loaded this file in dnSpy then searched for the string encryption, which landed us here:
This segment is in a class called EFT.ChannelCombined, which is the class that handles networking as you can tell by the arguments passed to it:
Right clicking on channelCombined.bool_2, which is the variable they log as an indicator for whether encryption was enabled or not, then clicking Analyze, shows us that it’s referenced by 2 methods…