Process Dump reconstructs unpacked malware from memory, then tells you which parts are noise

The problem it exists for: the file on disk is not the code running

Process Dump is described as a Windows reverse-engineering command-line tool to dump malware memory components back to disk for analysis, and the README states the problem plainly. Malware files are often packed and obfuscated before execution in order to avoid AV scanners. However, when those files run they will often unpack or inject a clean version of the malware code in memory.

So the static sample you received and the code actually executing differ. Any analysis of the on-disk file is analysis of a stub. The unpacked payload exists in memory and is usually clean of the packer's obfuscation, which is exactly what you want to hand to IDA or resubmit to scanners.

The tool's approach is to treat process memory as a source of reconstructable PE files rather than as raw regions. The listed main features make the scope clear: dump code from a specific process or all processes, find and dump hidden modules that are not properly loaded, find and dump loose code chunks even when they are not associated with a PE file, reconstruct imports using an aggressive approach, run in close dump monitor mode with `-closemon`, work multi-threaded so dumping all running processes goes quickly, and generate a clean hash database.

That last feature is the one that separates this from a simpler memory scraper, and it is worth understanding before anything else.

The clean hash database is what makes the output readable

Without filtering, dumping every process produces the entire Windows codebase: every DLL, every runtime, every driver image. You would have several thousand PE files, and the two you care about would be indistinguishable from the noise.

Process Dump solves this with hashes of known-clean files. The README puts it directly: it supports creation and use of a clean-hash database, so that dumping of known files such as kernel32.dll can be skipped.

There are three database files, defaulting to the application directory: `clean.hashes`, `entrypoints.hashes` and `shortentrypoints.hashes`. The distinction between the latter two is what the option table reveals. `-db add <dir>` adds PE file hashes recursively *including* entrypoint signatures, while `-db remove` and `-db rem` remove matching clean-module hashes but retain entrypoint signatures. So the entrypoint databases are used for a different judgement: not "is this file clean" but "does this code start where a clean module would start".

The database commands are:

* `-db gen` adds hashes from running processes and PE files found recursively in `%WINDIR%`, `%USERPROFILE%`, `C:\Program Files` and `C:\Program Files (x86)` * `-db genquick` adds hashes from running processes only, described as faster but less complete * `-db add <dir>` adds PE file hashes from a directory recursively * `-db clean` clears all three databases, including entrypoint signatures * `-db ignore` ignores all three loaded databases for this dump without changing the files

Two details matter in practice. `-db ignore` is non-destructive, so you can do a full dump of everything on a hunch without losing your baseline. And the README says repeated modules may still be skipped within a run even under `-db ignore`.

The paths are overridable with `-cdb` or `-c` for the clean hash database, `-edb` for the entrypoint database, and `-esdb` for the short entrypoint database.

Command line: three dumping modes and how they differ

There are three ways to select what to dump, and they behave differently in ways worth knowing before you start.

`-system` dumps modules and loose code not matching the clean hash database from all accessible processes. `-pid <pid>` dumps one process, accepting decimal or a `0x` prefix for hexadecimal. `-p <regex>` dumps processes whose *entire* name matches a case-sensitive regular expression, and multiple matches prompt for confirmation.

The README's own example list shows why the regex is anchored:

pd64.exe -p "chrome[.]exe"
pd64.exe -p ".*chrome.*"

The first pattern matches exactly, the second matches anything containing the word. The `[.]` bracket form rather than a literal dot is the conventional way to keep a dot from matching itself.

`-closemon` is the third mode and the most interesting one. It hooks process termination and dumps the process just before exit, with the README noting you should use it in a controlled environment and press Ctrl+C to stop. This exists because a packer often unpacks, runs briefly, and then wipes or unloads its payload on exit. A normal dump misses it entirely; hooking termination catches the window where the code still exists.

Two more options shape individual dumps. `-a <address>` dumps at a specific base address and requires `-pid`, accepting decimal or `0x`-prefixed hex. `-o <path>` sets the output folder, defaulting to the current working directory. The README states you must create the folder first and that existing files are never overwritten.

Diagnostics are `-v` for verbose output and `-nh` to suppress the version and copyright banner. Help is available as `--help`, `-help`, `-h` or `--h`, and running with no arguments also prints help.

Threading is where the tool's own engineering shows. `-t <count>` sets workers, default 16 and minimum 1, for system dumping, database generation and close monitoring, and the last `-t` or `-nt` wins. `-nt` is shorthand for one worker, and close monitoring still has its own separate monitoring thread. Direct PID and name dumps remain synchronous regardless of the worker count, which the README states explicitly.

Advanced switches: turning off what produces the most files

The advanced options exist because each of them makes the output larger or less certain, and on a real system you often want less of both.

