LeechCore: one API over local and remote physical memory acquisition

A library with no executable of its own

LeechCore is described as a physical memory acquisition library, and its scope is narrow: it focuses on physical memory acquisition using various hardware and software based methods. It provides API-based access to those sources through C and C++ APIs, Python and C# APIs.

What makes the design unusual is stated plainly in the project documentation: no executable exists for LeechCore, the library is always loaded by other applications using it, such as PCILeech and MemProcFS. If you are looking for a program you can run to dump memory, this is not it. It is the layer underneath such programs.

That positioning tells you who it is for. The consumers named in the documentation are PCILeech, which drives DMA based acquisition, and the Memory Process File System, MemProcFS, which exposes memory contents as a file system. Beyond those two, the audience is developers of forensics tooling, malware analysis environments and incident response utilities who want to abstract away the difference between a crash dump on disk and a live hypervisor guest.

Platform support follows the same practical bent. The library is supported on 32-bit and 64-bit Windows as a .dll, on x64 and arm64 Linux as a .so, and on macOS.

The LeechAgent is the remote half, secured with kerberos

You can use the library locally or connect over the network to a LeechAgent to acquire physical memory or run commands remotely. The LeechAgent itself is a separate component: the documentation is careful to say that it only provides a network connection to a remote LeechCore library, and that once connected it is possible to use both hardware and software based acquisition methods.

The transport properties matter for the use case the project describes. The connection is by default compressed and secured with mutually authenticated kerberos, which the documentation presents as making it suitable for incident response, in combination with analysis and live memory capture using Comae DumpIt or WinPMEM, even over high latency low-bandwidth connections. Kerberos mutual authentication is the part that changes the risk profile: the client proves who it is and the server proves who it is, rather than relying on network position alone.

The repository layout reflects the split. There are separate leechagent and leechagent_linux directories alongside the leechcore library itself, plus leechcorepyc for the Python binding, includes for headers, files for packaged artefacts and tests. A LeechCore.sln sits at the root, so the Windows build is a Visual Studio solution while the other platforms are built from the same sources.

Because the agent offers command execution as well as memory reads, the security boundary is the deployment, not the library. An agent exposed to an untrusted network is a remote code execution surface by design, and mutual authentication is what limits who can reach it.

The software device table, from raw dumps to hypervisors

The device table in the project documentation is the fastest way to understand what LeechCore abstracts. The software based methods include three file based sources that are not volatile and offer no write access: a raw physical memory dump, a full Microsoft crash dump and a full ELF core dump, all of which work on Linux as well.

Live sources are richer. QEMU and VMware both expose live memory with write support, as does TotalMeltdown, which the table ties to CVE-2018-1038, and libmicrovmi, which is listed with Linux support and as a plugin. A VMware memory save file is treated as a file rather than a live device. DumpIt and LIVEKD, WinPMEM and LiveKd provide live memory without write access, while LiveCloudKd provides live memory with write support and is listed as a plugin.

Two columns deserve attention. The Linux Support column is mostly No for the live devices, with libmicrovmi the notable exception, which reflects that most live acquisition paths are Windows specific. The Plugin column marks the methods that are not built into the library: LiveCloudKd, libmicrovmi, Hyper-V Saved State, and anything in the hardware table that depends on a plugin. That is the practical constraint for an integrator. The device you need may not be compiled in, and the plugin has to exist and match.

Note also what the table does not claim. It records types, volatility, write support, Linux support and plugin status, and it does not give throughput figures for the software devices, so those methods should be treated as situational rather than fast.

DMA hardware is where the bandwidth numbers come from

The hardware table covers FPGA and BMC based acquisition devices, and it is the only place in the project documentation where speeds are stated. All hardware based methods are supported on both Windows and Linux.

The fastest listed is ZDMA over Thunderbolt3 at 1000MB/s, followed by GBOX over OCuLink at 400MB/s. The USB-C devices cluster in the 190MB/s to 220MB/s range: LeetDMA at 190MB/s, CaptainDMA M2 at 190MB/s, CaptainDMA M2 100T at 220MB/s, CaptainDMA 4.1th at 190MB/s, CaptainDMA 75T at 200MB/s and CaptainDMA 100T at 220MB/s. AC701/FT601 over USB3 is listed at 190MB/s, USB3380-EVB over USB3 at 150MB/s, and a DMA patched HP iLO over a BMC interface at 1MB/s.

