- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 729
- Reaction score
- 457
Anyone currently digging into the kernel environment for R6 probably knows that while Secure Boot isn't a hard requirement yet, BattlEye is getting increasingly aggressive with its detection vectors. I've been looking into a plan for an external that skips the usual manual mapping headache and goes straight for physical memory access via BYOVD.
The Logic: Secure Boot & VBS
With Secure Boot off, VBS/HVCI usually isn't in the way, making the kernel a lot less restrictive. However, BE still likes to play dirty. Based on analysis of their pushed shellcode, they aren't just walking PsLoadedModuleList or using EnumDeviceDrivers anymore. They are actively enumerating drivers, reading certificates, and even dumping binaries if they find suspicious strings. If you're running an unsigned driver—even manually mapped—you're basically asking for a flag.
BYOVD Physical Memory Mapping
The strategy involves using a vulnerable signed driver (think old hardware monitors or system utility tools) that carries a legitimate Authenticode certificate. Instead of loading custom kernel code, we leverage the driver's own IOCTL to map arbitrary physical memory into user space.
Architecture & Detection Risks
While this method avoids the "unsigned code in kernel" trap, it's not a silver bullet. BattlEye has been known to track specific IOCTL patterns. Even if the driver is signed, if the anti-cheat sees a generic user-mode process calling an IOCTL known for physical memory mapping (like certain versions of MapPhysicalMemory), it might trigger a manual review or a heuristic ban.
The goal here is to be as invisible as possible by using the system's own trusted (but broken) tools against it. If the cert is clean and the IOCTL isn't burned, this should theoretically stay under the radar for a while.
Has anyone caught a ban lately using this specific mapping method on BE, or are they still mostly focused on sig-scanning manual mappers?
The Logic: Secure Boot & VBS
With Secure Boot off, VBS/HVCI usually isn't in the way, making the kernel a lot less restrictive. However, BE still likes to play dirty. Based on analysis of their pushed shellcode, they aren't just walking PsLoadedModuleList or using EnumDeviceDrivers anymore. They are actively enumerating drivers, reading certificates, and even dumping binaries if they find suspicious strings. If you're running an unsigned driver—even manually mapped—you're basically asking for a flag.
BYOVD Physical Memory Mapping
The strategy involves using a vulnerable signed driver (think old hardware monitors or system utility tools) that carries a legitimate Authenticode certificate. Instead of loading custom kernel code, we leverage the driver's own IOCTL to map arbitrary physical memory into user space.
- Identify a signed driver not yet blacklisted by BE.
- Utilize its IOCTL to map game physical pages directly to the cheat process.
- No ReadProcessMemory, no handle stripping, and zero custom kernel footprints.
- Overlay execution via process hijacking (Medal, Discord, or similar trusted overlays).
Architecture & Detection Risks
While this method avoids the "unsigned code in kernel" trap, it's not a silver bullet. BattlEye has been known to track specific IOCTL patterns. Even if the driver is signed, if the anti-cheat sees a generic user-mode process calling an IOCTL known for physical memory mapping (like certain versions of MapPhysicalMemory), it might trigger a manual review or a heuristic ban.
Anti-Cheat Checks: BE's shellcode can check for specific driver symbols or strings that match known mapping vulnerabilities.
Overlay Safety: Hijacking is safer than creating a top-most window, but ensure the target process doesn't perform its own internal integrity checks on the rendering hook.
Communication: If you're not careful with your IOCTL calls, the sheer volume of reads could be an outlier in their telemetry data.
Overlay Safety: Hijacking is safer than creating a top-most window, but ensure the target process doesn't perform its own internal integrity checks on the rendering hook.
Communication: If you're not careful with your IOCTL calls, the sheer volume of reads could be an outlier in their telemetry data.
The goal here is to be as invisible as possible by using the system's own trusted (but broken) tools against it. If the cert is clean and the IOCTL isn't burned, this should theoretically stay under the radar for a while.
Has anyone caught a ban lately using this specific mapping method on BE, or are they still mostly focused on sig-scanning manual mappers?