`-nc` disables loose-code dumping and hashing, which is enabled by default. This is the single biggest lever on volume. By default Process Dump finds executable regions that are not associated with any PE file and, because it builds a PE header and import table for those chunks, writes them out. That is the feature most likely to matter for injected shellcode, and also the one generating the most files on a clean machine.

`-ni` disables aggressive import reconstruction, also on by default. The aggressive approach exists because injected code frequently has no import table or a mangled one, so imports have to be inferred from referenced addresses. The price is that a reconstruction is a guess.

Entry point recovery gets three separate switches, which is unusual and tells you the feature is contested. `-eprec` forces entrypoint recovery even when a valid entrypoint already exists, with the README warning that recovery is heuristic and an unsuccessful search leaves the old value unchanged. `-nep` disables entrypoint recovery and live entrypoint hashing entirely, overriding `-eprec`, though file database generation still collects entrypoint signatures.

`-g` forces generation of both 32-bit and 64-bit PE headers, ignoring existing headers. That matters when you dump at an address with no valid header and need a loadable file rather than a fragment.

`-reexec` is the one to read carefully. It is described as experimental preparation for re-running dumps, discarding some captured state and assuming the original section layout. It does not run the dump and does not guarantee it will work, and it is off by default.

`-nr` disables recursion for database add and remove commands, and the README notes it does not affect `-db gen`.

The pattern across all of these is that the defaults favour completeness and the switches exist for when completeness produces too much to work with.

Installation, releases, and the binary you actually run

Process Dump ships as two standalone binaries. The README directs you to the GitHub releases page, then says to use `pd64.exe` on 64-bit Windows, which it recommends, or `pd32.exe` on 32-bit Windows. Both are standalone and no Microsoft Visual C++ Redistributable is required, which removes the usual first-run failure on a locked-down analysis machine.

The author also maintains an official compiled release on split-code.com, linked from the repository, which is worth knowing about as a distinct source from the GitHub release artifacts.

Version history has a long gap. v3.0.0 was tagged on 2026-10-03, immediately after v2.1.1 from 2022-01-25. The last push was on 2026-10-03 as well. So the project went more than four years between a 2.1.1 and a 3.0.0, and the current release is also the most recent commit activity.

That does not make it unmaintained, and the version jump to 3.0.0 alongside expanded documentation suggests the gap was spent on substantial rework rather than dormancy. But anyone carrying assumptions from v2.x should re-read the option tables, because the 4-year span makes silent behaviour changes plausible in a way they would not be for a tool with annual releases.

The repository is small and conventional for a Visual Studio project: `pd.sln`, a `pd/` directory holding the code, and `tests/`. Licence is MIT. Primary language is C++.

One practical detail for a lab: the README says to run database generation and dumping as separate commands, and for best access to run as Administrator. Both matter, because a database generated without elevation will be missing the hashes for system components you later need to skip.

Where this is the wrong tool, and how to use it safely

Three situations argue against it.

If you have a static sample and no execution, Process Dump does nothing for you. It requires the code to be running in a process you can read.

If you need to inspect a live production host, this is the wrong instrument. The README says for malware analysis, use an isolated lab and run Process Dump as Administrator. Administrator access plus a memory scanner across every process is a large blast radius, and `-closemon` hooks process termination, which can change the behaviour of the very code you are trying to observe.

If you want a general process inspector or a memory editor, this is too blunt. It is built around PE reconstruction and hashing, not around arbitrary memory read and write.

The safe workflow follows from the flags rather than from guesswork. Build the baseline on a known-clean machine, since a database generated on a contaminated machine teaches the tool to skip the payload. Copy the sample into an isolated network, let it execute, and dump it while running. Use `-pid` rather than `-system` when you know which process to look at, because `-system` walks everything and multiplies your exposure. Point `-o` at a directory on the analysis host so dumps do not land next to the sample.

One thing the README leaves open is what the reconstructed loose-code files look like in practice. The PE headers and import tables for chunks are generated rather than recovered, so a loose chunk written to disk is a best-effort reconstruction, and any analysis tool you feed it should be told that.

Editorial conclusion

Adopt Process Dump if you analyse packed malware on Windows and need PE files reconstructed from memory rather than the packed sample on disk. Do not run it on a production host, since the README directs you to an isolated lab and running as Administrator, and `-closemon` explicitly hooks process termination. Before a first real dump, generate a baseline on a clean machine with `pd64.exe -db gen` and keep it, because every dump you run later compares against it; without that database the output is dominated by the clean modules already on the machine rather than by the injected code you are looking for.

Frequently asked questions

Official sources

1. glmcdona/Process-Dump on GitHub
2. License: MIT
3. Project website
4. README
5. Releases