Playing Dirty w/o Cheating - Getting Banned for Fun

Playing Dirty Without Cheating: Getting Banned for Fun and No Profit

Speakers: Sam Collins, Marius Muench, Tom Chothia Conference: DEF CON 33 YouTube: https://www.youtube.com/watch?v=FXIScbxJTZw Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Sam%20Collins%20Marius%20Muench%20Tom%20Chothia%20-%20Playing%20Dirty%20Without%20Cheating%20Getting%20Banned%20for%20Fun%20and%20No%20Profit.pdf

Overview

Modern anti-cheat systems are some of the most sophisticated rootkits deployed at consumer scale. They run at kernel level, intercept system calls, monitor loaded drivers, and in some cases enforce integrity from before the operating system boots. They are also, as researchers from the University of Birmingham demonstrated at DEF CON 33, systematically exploitable to ban players — including completely innocent players — without anyone actually cheating.

Sam Collins, Marius Muench, and Tom Chothia set themselves a perverse academic challenge: get permanently banned from online multiplayer games without using real cheat software. The constraints were strict — no actual cheats, no commercially purchased cheat tools — and the methodology had to be reproducible enough to formalize. What followed was an eighteen-month investigation into the inner workings of BattleEye, Vanguard, Easy Anti-Cheat, and other kernel-level anti-cheat systems, resulting in confirmed bans in Overwatch 2, Rainbow Six Siege, Apex Legends, and Fortnite, and a demonstration that Hardware ID bans can be imposed on arbitrary innocent machines through a chain of firmware manipulation and HWID poisoning.

The talk is simultaneously a practical dissection of how anti-cheat systems actually work, a catalog of techniques that trigger bans without any game state modification, and a sobering analysis of the false-positive surface created by systems that ban based on behavioral signals and hardware fingerprints rather than observed cheating behavior.

Background

▶ Watch: Getting banned: edge cases and false positives explored (0:14)

The Anti-Cheat Arms Race

Online multiplayer games represent billions of dollars in revenue, and cheating — using software to gain unfair advantages like aimbots, wallhacks, or speed modifications — is a persistent problem that degrades player experience and drives paying customers away. The anti-cheat industry has responded by deploying increasingly invasive monitoring software.

The evolution follows a predictable pattern:

1. User-mode detection: Monitor running processes, check for known cheat tool names, scan memory for cheat signatures
2. Kernel-mode detection: Run a signed kernel driver that has full access to system state, intercept driver loading, monitor kernel data structures
3. Boot-time enforcement: Use UEFI Secure Boot integration or hypervisor-based virtualization to detect tampering before the anti-cheat driver even loads
4. Hardware fingerprinting: Issue Hardware ID (HWID) bans that persist across OS reinstalls, targeting the physical machine rather than the account

Each escalation by anti-cheat developers has been answered by escalation from cheat developers, creating an arms race where both sides now operate at the deepest levels of the system stack.

Why Academics Can't Afford Cheats

The researchers are explicit about their constraints: as academics, purchasing commercial cheat software was out of scope. This limitation turned out to be a productive constraint — it forced them to find ways to trigger ban behavior using only techniques that a sophisticated attacker (or, crucially, an innocent victim of a false positive attack) might employ. Their goal was not to cheat, but to understand what anti-cheat systems interpret as cheating and whether that interpretation can be manipulated.

They used multiple hardware systems for testing to ensure isolation — a ban in one account/hardware configuration should not contaminate tests on another. They also had to deal with the asymmetric information problem of bans: game publishers typically do not notify users of bans immediately, do not specify the reason, and sometimes delay enforcement by days to make it harder for cheat developers to identify detection signatures.

Key Findings

▶ Watch: Kernel-level anti-cheat analysis and weaknesses (6:03)

What Gets You Banned (Without Cheating)

The research produced a clear taxonomy of ban-triggering techniques across different games and anti-cheat systems:

| Game | Anti-Cheat | Technique | Ban Confirmed |

|------|------------|-----------|---------------|

| Overwatch 2 | User-mode | Manual PE injection (without LoadLibrary) | Yes |

| Rainbow Six Siege | BattleEye (kernel) | Pre-loading vulnerable driver before game start | Yes |

| Apex Legends | Easy Anti-Cheat | Synthetic keyboard input macros | Yes |

| Fortnite | BattleEye | Non-whitelisted overlay window | Yes |