Two columns mark which devices can do 64-bit memory access and which support PCIe TLP access. Every FPGA entry in the table has both marked Yes, while USB3380-EVB and the patched HP iLO are marked No for both. For an integrator those two capabilities are the real filter, since 64-bit access is what lets a modern kernel's structures be read in one pass rather than pieced together from 32-bit reads.

The DMA patched HP iLO deserves a note on its own. An iLO is a baseboard management controller, and the table places it on the BMC interface over TCP at 1MB/s, three orders of magnitude below the FPGA devices. It is the option for hardware where no PCIe slot is reachable, not a throughput play.

Getting the library and choosing a binding

There is no install command documented in the project overview, so the documented path is a download. The library is distributed as a GitHub release, and the documentation points at the latest release page:

https://github.com/ufrisk/LeechCore/releases/latest

For Python users there is a separate route. The documentation recommends the leechcorepyc python pip package, which is available for 64-bit Linux and Windows:

pip install leechcorepyc

That is the one binding that arrives as a package manager install, and it is limited to 64-bit Linux and Windows, so a Python workflow on macOS or on 32-bit Windows falls back to building from source.

The C and C++ APIs are the core, and the repository carries an includes directory for the headers, so linking is a matter of adding the .dll or .so to a project that already expects to load a library rather than run a program. The C# API is provided for .NET tooling. Detailed documentation for the individual methods and the API, including examples, lives in the LeechCore wiki rather than in the repository overview, which is where to look before committing to a specific device.

Limits worth knowing before you build on it

Several boundaries are visible in the documentation rather than hidden. First, the library is not a tool. If the requirement is a memory dumper you can run on a machine and hand a file to an analyst, LeechCore is the wrong artefact, because the executable that does the dumping, such as WinPMEM or DumpIt, is a separate program that LeechCore can also drive.

Second, device coverage is uneven. Several live methods are Windows only, most have no write access, and the ones that need a plugin are only as good as the plugin's release cadence, which is tracked in a separate repository. Building a product on top of a plugin device means tracking two release streams.

Third, and most importantly, live physical memory is the most sensitive data a machine holds. Process memory routinely contains credentials, tokens and keys in plaintext, and the LeechAgent offers remote command execution in addition to memory reads. The kerberos mutual authentication described in the documentation is the mitigation, and it has to be deployed properly, with a compromised LeechAgent host being a full compromise of every machine it can reach. There is also a legal dimension: reading another machine's memory is regulated in many jurisdictions, and the kerberos requirement exists partly to make that authorisation explicit.

Fourth, the licence. GPL-3.0 is the licence recorded for the repository, and linking a GPL library into a proprietary product has consequences for how that product is distributed. That is a question for a lawyer, not a paragraph in a review, but it belongs in the list of things to check before adoption rather than after.

Version 2.23, an active tree and a GPL-3.0 codebase

The release history is short and readable: v2.21 on 2025-02-12, v2.22 on 2025-04-05 and v2.23 on 2026-07-30. The repository is not archived and the last push was on 2026-09-27, so the code is being worked on after the newest tag.

That gap between the newest tag and the last commit is the normal consequence of a project that maintains its own release cadence, and for an integrator the practical question is which one you build against. Pinning v2.23 gives a dated artifact with a known device list. Tracking master gives you whatever the plugin work and the device support have become since July.

The upgrade cost of this library is unusual compared with most C libraries, and it is worth stating plainly. LeechCore sits underneath other applications, so its upgrade is not a routine dependency bump for the teams using it. PCILeech and MemProcFS have to be rebuilt against a new LeechCore, their device lists change when LeechCore adds or changes a device, and a plugin based device has to be matched on both sides. The cost lands on integration, not on the linker.

The licence is GPL-3.0, with the LICENSE file at the repository root. The code base is C, with the Python binding and the .NET API layered on top of the same core.

Editorial conclusion

Adopt LeechCore when you are building a forensics or incident response tool that needs one memory acquisition interface across local devices, remote agents and DMA hardware, and you are comfortable linking a GPL-3.0 library. Skip it if you need a standalone memory dumper with no integration work, or if you cannot justify shipping the LeechAgent on a remote host. Verify first that the device you care about is either built in or has a matching plugin, since LiveCloudKd, libmicrovmi and Hyper-V Saved State are listed as plugin backed, and check the release you pin, v2.23 from 2026-07-30, against the device list you depend on.

Frequently asked questions

Official sources

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