DMA Hardware Cheats Explained: How They Work and How We Catch Them

A deep technical dive into Direct Memory Access hardware cheats, why Windows Kernel DMA Protection is not enough, and why we recommend a proprietary hypervisor-based anticheat for studios that take protection seriously.

What Is a DMA Cheat?

A DMA cheat is a hardware device, typically an FPGA card like PCILeech, Squirrel or ZDMA, plugged into a second PC or directly into a PCIe slot (or a Thunderbolt enclosure) on the gaming PC. The card uses Direct Memory Access, a legitimate PCIe feature that lets hardware read and write system RAM without going through the CPU. Because the read comes from hardware instead of the game process, no in-process code ever touches the game's memory. The cheat runs entirely outside the reach of usermode API hooks, kernel syscall filters, module enumeration, and traditional memory integrity checks. The second PC typically hosts an AI aimbot, a radar overlay, or an ESP that gets its data from the DMA card and either feeds inputs back over USB (via an Arduino or Kmbox) or simply draws on a separate monitor. This class of cheat has become dominant in the last two years because it completely sidesteps how most anticheats are architected.

Why DMA Cheats Are Hard to Detect

Every other class of cheat leaves a footprint inside the game process: a hook, a patched byte, a modified memory region, an injected module. DMA cheats leave nothing. The game process looks pristine because nothing was ever done to it from inside. Behavioral and pattern-based approaches do not catch DMA cheats either, because a skilled player using a DMA radar still clicks like a human: the advantage is information, not input. The cheater just happens to always know where the enemies are, always pre-aim corners, always push the right lane. There is no statistical signal in the input stream to latch onto.

Fingerprinting: The PCIe Configuration Space

What you can look at, however, is the PCIe bus itself. Every PCIe device, legitimate or malicious, has to present a Configuration Space to the host. That is 256 bytes (or 4 KB for PCIe Extended config) of fields that the OS reads to figure out what the device is and how to talk to it. The key fields include: Vendor ID (for example 0x10EC for Realtek, 0x8086 for Intel, 0x10DE for NVIDIA), Device ID (a specific chipset within that vendor), Class Code (network adapter, audio controller, storage, etc.), Subsystem Vendor ID and Subsystem Device ID (identifies the board manufacturer), Revision ID, and the BAR (Base Address Register) layout. The first generation of DMA cheats did not bother hiding any of this. A stock PCILeech card shows up with a Xilinx or Lattice FPGA vendor ID, no matching subsystem pair, an unusual class code, and a BAR layout that does not look like anything a consumer would plug in. HyperAntiCheat's scanners enumerate all PCIe devices at runtime and check every one of these fields against a database of known-good hardware. A device that does not match any legitimate vendor and device pair, or whose subsystem IDs contradict its primary ID, is flagged as forensic evidence of a rogue DMA device.

Full Config Space Spoofing and Why It Is Still Detectable

More recent DMA cheat firmware has started fully spoofing the configuration space to impersonate a specific NIC or audio codec, copying the Vendor ID, Device ID, Subsystem IDs, and even the BAR layout of a real product. This is harder to detect by ID alone, but full spoofing is structurally difficult. The device still has to expose MSI or MSI-X interrupt capabilities, power management registers, latency tolerance reporting values, link speed and width that match the advertised part, and a consistent capability pointer chain. Discrepancies in any of those secondary fields, a real Intel NIC advertising a link state that the part was never shipped with, a claimed audio codec exposing no BAR for audio streaming, a subsystem pair that was never used by the real manufacturer, are all detectable. HyperAntiCheat cross-references the full config space against a reference database of what real parts actually present to the host, and flags any mismatch. It is an ongoing race, but it is a race we can actually run because the evidence is concrete and reproducible, not statistical.

Windows Kernel DMA Protection, and Why It Is Not Enough

