PCILeech: DMA memory access over PCIe, and how to install it

What PCILeech does that a normal memory acquisition tool cannot

PCILeech uses PCIe hardware devices to read and write target system memory, and it does this with DMA over PCIe. The README is explicit that no drivers are needed on the target system. That single property is the whole point. A conventional forensic tool has to run code on the machine it examines, which means the target's own operating system, security software and scheduling all sit between the analyst and the memory. PCILeech removes that layer: a device on the PCIe bus issues DMA transactions, and the target CPU is not asked for permission.

The audience is narrow and technical. The README frames the output around kernel implants, mounting live RAM as a file, mounting the file system as a drive, executing kernel code, spawning a system shell, pulling and pushing files, and removing the logon password requirement. That is a red team and kernel-research toolset, not a general endpoint agent. Supported targets are the x64 versions of UEFI, Linux, FreeBSD and Windows. The host side runs on Windows and Linux. If you work on 32-bit or ARM targets, the documentation does not cover you.

It also works without hardware. The README states that PCILeech supports a wide range of software memory acquisition methods through the LeechCore library, including remote live memory capture using DumpIt or WinPmem, local capture, and a number of memory dump file formats. So the same front end can drive a physical DMA card or a dump file you already have on disk.

How the DMA path and the LeechCore abstraction fit together

There are three layers in the documented design. At the bottom is the acquisition device: an FPGA card, a USB3380 board, or a software method. In the middle is LeechCore, which the README describes as handling all memory acquisition. On top is PCILeech itself, which turns raw memory access into the operations listed under Capabilities.

That split matters when you are debugging. A failure to reach the target is not necessarily a PCILeech bug; the acquisition layer is where the device is enumerated and where the memory window is defined. The README's most consequential hardware distinction lives here. USB3380 based hardware is only able to read 4GB of memory natively, but can read all memory if a kernel module (KMD) is first inserted into the target system kernel. FPGA based hardware, and software based methods, are able to read all memory without that step. Write access, which the kernel implants need, requires USB3380 hardware, FPGA hardware, LiveCloudKd or CVE-2018-1038 ("Total Meltdown").

The FPGA devices differ mainly in transport and ceiling. The README's table lists ZDMA over Thunderbolt3 at 1000MB/s, GBOX over OCuLink at 400MB/s, several CaptainDMA and LeetDMA boards over USB-C in the 190 to 220MB/s range, and AC701/FT601 over USB3 at 190MB/s. All of them are listed as supporting 64-bit memory access and raw PCIe TLP access. The USB3380-EVB is listed at 150MB/s with 64-bit memory access and TLP access both marked No. That is the trade-off in one line: the cheap path is the limited one.

Installing PCILeech and running a first memory dump

The README gives two routes: clone the sources in the repository, or download the latest binaries, modules and configuration files from the releases page. The repository is a Visual Studio solution (pcileech.sln) with the main sources under pcileech/, so building from source on Windows means opening that solution. If you only want to run it, take the release archive.

The README does not print a worked command line, so the first real step is to confirm that the acquisition layer sees a device. Memory acquisition is handled by the LeechCore library, and device selection is where a USB3380 board, an FPGA card or a software method gets picked up. If nothing is listed, the problem sits below PCILeech, in LeechCore or in the host's PCIe or USB stack.

Once a device is visible, a memory dump is the simplest real operation. The README describes dumping physical memory over the network through a remote LeechAgent, and the local equivalent writes the target's memory to a file you can analyze offline. Expect this to take a while on a large-memory machine. The README quotes retrieval at greater than 150MB/s as a capability, but the per-device table is the honest number, and FPGA methods are documented as maxing out at roughly 90MB/s on Linux against 150MB/s on Windows. Do not size a time window from the headline figure.

If you want to see what the implants can do rather than just read memory, the README lists mounting live RAM as a file, mounting the file system as a drive, and spawning a system shell on Windows targets. Those require write access, which brings back the hardware constraint from the previous section. A USB3380 board with no KMD loaded will not get you there.

The 4GB wall, the macOS cutoff, and the cases where PCILeech is the wrong tool

