Install anything it can't verify
Every package pins a SHA-256. The download is refused unless the bytes match exactly, and refused again if an HTTPS source quietly redirects to plain HTTP. A digest you cannot check is not provenance.
Stop hunting for download links
A package manager for digital forensics tools.
Forensic tooling is scattered across project pages, release feeds, personal sites and word of mouth — and you have to already know a tool exists before you can go looking for it. dfpm gathers them into one catalog you can browse and install from, then keeps track of what you installed, where it went, and exactly which version is running.
Why it exists
Three things it refuses to do.
A toolchain manager earns trust by what it declines to touch, not by how much it automates.
Leave you guessing which version ran
One version of a package is installed at a time. Installing replaces what was there, and the old version is removed only once the new one is in place and working. No stack of folders to pick through mid-case.
Change your system behind your back
dfpm never edits your PATH, never writes outside the folders it shows you, and deletes only the directories it created. Removing a package removes its own folder and its command shortcuts — nothing else on your machine is touched.
And one thing it always does
Prints the plan first. Package, version, platform, license, source, digest, download size, destination, and what will be replaced — every time, before anything changes.
What dfpm is not.
It does not acquire or interpret evidence, manage cases, or run investigation workflows. It manages the tools you use to do those things, and nothing more.
The lifecycle
From published release
to a working command.
Every install follows the same five steps. If any of them fails, the step before it is left exactly as it was.
The package points at an official release
An entry names the artifact the project itself published and records its SHA-256, alongside the license and the platform it was built for. dfpm never repackages, rebuilds or mirrors anything — what you install is the file the maintainers released.
The artifact is fetched and checked
Downloaded over HTTPS into a content-addressed cache and re-hashed against the digest the entry recorded. Anything else is refused, as is a redirect that drops out of HTTPS.
The archive stays where it was put
Path traversal, absolute paths, drive letters, symlinks, encrypted entries and reserved device names are all rejected. Extraction is refused if the result would not fit the volume, and a reserve is kept back so a successful install never leaves you at zero bytes free.
The result is checked before it counts
Files land in a staging directory first. The expected entrypoints and health-check files must be present, and the size and file count must match what the entry recorded, or the whole install is discarded and nothing is installed.
Only then does it take over
The staged version moves into place atomically, command shortcuts are rewritten, and the version it replaces is removed. A failure at any earlier point leaves your working version untouched.
Afterwards
It keeps checking.
Health without side effects
dfpm doctor checks that each package is still where it was put, that its commands still exist, and that its shortcuts still belong to it. It does not police the rest of a package's folder — a tool updating its own rules is working, not breaking. It reads; it never repairs, moves or deletes.
Downloads outlive their source
Checked downloads are kept so a package can be reinstalled with no network at all — useful in an isolated lab, and useful years later when an upstream release has been pulled. dfpm cache shows what is there and what still needs it.
Available packages
Catalog
Each entry pins the exact artifact a project released, along with its digest. dfpm checks that digest on every install and refuses anything that does not match.
What an entry guarantees.
Every package names the release artifact its project published, records that artifact's SHA-256, and records the upstream project, its license and the platform it was built for. On install, dfpm fetches it over HTTPS, refuses the download outright if the source redirects away from HTTPS, and re-hashes the file before anything is extracted. The download size is recorded too, so the plan can tell you what you are about to fetch and what it will cost on disk.
On your computer
Get started
dfpm needs Python 3.11 or newer and runs on Windows and Linux, including WSL.
1. Install dfpm
pipx install git+https://github.com/forynsics/dfpm.git
pipx keeps dfpm in its own environment and puts the command on your PATH. pip install works too if you would rather manage that yourself.
2. See where it will put things
dfpm paths
Tools go under %LOCALAPPDATA%\dfpm on Windows and ~/.local/share/dfpm on Linux. Use dfpm config set root <dir> to choose another data root.
3. Install a package
dfpm catalog dfpm install capa
The plan is printed first and waits for confirmation. Add --yes once you have reviewed it. dfpm ships with a catalog, so there is nothing to set up first.
4. Run it
dfpm run capa --version dfpm which capa
dfpm does not modify your PATH. dfpm run removes any ambiguity about which binary executed; dfpm which shows you the exact file and warns if something else on your PATH would win.
Everything else
The full command set
Going deeper
Documentation
Day to day
Plans, versions and platforms; running tools and reaching them from your shell; exit codes and runtimes.
The catalog
Where entries come from, how syncing works, and how a package is described.
Security model
What dfpm guarantees about the software it installs — and, just as plainly, what it does not.