What Does NOT Get You Banned (But Crashes or Blocks Instead)

• Cheat Engine: Crashes Valorant; Fortnite kicks without banning
• Windows User Debugger: Fortnite kicks without banning
• Direct kernel memory read/write via open process handle: Blocked by kernel anti-cheat
• Vulnerable driver loading: Anti-cheat hooks driver load functions and unloads them
• Hypervisor-based anti-cheat bypass: Causes Blue Screen of Death, not a ban

HWID Ban Manipulation

Hardware ID bans can be imposed on innocent machines through a multi-step attack:

1. Dump the target machine's hardware fingerprint (HWID) via physical access, a live OS boot, or social engineering
2. Spoof the HWID on an attacker-controlled machine
3. Get the attacker's machine (now appearing as the target) banned
4. The target user logs into the game on their legitimately fingerprinted machine and receives a ban from the association

Technical Deep Dive

▶ Watch: Anti-cheat detection mechanisms and their limitations (19:33)

How Anti-Cheat Systems Detect Cheats

User-mode detection (used by Overwatch 2 before kernel-level checks) works primarily through process enumeration and memory scanning. The system scans running processes for known cheat tool names, checks loaded modules against a blacklist, and monitors for unauthorized code loaded into the game process's memory space. Naive implementations are defeated by renaming processes or loading code without the Windows LoadLibraryA / CreateRemoteThread API pair.

Kernel-mode detection (BattleEye, Vanguard) deploys a Microsoft-signed kernel driver that runs with Ring 0 privileges. This driver can:

• Intercept NtLoadDriver calls to prevent loading of unauthorized or vulnerable drivers
• Monitor loaded driver lists and unload suspicious entries
• Scan kernel memory for unsigned code
• Hook low-level input APIs to detect synthetic input patterns

