How to Get Banned from Competitive Games Without Actually Cheating

TLDR: Researchers at the University of Birmingham demonstrated that modern kernel-level anti-cheats can be manipulated to ban innocent users by spoofing hardware identifiers or triggering false positives. By exploiting vulnerable signed drivers and manipulating BIOS/SPD data, they bypassed integrity checks to force bans on specific hardware configurations. This research highlights a critical risk where anti-cheat mechanisms can be weaponized to cause collateral damage to legitimate players.

Competitive gaming security has shifted heavily toward kernel-mode drivers, with titles like Valorant and Rainbow Six Siege deploying aggressive anti-cheat solutions that run at the highest privilege level. While these systems aim to stop memory manipulation and input automation, they have created a new, dangerous attack surface. The recent research presented at DEF CON 2025 by Sam Collins, Marius Muench, and Tom Chothia proves that these "robust" systems are not just failing to stop sophisticated cheats; they are actively vulnerable to being turned against the very users they are meant to protect.

The Mechanics of Forced Bans

Anti-cheat systems generally rely on two primary detection vectors: monitoring user-mode processes for known cheat signatures and enforcing kernel-level integrity checks to prevent unauthorized memory access. The researchers found that by manipulating the environment in which these anti-cheats operate, they could force the system to flag a machine as "cheating" even when no cheat software was present.

The most effective technique involved exploiting the "Bring Your Own Vulnerable Driver" (BYOVD) pattern. By loading a legitimately signed but vulnerable driver—such as an outdated Intel networking driver—an attacker can gain arbitrary read/write access to kernel memory. This access allows for the injection of malicious code or the modification of system structures before the anti-cheat driver initializes.

For example, the researchers demonstrated that by patching the CiValidateImageHeader function in the Windows kernel, they could force the system to return true for signature checks, effectively blinding the anti-cheat to unsigned code. Once the kernel is compromised, the anti-cheat can be fed false telemetry, or its own integrity checks can be triggered to cause a system crash or an automated ban.

// Simplified example of reading process memory via a vulnerable driver
HANDLE hProcess = OpenProcess(PROCESS_VM_READ, false, pid);
SIZE_T bytesRead = 0;
ReadProcessMemory(hProcess, (LPCVOID)baseAddress, &buffer, sizeof(buffer), &bytesRead);

Hardware ID Spoofing and Collateral Damage

Hardware ID (HWID) bans are the nuclear option for game developers. By collecting serial numbers from the motherboard, GPU, RAM, and NIC, anti-cheats create a unique fingerprint for a machine. If a user is banned, that fingerprint is blacklisted. The researchers showed that this system is fundamentally flawed because the hardware identifiers are often reported to the OS via software-accessible interfaces that can be spoofed.

The team successfully spoofed these identifiers by modifying the BIOS and the Serial Presence Detect (SPD) data on RAM modules. Using flashrom and custom adapters to interface directly with the SPI flash chips on the motherboard, they could rewrite the serial numbers stored in the firmware.

The process is surprisingly manual but highly effective:

1. Desolder the SPI chip or connect via an in-circuit programmer.
2. Dump the existing BIOS/SPD data.
3. Use a hex editor to locate and modify the serial number strings.
4. Flash the modified image back to the chip.

This technique is not just a way to evade a ban; it is a way to frame others. By dumping the HWID of a banned machine and flashing it onto a clean machine, an attacker can ensure the clean machine is immediately banned upon launching the game. This creates a secondary market for "pre-banned" hardware or allows malicious actors to destroy the reputation of other players.

Real-World Implications for Pentesters

For those conducting security assessments or bug bounty research, this work underscores that anti-cheat drivers are essentially rootkits. They operate with the same privileges as the OS and often implement their own "patch guard" mechanisms to prevent tampering. When testing applications that interact with these environments, you must account for the fact that the anti-cheat will treat any debugger or memory-access tool as a threat.

If you are performing an engagement where you need to analyze a game's network traffic or memory, you are likely to trigger these protections. The researchers' work shows that you don't need to be a "hacker" to get banned; you just need to have a configuration that the anti-cheat finds suspicious. This is a significant risk for developers who might be running virtualization or debugging tools on the same machine they use for gaming.

Defensive Considerations

Defenders, particularly those building anti-cheat solutions, face a difficult trade-off. The more aggressive the anti-cheat, the more it resembles the malware it tries to stop. To mitigate these risks, developers should move away from relying solely on HWID for identity, as it is inherently spoofable. Instead, they should implement more resilient, multi-factor authentication for accounts and focus on behavioral analysis that is harder to fake than static hardware serials.

Furthermore, the industry needs to address the OWASP risks associated with insecure drivers. The NVD and similar databases are filled with entries for vulnerable drivers that are still being used in the wild to facilitate these attacks. Until vendors implement stricter blocklists for signed drivers with known vulnerabilities, the BYOVD attack vector will remain a primary tool for both cheaters and those looking to cause chaos.

The research presented at DEF CON serves as a stark reminder that security through obscurity and high-privilege monitoring is not a substitute for sound architectural design. If your security model relies on the assumption that the user cannot modify their own hardware or kernel, you have already lost the game.