Exploiting A Vulnerability In BattlEye's Launching Chain To Hijack Kernel Protections Onto Any Usermode Application.
- Download BEService_arksa (from releases) into your C:\Program Files (x86)\Common Files\BattlEye
- Modify TargetGamePath in Main.c
- Compile with MSVC x64(Not LLVM/GCC)
- Run BattleJack
- Enjoy BattlEye Protections
BEDaisy.sys is also avaliable incase it gets patched, or you want to ensure stability.
BattleJack allows you to take the launcher commands for Battleye, send them to the service, and forge the loading process to poison the communication pipeline. Allowing you to secure your own process with BattlEye.
When you start BE's game launcher it will actually start the service, communicate the target game to the service, invoke itself again with the parameter "6".
The first launcher stays open, the secondary launcher stays open, verifies the cert of the game, opens the game and tells the service once it has done that. The second launcher then closes.
While the original one stays open and waits for the game to close. Its a pretty simple process. The issue is that the driver does verify the parent chain, this is due to a project by hypercall called FakeEye.
They patched hypercall's mechanisms by checking the boot owner of the secondary launcher's uniqueprocess within the driver.
Since they check the process chain, this shouldn't be possible should it? In classic BattlEye fashion they fucked that up.
For the sake of securing our own application; we don't need the driver execution to proceed past its initilization of the protected process, its ability to communicate with BEService and BEClient aren't needed.
In the state that we leave the application in, BEService has told BEDaisy that the game is open, to protect it, and to protect the secondary launcher. We keep the secondary launcher alive to maintain this state, as the next step in the launcher process is to close the secondary launcher, BEDaisy is waiting for it to close.
OBRegistercallbacks is initialized on the target process, and LSASS.exe/CSRSS.exe are hooked to prevent handles being generated to the game. You are secure against usermode handles.
Besides the clear anti debugging usecase; the intended usecase was to mitigate Vanguard's usermode VGM Module.
This module scans other usermode applications. As it would scan through my process, it would spam pagefaults, upsetting my anti debugging.
The simple solution is to hijack an anti cheat driver to prevent analysis.
This can also be used on heavy anti tamper systems and usermode anti cheats that scan usermode applications memory.
It served me well over the years; keeping intrusive anti cheats from setting off my loader protections.
Hypercall | His research into BELauncher powered this project.