Boot-time enforcement (Vanguard's highest security mode, required for ranked play) requires enabling Windows Secure Boot and verifying the boot chain. Vanguard uses this to ensure no unsigned code has been injected before the anti-cheat driver initializes. Additionally, Vanguard hooks the CPU's page fault handler — an extraordinarily deep hook that effectively kills PatchGuard (Microsoft's kernel integrity enforcement mechanism) and uses the processor's own exception handling to detect unsigned kernel code at access time.

Successful Ban Technique 1: Manual PE Injection (Overwatch 2)

Windows provides standard APIs for loading DLLs into a running process (LoadLibraryA) and creating threads in remote processes (CreateRemoteThread). Anti-cheat systems monitor these APIs specifically. A more sophisticated injection technique called manual mapping avoids both:

1. Allocate executable memory in the target process using VirtualAllocEx
2. Copy the DLL's PE sections directly into the allocated memory, resolving imports manually (walking the import table, resolving function addresses without calling Windows loader APIs)
3. Manually call the DLL's DllMain entry point
4. Hijack an existing game thread to execute the entry point code — avoiding the creation of any new threads visible to anti-cheat monitoring

The researchers loaded a benign DLL (their test payload, 1337.hex.dll) using this technique against a running Overwatch 2 instance. The result was a permanent ban with the stated reason: "Using unauthorized cheat programs or hacks." No game state was modified. No aimbot, wallhack, or speed modification ran. The mere presence of manually mapped code in the game process was sufficient.

Successful Ban Technique 2: Pre-Loading Vulnerable Driver (Rainbow Six Siege / BattleEye)

The cheat development ecosystem has long relied on vulnerable signed drivers — older drivers from legitimate hardware vendors that contain privilege escalation vulnerabilities, allowing user-mode code to obtain arbitrary kernel read/write via the driver's IOCTL interface. Anti-cheat systems combat this by maintaining a blocklist of known-vulnerable drivers and unloading them when detected.

The timing vulnerability the researchers exploited: BattleEye's driver blocklist is only enforced after the game launches. If a vulnerable driver is loaded before the game starts, BattleEye's driver monitoring may miss it during its initial enumeration.

The attack sequence:

1. Load a known-vulnerable driver before launching Rainbow Six Siege
2. Use the driver's vulnerability to gain kernel read/write
3. Inject code into the kernel address space
4. Unload the driver (removing it from the driver list before BattleEye can flag it)
5. Launch the game

BattleEye detected "funky behavior" in the kernel state (the injected code, even though benign in terms of game logic) and issued a ban. Again, no cheating occurred — only the behavioral fingerprint of how cheats load their kernel payloads.

Successful Ban Technique 3: Synthetic Input Macros (Apex Legends / Easy Anti-Cheat)

Rather than attacking memory or drivers, this technique targets the input subsystem. The researchers built a macro system using a "giant keyboard" simulation — a device that sends synthetic WM_KEYDOWN / WM_KEYUP messages and low-level input events. The macro held a key to fire rapidly at machine speed, mimicking rapid-fire modifications.

Easy Anti-Cheat's detection flagged this as aimbot/pixelbot behavior based on input timing analysis: the intervals between synthetic inputs were too precise to be human, and the inputs originated from a third-party device rather than registered user input devices. The ban was issued after several days of play. The researchers attribute the delay to anti-cheat systems deliberately holding bans in reserve to prevent cheat developers from quickly identifying what triggered detection.

Successful Ban Technique 4: Unauthorized Overlay (Fortnite / BattleEye)

Fortnite's implementation of BattleEye monitors for active overlay windows — applications that render on top of the game, which is how many cheats display wallhack information or aimbot assistance. BattleEye maintains a whitelist of approved overlays (Steam, Discord, NVIDIA Experience) and performs integrity checks on whitelisted applications to confirm they are authentic.

The researchers ran a simple dynamic overlay that moved across the screen without any game input or state access. It was not whitelisted and did not match any known-benign signature. BattleEye issued a ban for overlay detection.

HWID Collection and Manipulation

Hardware ID bans fingerprint the physical machine across multiple hardware components to resist ban evasion through account creation:

Components typically included in an HWID fingerprint:

• Memory module serial numbers (from SPD / EEPROM on each DIMM)
• Motherboard serial number and UUID (from DMI/SMBIOS)
• Network interface card MAC addresses
• GPU serial numbers
• Operating system installation ID

Extracting a target's HWID: The simplest method is physical access — boot the target machine from a live OS (USB stick with a custom script) and dump all identifiers. Alternatively, trick the target into running a script that performs the same enumeration.

Spoofing HWID in software: Commercial HWID spoofer subscriptions sell for $5/day or $20/week on cheat marketplaces. Software spoofers modify the values returned by Windows APIs that report hardware identifiers, making the system appear to have different hardware to anti-cheat software.

Hardware-level HWID modification:

Motherboard BIOS: The most reliable approach involves direct SPI flash manipulation:

• AFUDOS (AMI firmware utility) can dump and reflash BIOS images from within Windows, but many motherboards enable write protection by default
• Connecting a SOIC clip directly to the SPI flash chip allows physical read/write access, though power interference during operation can corrupt the flash
• Desoldering the SPI chip entirely, reading it via a chip programmer adapter, editing the serial numbers, and resoldering is fully reliable but requires soldering skills and risks permanent damage

RAM SPD (Serial Presence Detect):

• SPD is a small EEPROM on each memory module that stores timing parameters, manufacturer information, and serial numbers
• The researchers used a Raspberry Pi Pico with a DIMM adapter based on the "Bad RAM" project
• The SPD write-protect bit is cleared by briefly applying 7V to the appropriate pin, then the serial number bytes can be rewritten via I2C

HWID Poisoning Attack Chain

The complete attack to ban an innocent victim:

1. Obtain the victim's HWID (physical access, live boot, or social engineering)
2. Spoof the victim's HWID on the attacker's own machine
3. Trigger a bannable behavior on the attacker's machine (now appearing as the victim's hardware)
4. The victim logs into the game on their unmodified, legitimately identified machine
5. The anti-cheat system recognizes the hardware fingerprint as banned and issues the ban

The researchers demonstrated this live: Sam Collins performed the attack against Tom Chothia's Valorant account. Tom found himself banned on a machine he had never modified.

Amplifying with Malware

The researchers extended the HWID poisoning concept to malware scenarios, noting that adding HWID-based ban mechanisms to existing malware adds novel consequences:

• Banking trojans that steal credentials could also ban the victim from Rainbow Six Siege
• Cryptomining malware (Power Ghost) could ban the victim from Valorant — eliminating a competing use of CPU cycles
• A theoretical version of Stuxnet could ban nuclear facility engineers from Fortnite (delivered as a joke, but technically consistent with the attack pattern)

The practical implication: anti-cheat HWID ban systems that can be poisoned remotely turn any malware with physical access capability into a game-banning tool, creating a novel extortion vector.

Demo / PoC

▶ Watch: Live demonstration of anti-cheat bypass techniques (32:29)

The live demo involved Sam Collins conducting the HWID poisoning attack against Tom Chothia's Valorant account in real time during the DEF CON 33 presentation. Chothia's machine had an unlocked bootloader (a precondition established before the talk) but was otherwise unmodified and had never been used for cheating. Collins spoofed Chothia's HWID onto an attacker-controlled machine, triggered a Vanguard ban, and Chothia subsequently found his account banned when he attempted to log in.

Defensive Implications

▶ Watch: Responsible research approach and disclosure to game developers (42:29)

For Anti-Cheat System Developers

• Behavioral detection based on the mechanisms used to load code (manual mapping, vulnerable driver pre-loading) creates false positive surfaces that can be exploited to ban innocent players by making innocent machines appear to run cheat infrastructure.
• HWID ban systems that rely on hardware identifiers modifiable through software or accessible via physical manipulation are fundamentally gameable. HWID bans are useful friction for casual cheaters but fail against motivated adversaries and are weaponizable against innocent players.
• The most sophisticated anti-cheat systems (Vanguard's page fault hook approach) appear to successfully resist the techniques that work against less sophisticated systems — but they do so by hooking at a level that most security researchers would consider deeply invasive and appropriate only for dedicated security software.
• Valve's anti-cheat approach (server-side and behavioral analysis) appears more resistant to HWID poisoning scenarios because it relies less on hardware fingerprints.

For Players and System Owners

• Be aware that HWID bans can be remotely imposed by anyone with temporary physical access to your machine or who can socially engineer HWID disclosure.
• Pre-installed, banned GPUs are a realistic attack vector — purchasing used hardware could mean purchasing hardware with an active HWID ban.
• Macro devices and overlays can trigger bans even when used legitimately (e.g., accessibility macros, productivity overlays). Verify overlay applications are on anti-cheat whitelists before using them alongside games.

Key Takeaways

1. You can get permanently banned from major online multiplayer games without running any actual cheats — by mimicking the behavioral signatures of cheat loading infrastructure.
2. Manual PE injection (bypassing LoadLibraryA), vulnerable driver pre-loading, synthetic input macros, and non-whitelisted overlays are all confirmed ban triggers without game state modification.
3. HWID ban systems can be weaponized against innocent players by capturing, spoofing, and burning a victim's hardware fingerprint on a banned machine.
4. BIOS SPD modification and SOIC chip manipulation allow persistent hardware identifier changes that software-level HWID spoofing cannot match.
5. The HWID poisoning technique can be combined with existing malware payloads to add game banning as a novel attack consequence.
6. The most sophisticated anti-cheat systems (Vanguard) operate at a deeper system level than most security software and successfully resist the techniques that compromise BattleEye and Easy Anti-Cheat.
7. Anti-cheat systems function as kernelmode rootkits; understanding their detection logic is essential for both offensive security researchers and for building detection-resistant legitimate software.

About the Speakers

Sam Collins is a PhD student at the University of Birmingham specializing in memory attacks and low-level reverse engineering. He has developed hackable game environments used in undergraduate security courses at Birmingham, making him uniquely positioned to approach the anti-cheat problem from both offensive and pedagogical angles.

Marius Muench is a systems security professor at the University of Birmingham whose research focuses on smartphone security, embedded systems, and low-level reverse engineering. His work with the RP2350 (Raspberry Pi Pico 2) and similar microcontrollers informs the hardware manipulation techniques used in the HWID modification component of this research. He is the group's expert on hardware-level attack infrastructure.

Tom Chothia is a full professor at the University of Birmingham. He teaches game hacking as part of the university's security curriculum — a course that provided much of the initial framework for this research. His prior published work includes security analyses of Apple Pay, Visa contactless payments, Square payment terminals, and Bank of America payment infrastructure. He was also the willing victim of the live HWID poisoning demonstration, having his Valorant account banned in front of a DEF CON audience for the benefit of the research.

The University of Birmingham team's research code and a deeper technical analysis of Vanguard's page fault handler hook mechanism are available on GitHub, with an extended Black Hat version of the Vanguard analysis also linked from the slides.