forensictools: a Windows installer that assembles a forensics lab and puts it on your PATH
Collection of forensic tools
At a glance
- What is it?
- forensictools is a collection of digital forensics tools packaged as a single Windows setup program, built with NSIS and a PowerShell build script, that installs the tools and wires them into the Windows PATH so they can be run straight from a command line. It suits a responder setting up a fresh analysis machine, and it is a Windows only installer rather than a portable toolkit.
- Who is it for?
- forensictools fits a responder who repeatedly builds a clean analysis machine and wants one installer to lay down the tool set and the PATH entries, and it does not fit a Linux or macOS analyst, or a forensic examiner who needs an air-gapped, version-locked toolset with recorded hashes, since the tools are fetched from their own download sites.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 65 days ago.
- What is it written in?
- Mainly NSIS, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The product is a virtual environment, not a tool
forensictools is a toolkit designed for digital forensics, offering a wide array of tools, and the README states its primary goal plainly: to simplify the creation of a virtual environment for conducting forensic examinations.
That goal statement reframes what the project is. It is not a forensics tool, and it is not a collection of new forensic utilities. It is an installer whose output is a working analysis environment. The audience is therefore the person who opens a fresh Windows machine for a case, or who maintains a disk image, and who would otherwise spend the first hour of an engagement downloading, unpacking and configuring the analysis tools before any actual analysis begins.
The second capability is described with equal emphasis. In addition to installing the tools, forensictools adds the programs to the Windows PATH, and the README explains the intent as effortless utilization of these tools directly from the command line, eliminating the need for manual setup or configuration.
That PATH integration is the part that distinguishes this from a folder of zipped downloads. Once the tools are on the PATH, they work from any directory, from any shell, and a script that calls them does not need absolute paths or a wrapper. For a workflow that chains several tools together, that is worth more than the installation itself.
The project is MIT licensed, the homepage is the project page on the author's site, and the repository is under the cristianzsh organisation. The primary language is recorded as NSIS, which is the Nullsoft Scriptable Install System, the installer framework Windows packages are written in, and that single fact tells you the deliverable is a setup program rather than a library.
The repository is a build recipe, the releases are the product
The Download and usage section is short and its first sentence sets the boundary. This repository hosts only the source code required to build the application package encompassing all available tools. To acquire the final setup program, navigate to the releases section.
So the split is deliberate and it is a common pattern for installer projects. The git repository is where the package definition lives, so the composition of the toolkit is reviewable, diffable and versioned, while the artefacts themselves are distributed as release binaries. A user downloads the setup program and never touches the source; a maintainer changes a list and rebuilds.
The top level of the repository is consistent with that. There is a build.ps1, a PowerShell build script, which is where the package definition and the build logic live, a src directory holding the source including the images the README embeds, a docs directory, a CHANGELOG.md and the LICENSE file. The PowerShell script rather than a Makefile or a Python entry point is itself a choice worth noticing, since it keeps the whole build chain inside what a Windows workstation already has.
The release history shows a project that ships on its own schedule rather than continuously. The versions are v1.4 on 2026-08-20, v1.3 on 2026-01-12 and v1.2 on 2025-05-01. That is roughly one release every seven to eight months, and the last push was on 2026-08-20, the same day as v1.4, so the tag reflects the current state of the build script rather than a long-lived branch.
The CHANGELOG.md at the top of the repository is therefore the place to look for what actually changed between those points, and its presence next to a build script rather than a code tree is a reminder that what changes between releases is the set of tools, not application logic.
Where the tool list lives, and why the README does not repeat it
The README does not enumerate the tools, and that is a deliberate choice with a practical reason behind it.
A list with all tools can be found on the project page linked from the README, and the same README carries a video demonstration for anyone who wants to see the environment before installing it. The list is on the website rather than in the repository because the list changes with every build. Putting a tool inventory in the README would mean it is stale the moment the next release ships, and a stale inventory in a forensics context is worse than no inventory, because a responder might assume a tool is present when it is not.
The repository topics are the other place the scope is described, and they are more revealing than a tool count would be. Alongside the obvious dfir, forensics, forensics-tools, incident-response and toolkit, they include forensic-examinations and binary-analysis, which suggests the collection is not limited to disk and memory forensics but extends to examining executables.
The Windows-only framing is consistent throughout. The PATH integration described in the README is the Windows PATH, the package is an NSIS setup program, the primary language is NSIS, and the top level contains a PowerShell build script with no Linux or macOS equivalent mentioned anywhere. The homepage is the author's own site rather than a documentation site, which tells you the project's documentation lives in blog-style pages rather than in a hosted manual.
For a responder on a non-Windows platform, the answer is therefore the linked tool list and the individual tools themselves, not this project. The value of forensictools is specifically that it turns a set of separate downloads into one install with a working command line.
Adding a tool means opening an issue, and every tool ships free
The contribution policy is short and has two clauses, and the second one is the more consequential.
The first: if you wish to propose a new tool for inclusion, please open an issue. The second: all tools included in this toolkit are freely available for download.
That second clause is a constraint on what can go in, and it is a sensible one. A forensics environment that quietly includes a tool the analyst has to license separately is a licensing surprise waiting to happen in a case file. Requiring every bundled tool to be freely available keeps the install a single download with no per-seat cost and no account to create, which matters when the tools end up in a legal process where the provenance of every artifact has to be explainable.
The trade-off is that the collection is then limited to what is available without payment or registration, and it is limited to what is distributable by someone who is not the author of the tool. A tool that is free to download but that a maintainer might not be comfortable redistributing is a different question from a tool that is freely available, and the issue tracker is where that negotiation happens.
The issue route also tells you something about the shape of the project. Nothing in the README describes an automated test, a manifest schema, or a contribution process beyond opening an issue, so a proposal becomes a conversation rather than a pull request. For a project whose only artefact is a package definition, that is a reasonable amount of process.
The CHANGELOG.md is the counterpart to that policy, since it is where the record of which tools entered or left a given release would live. A responder relying on this toolkit for a case would want that file open next to the installer.
What the installer does not do for you
There are limits that follow from the design, and a careful reader can see them in what the README does not promise.
The first is that this is a fetching environment, not a forensic one. The tools are installed from their own sources, and the README states the inclusion condition as freely available for download, which is a condition about availability rather than about provenance, integrity or version pinning. Nothing in the repository describes hash recording, signature verification, or a manifest that fixes a particular version of a particular tool. For day to day triage that is fine. For a case where a specific tool version has to be shown to have been the one used, the installer's output is a starting point rather than evidence, and a separate acquisition record is still needed.
The second is that there is no rollback or removal story described. The README says nothing about uninstalling, about updating an existing install, or about how the PATH entries are handled if a user removes one tool. A forensic workstation is often a long-lived machine, so the maintenance path matters as much as the install path, and the documentation is silent on it.
The third is that the whole approach is Windows specific, and it depends on the Windows PATH being the right integration point. On a locked down corporate image, on a machine where the PATH is managed by configuration management, or on a jump host with restricted environment variables, the automatic part is the part most likely to break.
None of these are reasons to dismiss the project. They are reasons to treat the installed environment as something you verify, and the CHANGELOG as something you read, rather than as a fixed and audited reference image.
Editorial conclusion
forensictools fits a responder who repeatedly builds a clean analysis machine and wants one installer to lay down the tool set and the PATH entries, and it does not fit a Linux or macOS analyst, or a forensic examiner who needs an air-gapped, version-locked toolset with recorded hashes, since the tools are fetched from their own download sites. Before relying on it, read the CHANGELOG.md in the repository to see what moved between releases, and check the tool list on the project page, because the repository ships only the build source and the composition of a given build is decided at package time rather than pinned in the code you can read.
Frequently asked questions
What does the forensictools toolkit do?
It installs a wide array of digital forensics tools and adds them to the Windows PATH so they can be run directly from a command line without manual setup. Its primary goal is to simplify the creation of a virtual environment for conducting forensic examinations.
How do I get the forensictools setup program?
The repository hosts only the source code required to build the application package, so the final setup program has to be taken from the releases section of the repository. The build itself is driven by the build.ps1 script in the repository root.
How do I propose a new tool for the forensictools collection?
The README asks you to open an issue. It also states that all tools included in the toolkit are freely available for download, which is the condition a proposed tool has to meet.
Where can I see the full list of tools in forensictools?
The README links to a list with all tools on the project page, and a video demonstration is also linked for seeing the environment before installing it. The list is kept on the page rather than in the README so that it does not go stale between releases.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/cristianzsh-forensictools)Was this useful?