UEFI Pre-Boot Gap Explained: How Motherboard Firmware Became an Anti-Cheat Battlefield

What IOMMU is and why it matters for cheats

Every modern CPU has a memory management unit that controls which software processes can access which parts of RAM. That is well understood. What is less understood is that a separate unit does the same job for hardware devices: the IOMMU, Input-Output Memory Management Unit.

A PCIe device, a GPU, a network card, a storage controller, can all issue direct memory access requests. DMA lets hardware read and write RAM without involving the CPU, which is why it is fast. Without the IOMMU, any PCIe device has unrestricted access to the entire physical address space. With the IOMMU active, each device gets a translation table that maps which memory regions it is authorized to access. A device that tries to read outside its authorized range gets blocked at the hardware level, before the request reaches any software.

DMA-based cheats work by inserting a PCIe card into the game machine that reads game memory and sends it to a second computer where the cheat runs. The IOMMU is the hardware mechanism that is supposed to stop that. When the IOMMU is working correctly, the rogue PCIe card cannot read game process memory because it has no authorization entry for those addresses.

The gap is what happens when the IOMMU is supposed to be working but is not.

The pre-boot gap: IOMMU was lying

Vanguard's security team discovered that a significant number of motherboards were reporting IOMMU as active while not actually initializing it during the early boot phase. The firmware would set the IOMMU-enabled flag in its data structures, Windows would read that flag and trust it, and the operating system would behave as if DMA protection was in place. It was not.

The specific failure was in the timing of IOMMU initialization. The firmware is responsible for bringing hardware security features online during the pre-OS boot phase. For some combinations of firmware version and motherboard model, the IOMMU hardware was not being fully initialized before the operating system loaded and began trusting the IOMMU-active flag. The window between power-on and full OS control, measured in milliseconds on modern hardware, was enough for a PCIe device to establish memory access before the protection came up.

The OS never saw the gap because the firmware reported protection as active before the OS could query it. Windows trusted the firmware. The firmware was wrong.

How DMA hardware exploited the gap

DMA cheat setups use a PCIe FPGA card, most commonly based on Xilinx silicon, inserted into an available slot on the game machine. The card presents itself as a legitimate device to the PCIe bus. On systems where the IOMMU was not fully active during early boot, that card had unrestricted access to physical memory before any anti-cheat software was running.

[00.001ms] UEFI POST begins
[00.014ms] PCIe bus enumeration: DMA card detected at slot B2
[00.016ms] IOMMU flag set ACTIVE in firmware table (hardware NOT yet initialized)
[00.018ms] DMA card: unrestricted physical memory access window OPEN
[00.021ms] DMA card: scanning for game process base address... found
[00.024ms] DMA card: cheat payload mapped to target memory region
[00.890ms] Secure Boot: bootloader signature verified OK
[01.240ms] Windows kernel loading
[02.100ms] IOMMU hardware initialization begins (OS-requested)
[02.104ms] IOMMU reports protection active (was already flagged active since 00.016ms)
[04.800ms] Vanguard driver loads
[04.802ms] IOMMU status check: ACTIVE (no indication of pre-init window)
[04.803ms] DMA cheat: operational. Payload loaded before protection came up.

The critical line is at 00.016ms: the firmware flags IOMMU as active, but the hardware has not been initialized. The DMA card gets its access window before Secure Boot verification even runs. By the time Vanguard loads at 04.800ms and queries IOMMU status, the protection reports as active because it is active by then. The cheat payload is already in place, loaded before any protection existed to stop it.

This is why kernel-level anti-cheat with ring-0 access was not sufficient to catch this attack vector. The attack predates the kernel load.

How Vanguard found and closed it

Riot's anti-cheat team identified a pattern in ban appeals and hardware analysis: players on certain motherboard models were producing anomalous memory behavior that was consistent with DMA access but that passed IOMMU integrity checks at the OS level. The inconsistency pointed to the pre-OS phase.

The investigation produced a firmware test: boot the system, measure actual IOMMU hardware state at the earliest possible point, and compare it to what the firmware reported. On affected motherboards, the gap was measurable. The firmware was reporting a state that the hardware had not reached yet.

Riot then did something unusual for a game company: they contacted ASUS, ASRock, Gigabyte, and MSI directly with the findings and coordinated a firmware patch release. The patches force IOMMU hardware initialization to complete before the firmware sets the active flag, closing the window that DMA cards were using.

Vanguard's client now checks for the patched firmware state at launch. Systems that cannot confirm proper IOMMU initialization receive a VAN:Restriction error and cannot start Valorant until the BIOS is updated. For high-Elo players specifically, the check is enforced more strictly.

The CVEs: which motherboards were affected

All four manufacturers released patches. The patches are distributed as BIOS updates through each manufacturer's support pages. Systems that have not applied the update remain in the vulnerable state for other exploit vectors, though Vanguard's launch block means Valorant players on affected hardware are effectively required to update before playing.

What "patched" actually means for the cheat side

The patch closes the specific pre-boot window that allowed DMA cards to establish memory access before IOMMU came up. It does not eliminate DMA cheating entirely. It raises the cost significantly.

On a patched system, the IOMMU is active from the first millisecond of PCIe bus enumeration. A DMA card inserted into the slot gets an authorization entry that covers only its legitimate function, which for a standard Xilinx FPGA is nothing related to game memory. Any attempt to read outside its authorized memory range is blocked at the IOMMU hardware level, before any software receives the request.

Bypassing this requires either a card that presents itself as a device the IOMMU grants legitimate memory access to (a technique that requires custom firmware on the FPGA that mimics a trusted device's identity), or operating at a privilege level above the IOMMU itself, which means compromising the firmware or exploiting a CPU vulnerability. Neither approach is available off-the-shelf. They require significant engineering investment per target platform.

The current state of DMA cheating after the patch wave

The patch wave changed the DMA cheat market substantially. Products that relied on the pre-boot window no longer work on patched systems. Providers who built their DMA implementations around the gap had to either retool or exit the market. The retooling options are expensive in engineering terms and narrow the viable target set, because the techniques required to bypass a properly initialized IOMMU are platform-specific and require continuous maintenance as firmware updates change the relevant code paths.

What remains viable is DMA operation within the IOMMU's authorized window. An FPGA card that convinces the IOMMU it is a legitimate device gets an authorized range, and operations within that range are not blocked. This is a smaller and harder-to-exploit surface than the pre-boot gap, but it is not zero.

The broader picture is that anti-cheat enforcement has moved progressively deeper into hardware: from process scanning to kernel drivers to firmware validation to TPM attestation. Each layer closes a surface that the previous layer left open. The pre-boot gap patch is one step in that progression, not the end of it.

For how the TPM layer works and why it closes attack surfaces that IOMMU patching leaves open, see TPM and Remote Attestation Explained. For how behavioral detection operates as a separate enforcement layer independent of hardware entirely, see Behavioral Biometrics Explained. And for the specific question of what a HWID Spoofer covers and what it does not, the kernel-level interception and cleaner system operates on a different surface than any of the firmware-layer topics covered here.