Microsoft introduced Kernel DMA Protection in Windows 10 specifically to stop DMA attacks. It uses the IOMMU (Intel VT-d or AMD-Vi) to remap all DMA accesses through a translation layer, so that a rogue PCIe device cannot read arbitrary system memory. When it works, it is an excellent defense. The problem is that it does not always work. Kernel DMA Protection requires: an IOMMU-capable CPU and chipset, the IOMMU enabled in BIOS/UEFI (usually called VT-d on Intel, AMD-Vi on AMD), firmware that correctly initializes the IOMMU before PCIe devices are enumerated at boot, Windows 10 1803 or later, and the feature enabled in the OS. Many consumer motherboards do not expose the IOMMU setting at all, or expose it but fail to initialize it correctly at early boot. In December 2025, a UEFI firmware vulnerability tracked as CERT/CC VU#382314 was disclosed affecting a broad range of ASRock, ASUS, GIGABYTE and MSI boards: the firmware reports to the OS that DMA protection is active, but fails to actually initialize the IOMMU in the boot sequence. Until the board is flashed with a fixed BIOS, a malicious PCIe device plugged in before boot can read and write system memory unimpeded. Riot's Vanguard has started enforcing BIOS updates on affected boards as a condition for launching the game, which is a strong signal of how serious the issue is and how much of the installed base is still vulnerable. So even on the latest Windows builds, on a motherboard that nominally supports Kernel DMA Protection, a significant fraction of players are effectively running with DMA protection disabled and have no idea.

The Real Solution: a Hypervisor-Based Anticheat

The structural limitation of any kernel-mode-only anticheat is that it runs at the same privilege level as the kernel cheat it is trying to catch, and one privilege level too high to constrain DMA hardware. A kernel-level cheat with equal ring-0 access can try to hide its own memory, patch the anticheat's scanners, or unload the driver. A DMA cheat does not even need ring-0 at all because it bypasses the CPU entirely over hardware. A hypervisor solves both problems by running one privilege level higher than the OS. The anticheat installs a thin Type-1 hypervisor that virtualizes the running Windows instance and intercepts: every attempt to access the game's critical memory pages (via EPT or NPT violations on Intel and AMD respectively), every privileged instruction the OS would normally execute unchecked (CR3 writes, MSR writes, CPUID, VMCALL), and every DMA remapping operation that the IOMMU would handle. Because the hypervisor runs under the OS, nothing in the OS, not a kernel cheat, not a rogue driver, not even a signed driver loaded by the attacker, can tamper with the hypervisor's memory or disable its protection. And because the hypervisor owns the IOMMU configuration directly, it can enforce DMA protection without relying on the motherboard BIOS to do it correctly. This is the only architecture that structurally beats both kernel-level cheats and DMA hardware cheats.

Why HyperAntiCheat Recommends a Custom Hypervisor

For studios with a high cheating risk profile, competitive shooters, esports titles, games with a large paid cheat ecosystem, we strongly recommend the custom hypervisor deployment of HyperAntiCheat. It is not the default (most titles do not need it and the engineering cost is higher), but for publishers who ask, we build and ship a proprietary hypervisor tailored to the game. That means: protected memory ranges that cover the game's critical data structures, custom EPT policies that block any unauthorized read of game memory whether from kernel code, another process, or a DMA device, direct IOMMU enforcement that is not dependent on the motherboard firmware doing the right thing, and full integration with our standard forensic detection pipeline, so every hypervisor-level violation is logged with a reproducible artifact. A hypervisor-based anticheat gives a fundamentally stronger guarantee than any kernel driver alone. If you are building a competitive title and DMA cheats are on your threat model, a custom HyperAntiCheat hypervisor is the answer, and we strongly recommend it.

The Bottom Line

DMA hardware cheats are the frontier of the cheat ecosystem. They bypass everything that lives inside the game process, and Windows' built-in defense is too dependent on motherboard firmware to be reliable. The answer is forensic detection at the PCIe layer combined with a hypervisor that enforces memory isolation independently of the OS and the BIOS. HyperAntiCheat does both: we fingerprint and cross-validate every PCIe device on the system, and for studios that need maximum protection we build a custom proprietary hypervisor to back it up.