Guide for Direct Memory Access (DMA) attack techniques using FPGA hardware...
This skill covers Direct Memory Access research from the awesome-game-security collection, focusing on FPGA-based PCIe attacks, pcileech usage, physical-memory access workflows, and the defensive limits of software anti-cheat once a hostile device can read memory below the OS.
Cheat > DMAAnti Cheat > Detection:DMAAnti Cheat > Detection: Hacked HypervisorAnti Cheat > Detection:Virtual EnvironmentsAnti Cheat > Detection:HWIDWindows Security FeaturesDMA attacks exploit the ability of PCIe devices to directly access
system memory without CPU involvement. An attacker can:
- Read arbitrary physical memory
- Write to physical memory
- Bypass software-based protections
- Remain invisible to OS-level detection
- FPGA development board (Xilinx/Altera)
- PCIe interface capability
- Sufficient logic resources
- Development environment
- No hostile process needs to exist on the game PC
- No suspicious driver or injected module is required
- Reads can occur from a second machine over PCIe-attached hardware
- Traditional kernel callbacks and handle protection do not see the access
- IOMMU / VT-d policy determines whether DMA can access arbitrary memory
- Device impersonation can blur the line between legitimate hardware and FPGA firmware
- Secure Boot and TPM help with platform trust, but do not eliminate physical DMA risk
- Enumeration-based detection is useful but not sufficient against good firmware mimicry
pcileech is the primary framework for DMA-based memory access:
- Screamer PCIe (Xilinx Artix-7)
- PCIe Squirrel
- AC701 (Xilinx Artix-7)
- SP605 (Xilinx Spartan-6)
- Custom FPGA boards
# Memory dump
pcileech dump -out memory.raw -min 0 -max 0x200000000
# Process listing
pcileech pslist
# Read specific address
pcileech read -a 0x12345000 -l 0x1000
# Write to address
pcileech write -a 0x12345000 -v 0x41414141
- Vivado (Xilinx)
- Quartus (Intel/Altera)
- Open-source toolchains
- TLP packet generation
- Configuration space emulation
- MSI/MSI-X interrupt handling
- DMA read/write implementation
- Device ID spoofing
- Vendor ID masquerading
- Serial number randomization
- Capability structure emulation
Intel I210 NIC Emulation (most common target):
- Full PCI configuration space replication:
- Vendor ID: 0x8086, Device ID: 0x1533 (I210-AT)
- Subsystem Vendor/Device matching real OEM boards
- Capability list: PCIe cap, MSI-X cap, Power Management
- BAR layout: 128KB MMIO BAR0, optional I/O BAR2
- PHY register emulation: basic link status response
- No actual network traffic needed (NIC appears "cable unplugged")
Intel I226 NIC Emulation (newer boards):
- Device ID: 0x125C (I226-V)
- Updated capability structures (PCIe Gen3 vs Gen2)
- Requires correct ASPM (Active State Power Management) config
Detection vectors anti-cheat can inspect:
- Device does not respond to real NIC operational commands
- Missing DMA ring buffer activity (no Tx/Rx descriptors)
- Power state never transitions (always D0)
- PCIe link training characteristics differ from real silicon
- Compare config space values against known-good database
- Network adapters (Intel I210/I226)
- Storage controllers
- USB controllers
- Sound cards
1. Correct PCI configuration space
2. Proper capability structures
3. BAR (Base Address Register) setup
4. Interrupt handling
- Emulate Intel I210 NIC
- Proper device/vendor ID
- PHY register emulation
- Minimal functionality for detection evasion
// Typical pcileech API usage
HANDLE hDevice;
BYTE buffer[0x1000];
// Read physical memory
pcileech_read_phys(hDevice, physAddr, buffer, sizeof(buffer));
// Walk page tables to translate VA to PA
PHYSICAL_ADDRESS TranslateVA(UINT64 cr3, UINT64 virtualAddr) {
// PML4 -> PDPT -> PD -> PT -> Physical
UINT64 pml4e = ReadPhys(cr3 + PML4_INDEX(virtualAddr) * 8);
UINT64 pdpte = ReadPhys(PFN(pml4e) + PDPT_INDEX(virtualAddr) * 8);
UINT64 pde = ReadPhys(PFN(pdpte) + PD_INDEX(virtualAddr) * 8);
UINT64 pte = ReadPhys(PFN(pde) + PT_INDEX(virtualAddr) * 8);
return PFN(pte) + PAGE_OFFSET(virtualAddr);
}
- Scan physical memory for valid CR3 values
- Look for kernel structures
- Use signature scanning
- Validate page table entries
- CE server for DMA access
- Process memory reading via DMA
- Remote debugging capability
- Structure reconstruction
- Live memory viewing
- Pointer scanning
- DMA libraries (DMALib)
- Minimal VM libraries
- Game-specific cheats
1. No process attachment
2. No suspicious API calls
3. No kernel driver needed
4. No code injection
5. Operates below OS level
- Read-only for some implementations
- Timing-based detection possible
- Hardware fingerprinting
- Memory encryption (on newer systems)
- PCIe device enumeration
- IOMMU/VT-d monitoring
- DMA buffer analysis
- Performance counter anomalies
- Device identity consistency checks
- Platform attestation and boot-state validation
- Thunderbolt 1-4 / USB4 provide direct PCIe tunneling
- Hot-plug capable: device can be attached at runtime
- Pre-boot DMA: device has memory access before OS loads
- Thunderbolt Security Levels:
- SL0 (None): no security, legacy mode
- SL1 (User Auth): user must approve new devices
- SL2 (Secure Connect): device must match a previously approved UUID
- SL3 (No PCIe tunneling): completely disables DMA
- Thunderclap: malicious Thunderbolt peripherals bypass IOMMU
- Device re-identification: change device UUID to bypass SL2
- OS-level Thunderbolt driver vulnerabilities
- PCIe tunneling through USB4 hubs
- Kernel DMA Protection (Windows 10 1803+): automatic IOMMU for hot-plug
- Thunderbolt firmware verification
- Platform-level: BIOS setting to disable Thunderbolt PCIe tunneling
- macOS: T2 chip enforces DMA restrictions on Thunderbolt ports
- Maintain two sets of page tables (two CR3 values):
- "Clean" CR3: points to legitimate page tables visible to anti-cheat
- "Shadow" CR3: modified page tables with cheat-accessible mappings
- Swap CR3 before/after anti-cheat inspection windows
- Combine with EPT manipulation for hypervisor-level split
- Desync instruction TLB (iTLB) and data TLB (dTLB):
- Execute code from one physical page
- Read data from another physical page at same virtual address
- Requires precise TLB invalidation control
- Hypervisor can create EPT-based split: execute permission on page A,
read permission on page B, at same GPA
- Anti-cheat mitigation: TLB flush + re-walk, serializing instructions
- Legitimate CR3 value may pass all validation checks
- Shadow mappings only active during cheat execution windows
- Requires hypervisor or hardware-level inspection to detect
- Timing anomalies from frequent CR3 switches may be measurable
- pcileech-wifi: Wireless card emulation
- Remote memory access
- Extended range operation
- Ring -2 execution
- Highest privilege level
- Extremely stealthy
- Complex implementation
- Virtual Management Device
- Hide behind Intel VMD
- Complex detection evasion
/firmware
├── src/
│ ├── pcie_core.v # PCIe core
│ ├── tlp_handler.v # TLP processing
│ ├── dma_engine.v # DMA implementation
│ └── config_space.v # Config emulation
├── constraints/
│ └── board.xdc # Pin constraints
└── scripts/
└── build.tcl # Build script
// TLP packet handling
module tlp_handler (
input wire clk,
input wire [127:0] rx_data,
output reg [127:0] tx_data,
// DMA interface
output reg [63:0] dma_addr,
output reg [31:0] dma_data,
output reg dma_read,
output reg dma_write
);
- Security research only
- Authorized testing environments
- Responsible disclosure
- Legal compliance
- Physical hardware access required
- Potential system instability
- Detection by advanced anti-cheat
- Legal implications
The README contains:
Important: This skill provides conceptual guidance and overview information. For detailed information use the following sources:
Fetch the main README for the full curated list of repositories, tools, and descriptions:
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/README.md
The main README contains thousands of curated links organized by category. When users ask for specific tools, projects, or implementations, retrieve and reference the appropriate sections from this source.
For detailed repository information (file structure, source code, implementation details), the project maintains a local archive. If a repository has been archived, always prefer fetching from the archive over cloning or browsing GitHub directly.
Archive URL format:
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txt
Examples:
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/ufrisk/pcileech.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/000-aki-000/GameDebugMenu.txt
How to use:
{owner} with the GitHub username/org and {repo} with the repository name (no .git suffix).code2prompt.For a concise English summary of what a repository does, the project maintains auto-generated description files.
Description URL format:
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txt
Examples:
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/00christian00/UnityDecompiled/description_en.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/ufrisk/pcileech/description_en.txt
How to use:
{owner} with the GitHub username/org and {repo} with the repository name.Priority order when answering questions about a specific repository:
