dma-attack-techniques · git:20260414.dca5097 · 2026-04-14 · sha256 00f09931a7829672
dma-attack-techniques git:20260414.dca5097A

Name: dma-attack-techniques
Author: gmh5225
Immutable. This exact content is served forever at /api/v1/blob/00f09931a7829672.
---
name: dma-attack-techniques
description: Guide for PCIe DMA threat modeling, FPGA-based memory access, and defensive implications in game security. Use this skill when researching pcileech, BAR and TLP behavior, page-table walking, IOMMU or VT-d, device impersonation, firmware mimicry, or DMA detection and mitigation in game security research.
---

# DMA Attack Techniques

## Overview

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.

## README Coverage

- `Cheat > DMA`
- `Anti Cheat > Detection:DMA`
- `Anti Cheat > Detection: Hacked Hypervisor`
- `Anti Cheat > Detection:Virtual Environments`
- `Anti Cheat > Detection:HWID`
- `Windows Security Features`

## DMA Fundamentals

### What is DMA Attack?
```
DMA 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
```

### Hardware Requirements
```
- FPGA development board (Xilinx/Altera)
- PCIe interface capability
- Sufficient logic resources
- Development environment
```

## Defensive Context

### Why DMA Matters for Anti-Cheat
```
- 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
```

### Key Defensive Constraints
```
- 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 Framework

### Overview
pcileech is the primary framework for DMA-based memory access:
- Open-source memory forensics tool
- Supports multiple FPGA boards
- Extensive plugin ecosystem
- Active development community

### Supported Hardware
```
- Screamer PCIe (Xilinx Artix-7)
- PCIe Squirrel
- AC701 (Xilinx Artix-7)
- SP605 (Xilinx Spartan-6)
- Custom FPGA boards
```

### Basic Usage
```bash
# 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
```

## FPGA Firmware

### Development Tools
```
- Vivado (Xilinx)
- Quartus (Intel/Altera)
- Open-source toolchains
```

### Firmware Features
```
- TLP packet generation
- Configuration space emulation
- MSI/MSI-X interrupt handling
- DMA read/write implementation
```

### Anti-Detection Features
```
- Device ID spoofing
- Vendor ID masquerading
- Serial number randomization
- Capability structure emulation
```

### Firmware Mimicry Details
```
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
```

## Device Emulation

### Common Emulation Targets
```
- Network adapters (Intel I210/I226)
- Storage controllers
- USB controllers
- Sound cards
```

### Emulation Requirements
```
1. Correct PCI configuration space
2. Proper capability structures
3. BAR (Base Address Register) setup
4. Interrupt handling
```

### Example: Network Adapter Emulation
```
- Emulate Intel I210 NIC
- Proper device/vendor ID
- PHY register emulation
- Minimal functionality for detection evasion
```

## Memory Access Techniques

### Physical Memory Reading
```c
// Typical pcileech API usage
HANDLE hDevice;
BYTE buffer[0x1000];

// Read physical memory
pcileech_read_phys(hDevice, physAddr, buffer, sizeof(buffer));
```

### Virtual Address Translation
```c
// 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);
}
```

### DTB (Directory Table Base) Finding
```
- Scan physical memory for valid CR3 values
- Look for kernel structures
- Use signature scanning
- Validate page table entries
```

## Integration with Tools

### Cheat Engine DMA Plugin
```
- CE server for DMA access
- Process memory reading via DMA
- Remote debugging capability
```

### ReClass DMA
```
- Structure reconstruction
- Live memory viewing
- Pointer scanning
```

### Custom Implementations
```
- DMA libraries (DMALib)
- Minimal VM libraries
- Game-specific cheats
```

## Anti-Cheat Bypass

### Why DMA Bypasses Anti-Cheat
```
1. No process attachment
2. No suspicious API calls
3. No kernel driver needed
4. No code injection
5. Operates below OS level
```

### Limitations
```
- Read-only for some implementations
- Timing-based detection possible
- Hardware fingerprinting
- Memory encryption (on newer systems)
```

### Detection Methods
```
- PCIe device enumeration
- IOMMU/VT-d monitoring
- DMA buffer analysis
- Performance counter anomalies
- Device identity consistency checks
- Platform attestation and boot-state validation
```

## Thunderbolt / USB4 DMA

### Attack Surface
```
- 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
```

### Thunderbolt-Specific Attacks
```
- 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
```

### Defensive Measures
```
- 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
```

## Shadow CR3 / Split TLB

### Page Table Manipulation
```
- 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
```

### Split TLB Techniques
```
- 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
```

### Detection Challenges
```
- 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
```

## Advanced Techniques

### Wireless DMA
```
- pcileech-wifi: Wireless card emulation
- Remote memory access
- Extended range operation
```

### SMM (System Management Mode)
```
- Ring -2 execution
- Highest privilege level
- Extremely stealthy
- Complex implementation
```

### VMD Controller Emulation
```
- Virtual Management Device
- Hide behind Intel VMD
- Complex detection evasion
```

## Firmware Development Guide

### Project Structure
```
/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
```

### Key Components
```verilog
// 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 Considerations

### Ethical Use
```
- Security research only
- Authorized testing environments
- Responsible disclosure
- Legal compliance
```

### Risk Awareness
```
- Physical hardware access required
- Potential system instability
- Detection by advanced anti-cheat
- Legal implications
```

## Resource Organization

The README contains:
- pcileech and derivatives
- FPGA firmware projects
- DMA libraries
- Integration tools
- Device emulation firmware
- Anti-detection implementations

---

## Data Source

**Important**: This skill provides conceptual guidance and overview information. For detailed information use the following sources:

### 1. Project Overview & Resource Index

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.

### 2. Repository Code Details (Archive)

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:**
1. Identify the GitHub repository the user is asking about (owner and repo name from the URL).
2. Construct the archive URL: replace `{owner}` with the GitHub username/org and `{repo}` with the repository name (no `.git` suffix).
3. Fetch the archive file — it contains a full code snapshot with file trees and source code generated by `code2prompt`.
4. If the fetch returns a 404, the repository has not been archived yet; fall back to the README or direct GitHub browsing.

### 3. Repository Descriptions

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:**
1. Identify the GitHub repository the user is asking about (owner and repo name from the URL).
2. Construct the description URL: replace `{owner}` with the GitHub username/org and `{repo}` with the repository name.
3. Fetch the description file — it contains a short, human-readable summary of the repository's purpose and contents.
4. If the fetch returns a 404, the description has not been generated yet; fall back to the README entry or the archive.

**Priority order when answering questions about a specific repository:**
1. Description (quick summary) — fetch first for concise context
2. Archive (full code snapshot) — fetch when deeper implementation details are needed
3. README entry — fallback when neither description nor archive is available