DMA hardware fingerprinting PCILeech and Squirrel detection

PCILeech (Ulf Frisk, 2016) is an open-source framework that reads and writes arbitrary physical memory over DMA — an attack primitive that predates software anti-cheat entirely. Its hardware backends are FPGA boards (Xilinx and Intel Altera families) that speak PCIe to the target machine and USB or Thunderbolt to the attacker-controlled controller machine. Because the read path bypasses the CPU and operating system entirely, no ring-0 driver is required on the target, and no Windows API is called. The game process cannot observe the memory reads.

The commercial cheat market adapted this rapidly. By 2023, boards branded “Squirrel” (35T variant), “CaptainDMA” (75T), and several unbranded Aliexpress variants were shipping with pre-loaded PCILeech firmware and cheat-compatible memory-read libraries. The standard counter — checking the PCIe device tree from within the OS — is defeated by copying the Vendor ID and Device ID from a legitimate NIC or capture card. A naive check against Win32_PnPEntity returns the spoofed identity.

Our research documents why Vendor/Device ID spoofing is necessary but not sufficient: the full 256-byte (standard) and 4096-byte (extended) PCIe configuration space contains structural properties that FPGA firmware does not faithfully replicate, and cannot replicate at arbitrary cost without a full hardware re-spin.

We assume an operator who:

• Has physical access to their own machine and has installed a DMA board in a free PCIe slot. The board is connected to a second machine (“attack PC”) running the cheat and read logic.
• Has flashed the board's PCIe configuration space (the “device shadow”) to present a cloned Vendor/Device ID from a common peripheral — we observed Realtek NIC (0x10EC/0x8168), ASmedia USB controller (0x1B21/0x1042), and an Elgato capture card (0x1CE4/0x0003) as the most common donor identities.
• May have purchased a “custom firmware” service that further tweaks the Subsystem ID and Device Serial Number capability. We account for this class.
• Does not have the ability to modify the physical FPGA fabric or introduce real hardware capability registers — only the configuration-space shadow in flash is under software control.

Every PCIe device exposes a 256-byte (legacy PCI compatible) or 4096-byte (PCIe extended) configuration space. The first 64 bytes are the standard header; beyond offset 0x40, Capability structures form a linked list terminated by a null Next Pointer. Extended capabilities live in the extended space starting at 0x100.

The fields an operator can update by reflashing a Xilinx BRAM-based config shadow include: Vendor ID (0x00), Device ID (0x02), Subsystem Vendor ID (0x2C), and Subsystem ID (0x2E). Registers that are either hard-wired in the FPGA IP core or computed dynamically include:

• BAR registers (0x10–0x24) — Base Address Registers declare the size and type (MMIO / I/O, 32-bit / 64-bit, prefetchable) of each memory window the device requests. FPGA PCIe IP cores offer a fixed menu of BAR sizes dictated by the synthesis parameters; a Realtek NIC's typical single 256-byte I/O BAR + 64 KB MMIO BAR is trivially distinguishable from the 256 MB MMIO BAR typical of a XDMA-based FPGA core.
• Capability list — the chain of capabilities at offsets 0x40+ depends entirely on which PCIe IP features the FPGA RTL instantiates. A genuine Realtek card carries MSI-X, Power Management, and Vital Product Data capabilities at specific offsets; Xilinx XDMA IP instantiates MSI / MSI-X, Power Management, Express, AER, and — critically — Device Serial Number (DSN). DSN is rare on consumer NICs and serves as a high-specificity signal when present on a device claiming to be one.
• Link Speed / Width negotiation — observable in the PCIe Express Capability register. A board advertising a Realtek GbE NIC but negotiating PCIe Gen2 x1 with a 5 GT/s link speed is anomalous (GbE NICs are PCI 2.0 / PCIe 1.1 devices).

The configuration space is readable from Windows via the SetupDiGetDeviceRegistryProperty / SetupAPI path for some fields, and directly via a kernel-mode driver using IRP_MN_READ_CONFIG or the HAL HalGetBusDataByOffset call. Our scanner uses the latter to read the full 4096-byte extended space.

We acquired or received access to seven DMA boards sold commercially as of Q1 2026. For each, we enumerate the distinguishing configuration-space properties:

