Loading post...
Please wait
11 de junio de 2026
By Frank Casanova — for engineers who care about systems, trust, and the messy boundary between security and control.
If you have spent any time in systems programming, especially if Rust is your daily driver, you already understand why this story matters. Rust is not just another language with a clever borrow checker — it is an attempt to make a whole class of memory-safety bugs structurally impossible. Anti-cheat development started from the same concern but in a very different place: not memory safety, but trust boundaries.
When Riot Games made headlines by targeting certain hardware devices used for cheating, the public conversation quickly collapsed into outrage. But on this machine, I want to walk through what is actually happening under the hood, why the engineering community cares, and what the normal user should really be worried about.
Before we can discuss how cheats work, we need to understand what the game developer is defending. An online multiplayer shooter is, at its core, a distributed system.
In most games, the server is authoritative. It tracks the true state. But the client decides what to render. The server sends a stream of updates: "Player A is at coordinate (x, y, z)", "Player B turned 90 degrees", and so on. Then, on the GPU and CPU of your computer, the local game engine decides which of those players are visible to your in-game avatar based on field of view, distance, walls, and line of sight.
This is not a design flaw. It is a performance requirement.
flowchart LR
Server[Game Server] -->|Position updates| Client[Local Game Client]
Client -->|Render commands| GPU[Graphics API → GPU]
Client -->|Hidden checks| Visibility[Visibility Engine]
Visibility -->|Shows| Friendly[Friendlies / Environment]
Visibility -->|Hides| Enemy[Enemies Behind Walls]
Figure 1. Server-Client Rendering Pipeline. The local client holds full position data for all players but filters what reaches your eyes.
Imagine the alternative: the server calculates visibility and sends you only what you see. The latency would be noticeable. By the time your character turns a corner, the server has to detect that, compute visibility, send you the new allowed view, and only then can your client render. The client is deliberately given more information than it shows. A wallhack cheat just leaks this preloaded information.
Not all cheats are created equal. They range from trivial to terrifying, and the defenses scale accordingly.
The easiest cheat to understand is also the easiest to dismiss: read game memory, find the enemy position structure, overlay a red box. In Rust, this would be roughly equivalent to reading from a raw pointer. Except the game client is not giving you a safe API — it is running in the same address space, and the OS provides legitimate mechanisms that attackers abuse.
flowchart TB
subgraph User Process A — Game
GA[Game State Memory]
end
subgraph User Process B — Cheat
CB[Cheat Software]
OS[OS Debug Interfaces — ReadProcessMemory, etc.]
end
CB -->|Attaches via| OS
OS -->|Reads from| GA
GA -->|Leaks enemy positions| CB
Figure 2. Cross-process memory access. User-space cheats exploit OS debugging APIs, which are legitimate tools turned against their host.
Another path is hijacking the game's own execution. On Windows and Linux, programs load shared libraries at runtime. A trivially modified DLL can be placed earlier in the library search path, loaded before the real one, and then proxy calls through to the original while silently modifying rendering behavior.
Rust developers would find this reminiscent of LD_PRELOAD in Unix. It works exactly the same conceptually: interpose on symbol resolution.
The third major category is hooking graphics API calls. The game submits draw calls to a graphics API like DirectX, Vulkan, OpenGL, or Metal. The driver translates those into GPU commands. Between the game and the GPU is a long chain of abstractions, each of which is a potential interception point.
A hook can modify the depth test. If you disable depth checking on the enemy team's character models, they become visible through walls. The game did not do anything wrong — the rendering pipeline simply never applied that filter.
flowchart LR
Game[Game Engine] -->|Draw calls| API[Graphics API]
API -->|Translate| Driver[GPU Driver]
Driver -->|Commands| GPU[GPU Hardware]
Hook[API Hook — Cheat] -.->|Intercepts & modifies state| API
Hook -->|Disables depth test for enemies| Render[Render Pass]
Figure 3. Graphics API hook. The modification happens in the abstraction layer between engine and hardware.
Finally, there are purely user-mode overlays: the cheat runs outside the game process, reads game memory via debug APIs, computes target coordinates, and draws boxes on a transparent top-level window. This is why programs like MSI Afterburner (which shows FPS, temperatures, and GPU usage) share architectural DNA with wallhacks.
At first, anti-cheat was a DLL loaded alongside the game. It inspected files, scanned loaded libraries, and checked for known bad signatures. It was a user process inspecting other user processes. But the attacker always had the advantage: they could test 100 variations and publish the one that worked, while the defender had to cover all of them.
In security, there is a classic asymmetry: defense must work every time, while attack only needs to work once. This is sometimes called the "io_state" problem. A single successful bypass invalidates weeks of patching.
If you cannot win in user space, you go lower. If both the game and anti-cheat run as normal user processes, they are peers. But the kernel can see everything. By moving the anti-cheat into kernel space, the defender gains a strictly more powerful vantage point.
Let me be clear: the anti-cheat is not some kernel subsystem written by Microsoft or the Linux kernel team. It is a third-party driver, loaded as a kernel extension. In practice, this means the game developer is effectively saying: "We need privileged code on your machine to keep the game fair."
flowchart TB
subgraph User Space
Game[Game Client]
Cheat[Cheat Software]
AC_User[Anti-Cheat — User Mode]
end
subgraph Kernel Space
Kernel[OS Kernel]
AC_Kernel[Anti-Cheat — Kernel Driver]
end
Game -->|Pipes through| AC_Kernel
Cheat -->|Tries to manipulate| Game
AC_Kernel -->|Can inspect/read| Game
AC_Kernel -->|Can inspect/read| Cheat
Kernel -->|Enforces| AC_Kernel
Figure 4. Kernel-space anti-cheat observability. A kernel-mode driver can inspect both game and cheat, while user-space cannot see kernel-side decisions.
But the arms race did not stop at the kernel. Once the anti-cheat lived in kernel space, cheaters asked: while the kernel can see everything inside the machine, what if the cheat is not on the machine?
DMA is a feature of modern hardware. An IO device with DMA capability can read or write system RAM without the CPU's involvement. The GPU does this constantly to fetch textures and frame buffers.
A cheat can install a specially designed PCIe device. A small driver authorizes that device to perform DMA. Once authorized, the device reads the exact same RAM regions the GPU is reading — including enemy positions, health values, ammo counts — and sends the data out of the machine entirely.
The anti-cheat in kernel space has no visibility into a separate physical device's contents. It can see the driver, but it cannot see the device's internal logic once the DMA permission is granted.
flowchart TB
subgraph Gaming PC
RAM[System RAM]
CPU[CPU]
DMADevice[PCIe DMA Device]
Driver[Unauthorized/Legacy Driver]
KernelSpace[Kernel Anti-Cheat]
end
subgraph Attack PC
CheatLogic[Cheat Logic]
Display[Overlay / Aim Assist]
end
Driver -->|Grants DMA access| DMADevice
DMADevice -->|Reads RAM directly| RAM
DMADevice -->|Exfiltrates data via USB/Ethernet/WiFi| CheatLogic
CheatLogic -->|Returns aim instructions| DMADevice
DMADevice -->|Writes modified memory| RAM
KernelSpace -->|Can see driver & device, cannot read target's internal logic| DMADevice
Figure 5. DMA cheat architecture. The attack logic is offloaded to a separate machine; the gaming PC only sees a peripheral with memory-map access.
The weaponized DMA device can be disguised as a legitimate-looking GPU, network adapter, or capture card. Real, functioning hardware is often used as camouflage. You could have a slightly modified cheap GPU doing double duty: rendering your game normally, while also exfiltrating position data out through a debug port.
The secondary machine can be a Raspberry Pi, a phone, or anything with enough compute to do target prediction. You do not need a $4,000 workstation; you need something that can run vector math.
Given all this, the question is: what can a kernel-mode anti-cheat actually do against DMA?
The honest answer, from an engineering perspective, is: less than you might hope.
The anti-cheat can scan for suspicious device drivers, known malicious firmware signatures, and unusual DMA access patterns. If a device is accessing memory regions that no legitimate driver should be touching — at times when no game is even running — that is a signal.
The Riot approach, by all appearances, was this: buy the black-market DMA devices, reverse-engineer them, and add signatures for those specific devices/firmware/drivers to Vanguard. When the pattern is detected, either block the game or lock the system until the device is removed.
The anti-cheat can analyze system-level timing. A legitimate DMA transfer from a GPU typically follows certain patterns tied to frame rendering. A suspicious device transferring memory outside those windows is a red flag.
Remember that the anti-cheat driver is itself a kernel extension. If it has the power to make your computer unbootable, it also has the power to break things accidentally. When software runs at ring 0, there is no safety net. A bug in a Vanguard-like driver affects the whole kernel. This is not theoretical; it has happened.
When the public reacted to Riot's post, the question was: can a game company make your computer unusable? The answer splits into two interpretations.
Thermally, electrically, electromagnetically — could they damage your chipset? In theory, yes. Bad firmware or a misbehaving low-level driver can write to GPIOs, control fans, adjust voltages, and in extreme cases, brick components. But nobody is doing this deliberately in a commercial anti-cheat. The legal exposure, let alone the moral bankruptcy, is infinite compared to the value of catching a cheater in Valorant.
This is the realistic scenario. Kernel mode means the anti-cheat can:
From the user's perspective, the computer "does not work." Not because it is broken, but because the configuration has been rejected.
flowchart LR
Detect[Kernel AC Detects Suspicious Device] --> Response{Response Level}
Response -->|Soft| BlockGame[Block Game from Launching]
Response -->|Medium| Reboot[Force Reboot; Flag System]
Response -->|Aggressive| Bypass[Bypass Boot Path / OS Reinstall Required]
BlockGame --> UserSees[User Sees: "Cannot Launch"]
Reboot --> UserSees2[User Sees: "System Compromised"]
Bypass --> UserSees3[User Sees: "Computer Bricked"]
UserSees -.Feel Unusable.-> UserSees
UserSees2 -.Feel Unusable.-> UserSees2
UserSees3 -.Feel Unusable.-> UserSees3
Figure 6. Anti-cheat response escalation. The boundary between "blocked" and "bricked" is technical, but to the user the distinction is irrelevant.
Whatever your feelings about cheaters in Valorant, this is a systems-level pattern worth understanding.
Every piece of kernel-level code that ships to millions of machines is a permanent trust boundary shift. Windows has signed driver enforcement, but signing certificates have leaked before. Linux kernel modules are less strictly gatekept.
A DMA cheat device is, architecturally, a peripheral. It uses a legitimate hardware interface. The driver that authorizes it lives in the kernel. Subverting that trust chain requires no exploits — it uses the systems exactly as designed.
Rust programmers are familiar with the concept of safe abstractions over unsafe primitives. The kernel itself is fundamentally unsafe — it has to talk to hardware. Drivers are the bridge. And every bridge is attack surface.
For readers who want to understand the hardware side, here is the real mechanism.
Modern systems have an IOMMU (Input-Output Memory Management Unit). On Linux, this is the DMA-API subsystem. The IOMMU maps physical addresses visible to a device into a device-specific address space. Without IOMMU-enabled drivers, a device can potentially reach any physical RAM address — including where the kernel, your password manager, and your VPN client live.
DMA-capable PCIe devices request memory regions through the OS. The OS programs an IOMMU mapping. If a driver incorrectly grants access to a wider region than needed, it is a security vulnerability. The DMA cheat exploits this by requesting broad mappings.
A PCIe DMA write is a memory-mapped transaction. The device simply performs a bus write transaction to a physical address. No CPU is involved. No context switch. No kernel scheduler. This is why it is fast and why it is hard to detect from software.
stateDiagram-v2
[*] --> DeviceConnected: PCIe Device Plugged In
DeviceConnected --> DriverLoaded: Driver Installed
DriverLoaded --> DMAAuthorized: IOMMU Mapping Granted
DMAAuthorized --> ActiveExfiltration: Device Reads RAM
ActiveExfiltration --> ExternalProcessing: Data Sent to Second Machine
ExternalProcessing --> MemoryWriteBack: Second Machine Sends Commands
MemoryWriteBack --> ActiveExfiltration: Results Injected into Game
note right of DMAAuthorized
Anti-cheat can see driver
but cannot inspect device's
internal logic or DMA targets
end note
Figure 7. DMA cheat lifecycle. The cheat operates as a state machine whose internal state is invisible to the gaming machine.
Not all solutions require kernel mode. Some are surprisingly clever.
If enemy position data is being read by a process that is not the game, that introduces a detectable pattern. Cache timing attacks have been used to detect memory access patterns. In theory, anti-cheat can use performance monitoring counters (PMCs) to detect cache line access anomalies.
Linux exclusive: enabling kernel page-table isolation (KPTI) and strict memory mapping restrictions makes DMA attacks harder, because broader mappings require more explicit setup. IOMMU strict mode limits a device to only the pages it actually needs.
Intel TDX and AMD SEV offer encrypted memory regions that even physical DMA devices cannot read. Game developers in a position to ship products on cloud gaming infrastructure already get this protection for free — the data is encrypted before it reaches the host RAM. The cloud gaming model fundamentally changes the trust equation.
Software engineers need to internalize something important here.
When you press "run" on a .exe that installs a driver, you are granting it ring-0 privilege. That is the highest privilege level in x86/x64 architecture. It is the same privilege level as the kernel scheduler, the filesystem stack, and the network stack.
If the installer requires administrative approval and a reboot, understand why. It is not because the software needs "special permissions." It is because it is becoming part of the operating system's trusted computing base.
Vanguard, BattlEye, Ricochet — each of these anti-cheats has a kernel component. Each has been bypassed. Some kernel anti-cheats have introduced actual system instability. The permission model is fundamentally: we trust this driver completely, including its ability to read everything on your machine.
Microsoft's WHQL and driver signing requirements make it harder to inject unsigned drivers. But once a driver is signed, it is a broad trust grant. If that signature is extracted and reused by malicious software, or if the signed driver has vulnerabilities (buffer overflows in kernel drivers are a perennial finding), you are protected more by policy than by architecture.
The public backlash to Riot's DMA device blocking was rooted in legitimate concern, not just pro-cheat sentiment. Here is why non-cheating users care.
Streamers regularly use Elgato capture cards, which are PCIe DMA-capable devices. Professional audio interfaces can take similar paths. A kernel anti-cheat that behaves aggressively against all DMA-capable devices breaks people's setups.
Kernel heuristics can misfire. A security product that can render your system unbootable should have a higher reliability standard than one that just shows a notification.
A tool that can block cheating can also block arbitrary software. The same kernel driver that stops a DMA cheat could, with a firmware update, start scanning for VPNs, torrent clients, or any software the vendor considers undesirable. The trust model is a one-way door.
The future is not necessarily more kernel code.
Xbox Cloud Gaming, NVIDIA GeForce Now, and similar services run the game on hardware the user never touches. The user only receives a video stream. Memory never leaves the datacenter's IOMMU-managed hardware. DMA attacks require physical access to the host.
Hardware-isolated execution environments (Intel TDX, AMD SEV-SNP, ARM TrustZone) can encrypt a game's memory from the device bus itself. The guest OS cannot read its own guest memory without the CPU's cooperation. DMA devices are encrypted.
Endpoint detection and response (EDR) is converging with anti-cheat requirements. The same kernel observability that catches malware can catch cheats. The tooling exists. The question is who controls it.
What makes this video topic resonate beyond games is that it touches universal concerns in systems design.
The boundary between "we can" and "we should" is the engineer's responsibility. A kernel driver that checks for DMA devices can also misbehave, break hardware, and violate user trust. The fact that it is theoretically possible to make a computer unusable — via either software or hardware means — should not be taken as a green light.
The real lesson for software engineers is this: understand your trust model. Know what is in your TCB (Trusted Computing Base). Treat privilege escalation paths with the gravity they deserve.
A cheat from user space is annoying. A cheat from kernel space is existential to game integrity. A cheat from a separate physical machine is the boss fight. And anti-cheat approaching that boss fight with an equally powerful weapon — kernel-level authority — raises questions that go far beyond Valorant.
Let me close with an analogy for Rust developers.
Rust's borrow checker enforces memory safety at compile time by drawing strict boundaries around access to data. One owner, multiple immutable borrows, or one mutable borrow — never both. Kernel-level anti-cheat draws a strict boundary at the hardware level: one authority, the kernel, with total visibility; everything else is restricted.
The similarity ends when humans enter the system. Rust's borrow checker is verified logic. Kernel anti-cheat is deployed, updatable, and sometimes poorly written software running with the keys to the kingdom.
The borrow checker does not ask you to trust it. It guarantees invariants statically. A kernel driver asks you to trust it every time it touches memory. That trust must be earned, continuously, through robustness, review, and transparency.
If you write kernel code or drivers, your burden of proof is higher than for any user-space application. If you maintain or depend on a system that bundles a kernel anti-cheat, think carefully about what you are accepting in exchange for fairness.
This post was built from the transcript of Core Dumped's video "Can Game Companies Actually Make Your PC Unusable?" — a deep technical interview with a human host explaining how game cheating evolved from DLL injection to PCIe DMA attacks.