The clearest limitation is the USB3380 memory ceiling. Reading only the first 4GB natively is not a rounding error on a modern server; it is most of the interesting memory on a machine with 64GB or 128GB installed. The documented workaround is to insert a kernel module into the target first, which defeats the no-driver-on-the-target property that makes the tool attractive in the first place. If your reason for using PCILeech is that you cannot touch the target's kernel, budget for FPGA hardware.

The second limitation is platform support. macOS High Sierra and above are not supported, and the README marks that with an asterisk in every capability line that mentions macOS Sierra. Targets are x64 only. If your fleet is Apple silicon or 32-bit, the documentation offers nothing.

The third is environmental. DMA over PCIe assumes you can present a device to the target's bus. On a laptop with soldered, non-Thunderbolt expansion, on a locked-down hypervisor, or on a machine where IOMMU enforcement is in place, the path may simply not exist. The README does not document IOMMU behaviour, so this is something to establish on your own hardware before you commit.

Finally, PCILeech is the wrong tool when the question is not about memory at all. It will not give you disk artefacts, registry history or event logs. It reads and writes memory. If your case is a timeline reconstruction from a powered-off laptop, a software acquisition method through LeechCore or a plain imaging tool is the better fit.

PCILeech against software memory acquisition

The most useful comparison is not against another DMA tool but against the software methods PCILeech itself supports. The README notes that PCILeech works without hardware using software memory acquisition methods in LeechCore, including remote live memory capture with DumpIt or WinPmem, local capture, and memory dump file formats.

The difference in approach is where the code runs. DumpIt and WinPmem execute on the target and ask the target's operating system for memory. They are cheap, they need no PCIe hardware, and they work on machines you cannot physically reach. They also run inside the environment you are investigating, which means a kernel-level adversary can interfere with them, and they depend on the target being healthy enough to run a program.

PCILeech with a DMA card inverts all of that. It needs physical proximity and hardware, and it needs the target's bus to accept a device, but it does not need the target's cooperation. Choose based on which of those constraints you can actually satisfy. A remote user's workstation with no physical access is a DumpIt or WinPmem job. A seized machine on a bench where you need memory the operating system will not hand over is where the DMA path earns its cost.

One more distinction inside the hardware options: raw PCIe TLP access is listed only for FPGA devices. If your work depends on issuing TLPs directly rather than on the memory read and write API, USB3380 hardware is not a candidate at all.

Licence, maintenance and what an upgrade actually costs

PCILeech is licensed under AGPL-3.0. That is a strong copyleft licence with a network clause, and it is worth reading before you build it into anything you distribute or expose as a service. This is not legal advice; if you plan to ship a product around it, get your own review. The practical point is that AGPL-3.0 is a different proposition from a permissive licence, and the repository carries the LICENSE file at the top level for you to read.

The repository is not archived, and the last push was on 2026-07-25. Releases are not frequent: v4.17 in September 2023, v4.18 in June 2024, v4.19 in January 2025. That cadence tells you to pin a version rather than track the default branch. Upgrading is not a single binary swap either, because the project spans a Windows solution, a shellcode directory, FPGA bitstreams hosted in a separate repository, and the LeechCore library that handles acquisition. A version bump on the PCILeech side can require a matching device firmware and a matching LeechCore.

The FPGA hardware is the real upgrade cost. The README's device table links each board to a project sponsor entry, and the boards themselves are third-party hardware. A PCILeech upgrade that changes the device protocol is not something you fix with a package manager. Budget for the fact that the durable part of your setup is the card, and the software around it moves underneath.

Editorial conclusion

Adopt PCILeech if you do memory forensics, kernel research or red team work on x64 Windows, Linux, FreeBSD or UEFI systems and you accept the hardware cost and the AGPL-3.0 terms. Do not adopt it for routine incident response on machines you cannot take offline, for macOS High Sierra or later targets (the README states they are not supported), or for ARM and 32-bit systems that are outside the documented target list. Before relying on it, verify three things on your own bench: that your chosen acquisition path actually reaches all memory (USB3380 hardware is limited to 4GB natively), that your host OS gives you the throughput you need (FPGA methods are documented as maxing out near 90MB/s on Linux against 150MB/s on Windows), and that your target kernel build is covered by the implants you intend to use.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. ufrisk/pcileech on GitHub