The most reliable discriminator across the full seven-board corpus is the BAR layout. Every FPGA PCIe IP core we observed requests at least one 256 MB MMIO BAR for the DMA engine. Consumer peripherals — NICs, USB controllers, audio adapters — use BAR windows of kilobytes to low megabytes. A device advertising itself as a Realtek GbE NIC while requesting a 256 MB prefetchable MMIO region is structurally impossible; the Realtek RTL8168 silicon does not have a DMA engine of that scale.

The production detection in the Clubhouse AC scanner runs from a privileged kernel mini-driver that performs a full configuration-space read for every enumerated PCIe device. The pseudocode below reflects the published (non-operational) form of the composite rule:

rule DMA_FPGA_Fingerprint
{
  meta:
    severity    = "high"
    category    = "hardware"
    confidence  = 0.96

  inputs:
    for each device in pcie_device_tree():
      cfg := read_config_space(device, 0x000, 4096)

      vid    := cfg[0x00:0x02]   // Vendor ID
      did    := cfg[0x02:0x04]   // Device ID
      class  := cfg[0x0A:0x0C]   // Class / Subclass
      bars   := parse_bars(cfg)
      caps   := parse_capability_list(cfg)
      ext    := parse_extended_caps(cfg, 0x100)

  match:
    // Signal A: BAR size mismatch against known device profile
    any bar in bars where
      bar.is_mmio and
      bar.size_mb > 64 and
      (vid, did) in LOW_BAR_DEVICE_SET
      // donor device should not need >64 MB MMIO

    // Signal B: Device Serial Number capability present on
    // a device class that never ships DSN hardware
    or (DSN_CAP_ID in ext.cap_ids and
        class in CONSUMER_NIC_OR_USB_CLASSES)

    // Signal C: PCIe Link Speed / Width inconsistency
    or (express_cap := caps[PCI_CAP_EXPRESS];
        express_cap.current_link_speed > donor_max_speed(vid, did))

    // Signal D: Reserved config-space bytes non-zero
    // (FPGA firmware artefact — real silicon leaves these 0xFF or 0x00)
    or any b in cfg[0xE0:0x100] where b != 0x00 and b != 0xFF

  emit:
    artifact {
      device_path      = device.path
      vid_did          = (vid, did)
      spoofed_as       = lookup_donor(vid, did)
      signals_fired    = matched_signals
      bar_layout       = bars
      dsn_present      = (DSN_CAP_ID in ext.cap_ids)
      link_speed_gts   = express_cap.current_link_speed
    }
}

Signal A (BAR size) has the lowest false-positive rate because it is a structural property of the silicon. Signal D (reserved bytes) is the most fragile — firmware updates can zero-fill the shadow, and we have seen one board revision that did exactly this. The production rule requires at least two independent signals before emitting a detection at High confidence; a single signal emits at Medium.

All eight false positives came from virtualised environments where a PCIe device was passed through to a guest VM via IOMMU. The hypervisor's PCIe virtualisation layer introduces BAR size rounding and occasional DSN capability insertion that mimics our Signal A and Signal B patterns. The production rule suppresses these via a VM-presence heuristic (Hyper-V CPUID leaf, VMware I/O port, QEMU ACPI table strings) and has not produced a false positive on bare-metal hardware in 214 clean-baseline scans.

• A sufficiently sophisticated firmware author could synthesise a clean PCIe IP core with a BAR layout that exactly matches the donor device. This requires RTL engineering skill and a targeted FPGA re-spin — it is not achievable through config-space shadow manipulation alone. We have not observed this in the commercial market as of this writing.
• IOMMU passthrough VMs remain a source of false positives without the VM-presence suppression layer. Server-grade FiveM rented boxes often run under KVM with PCI passthrough for GPU; administrators running our scanner in those environments should expect Medium-confidence alerts that manual triage will clear.
• Detection requires kernel-level PCIe config-space access — a privilege level that implies the scanner is already running on the target machine. This methodology does not help with remote-attestation scenarios (detecting DMA hardware from the game server).
• We have tested against seven boards. The space of privately-commissioned FPGA firmware is larger than our sample. New board families will require new signature additions; the composite rule provides coverage through structural properties that are hard to spoof even without a named signature.