PE-sieve: scanning a single process for injected PEs, hooks and shellcode

The gap PE-sieve fills: a process that lies about its own file

A file on disk and the code running in memory are two different things. Malware that injects a PE into another process, hollows out a legitimate one, or writes a shellcode buffer and jumps to it leaves the on-disk executable looking clean. Static analysis of the file tells you nothing about what is executing. PE-sieve is aimed at that gap. Its README describes it as a tool that helps to detect malware running on the system and collect the potentially malicious material for further analysis, recognising and dumping replaced or injected PEs, shellcodes, hooks and other in-memory patches. The named detections are concrete: inline hooks, Process Hollowing, Process Doppelgänging, Reflective DLL Injection. The audience is the analyst who already has a suspect PID, usually from a sandbox report or an EDR alert, and needs the memory-resident payload as a file. It is not a scanner you point at a disk. It is a scanner you point at a running thing.

How the scanner works: one process, memory regions, dumped implants

PE-sieve is deliberately scoped to a single process per run. The README calls it a light-weight engine dedicated to scan a single process at the time. That constraint shapes the architecture: the tool attaches to one target, walks its memory, and compares what it finds against what a normal image of that process should look like. Anything that does not fit gets reported and, where possible, written out as a dump. The repository layout reflects this pipeline. The scanners/ directory holds the detection logic, postprocessors/ handles what happens to findings after they are collected, stats/ accumulates the report data, and pe_sieve_report.h defines the report structure. The PE parsing itself is not in this repository: it comes from libPEConv, pulled in as a git submodule, which is why the README insists on a recursive clone. The output is a report plus dumped artefacts, and the README frames the goal as collecting material for further analysis rather than issuing a verdict. That distinction matters. PE-sieve is a collector, not a classifier.

Installing PE-sieve and running the first scan

The README points at the releases page for builds, and notes that the tool is also available via Chocolatey and Scoop. Building from source needs the submodule, so the clone must be recursive. The README gives this exact command:

git clone --recursive https://github.com/hasherezade/pe-sieve.git

The repository also carries CMakeLists.txt, mingw_build.sh and an AppVeyor configuration, so both CMake and MinGW paths exist in the tree. If you take the packaged route instead, the release archive is the faster path and avoids the submodule entirely.

Once you have the binary, the first real use is scanning a PID you already suspect. The README does not spell out the full flag list in the excerpt available here, so treat the tool's own help output as the authority on parameters rather than anything copied from a blog post. The workflow the project describes is: identify the process, scan it, then take the dumped implants and open them in a disassembler. That last step is the point of the exercise. A dump without follow-up analysis is just a file.

For embedding, the DLL build is the other entry point. The README states that the DLL version exposes a simple API and can be easily integrated with other applications, and points at the API page in the wiki. The repository files back this up: dll_main.cpp, pe_sieve_api.cpp and pe_sieve.h are all present at the top level, alongside main.cpp for the EXE build. If you are writing a scanner, the API is the interface to read, not the command line.

Where PE-sieve is the wrong tool

The single-process scope is a real limit, not a footnote. If you need to sweep every running process on a host, PE-sieve will not do it in one invocation. The README says so directly and points elsewhere: HollowsHunter is the project's own answer for scanning multiple processes at once, or the full system. Reaching for PE-sieve when you want host-wide coverage means writing your own loop and managing the output yourself.

The second limit is what a dump is worth. PE-sieve recognises and dumps implants, but the README does not describe any scoring, confidence level or automatic clean-or-malicious decision. An analyst still has to look at the output. Tools that promise a verdict are doing something different, and usually less transparently.

The third limit is platform. The repository badges Windows only, the build files are AppVeyor and MinGW, and the artefacts are EXE and DLL. There is no Linux or macOS story here. If your investigation is not on Windows, this is not the tool.

Finally, packaging details are thinner than the detection documentation. The README does not document rollback, uninstall steps or what the Chocolatey and Scoop packages place on disk. Verify that yourself before deploying into an environment where you cannot easily remove it.

HollowsHunter and the rest of the PE-sieve family

The most direct alternative is HollowsHunter, and it is not a competitor so much as a wrapper. The README describes it as the tool to use if, instead of scanning a single process, you want to scan multiple processes at once, or even the full system with PE-sieve. The difference in approach is scope orchestration: HollowsHunter drives PE-sieve across many targets and adds filters on top, while PE-sieve stays the single-process engine underneath. Choosing between them is really choosing whether you want to write the enumeration loop yourself.

MalUnpack is the other family member, aimed at quick unpacking of a supplied malware sample. That is a different starting point: you have a file, not a running process. If your sample is already executing and you want to know what it became, PE-sieve is the fit. If you have a packed binary and want the unpacked payload, MalUnpack is the stated use case.

Outside the family, the honest comparison is with debuggers and memory dumpers. A debugger gives you control and breakpoints but requires you to know where to look. PE-sieve gives you a report of what looks wrong without you having to set anything up. The trade is depth for reach: the debugger goes deeper on one thing, PE-sieve covers more ground per run.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-06-06. Releases are infrequent rather than continuous: v0.4.0.1 in February 2025, v0.4.1 in February 2025, and v0.4.1.1 in September 2025. That cadence suggests a tool that is stable rather than one adding features every month, which cuts both ways. You are unlikely to be chasing breaking changes, and you are also unlikely to get a quick fix for a detection gap.

Upgrade cost is low in the normal case. The EXE is a drop-in replacement, and the DLL API is versioned through the header files in the tree. The real maintenance burden is the submodule: because libPEConv is pulled in rather than vendored, a fresh clone or a rebuild after a long gap needs the recursive clone to have succeeded. A build that fails on missing PE parsing code is almost always a submodule problem, not a compiler problem.

The licence is BSD-2-Clause, which is permissive and places few obligations on how you redistribute or embed the tool. That said, this is a description of the licence identifier, not legal advice. If you are shipping the DLL inside a commercial product, read the LICENSE file in the repository and get your own counsel to confirm what attribution your distribution requires.

Editorial conclusion

Adopt PE-sieve if you already have a suspect process and want the implant material on disk for a disassembler, and prefer the DLL if you are building a scanner of your own. Do not adopt it as a system-wide monitor or a standalone verdict engine: it scans one process per run, and the README does not document any scoring or rollback behaviour. Before relying on it, verify the current release tag on the releases page and confirm that a recursive clone populated the libpeconv and paramkit submodules.

Frequently asked questions

Official sources

1. hasherezade/pe-sieve on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases