The Sleuth Kit: a layered toolkit for reading disk images from the bottom up

Tool names tell you which layer of storage they read

The design decision that makes The Sleuth Kit easy to learn is in its naming. Every command starts with a letter assigned to the layer of a disk it operates on, and the README walks through those layers in order: partitions and slices at the bottom, then the file system, then blocks of raw content, then inode metadata, then the human friendly file view on top. A tool whose name begins with `blk` reads data units. One that begins with `i` reads metadata structures. One that begins with `f` works with file names.

The payoff is that you can guess at a capability. If you want to know what a partition table contains, you reach for the file system layer first. If you want the bytes behind a deleted file, you are in the content layer. `fsstat` sits at the file system layer and prints volume details in ASCII, including the volume name, the last mounting time and, for UNIX file systems, the layout of each group.

The repository is written in C, and the tree shows the shape of the build: `tsk/` for the core, `tools/` for the command line programs, `bindings/` for language bindings, `man/` for manual pages, `tests/`, `unit_tests/` and `samples/` for the example programs the bindings are tested against. `case-uco/` and `db_diff/` indicate work on the UCO case format and on comparing case databases, so the toolkit is not frozen at a set of standalone scripts.

Listing and extracting files through the metadata layer

`fls` is the tool most people meet first. It lists file and directory names from an image, and unlike an ordinary directory listing it shows deleted entries, because deleted names still exist in the file system's metadata until that metadata is reused. That is the whole reason the toolkit exists as a separate project rather than as a wrapper around a mounted filesystem.

The README names two invocations you need for a real timeline, and they are the commands to reach for when you want allocated names plus metadata:

fls -rm dir
ils -m

The `-r` flag recurses, and the `m` flag adds the timing data. The README presents both without the image argument spelled out, since every one of these tools takes the image path as its argument. `istat` then explains one metadata structure in detail, including, since version 4, the destination of symbolic links, and `icat` writes out the data units allocated to that structure, which is the closest thing here to a `cat` for a forensic image. `ifind` works in the opposite direction, identifying which metadata structure claims a given file name or content unit.

The human interface layer adds `ffind`, which identifies the name of the file that has allocated a given metadata structure. On file systems where deleted files keep their directory entries, that is how you get from a surviving name to the content that belongs to it.

Carving unallocated space with blkls and blkcalc

The content layer is where deleted data recovery happens. `blkcat` prints the contents of one specific data unit, which sounds redundant next to `dd` but is not, because the unit size is whatever the file system in the image dictates rather than a block size you guess at.

`blkls` is the more interesting command. It writes out every unallocated unit of the file system as a single byte stream, which concatenates all the space that used to hold deleted file content into something a search tool can chew through. The README is explicit that the output is meant to be searched for deleted file content.

`blkls` also accepts `-l`, a feature carried over from The Coroner's Toolkit, which lists the details of each data unit the same way `ils` does. The listing mode and the carving mode pull in opposite directions: one tells you where a unit lives, the other produces the bytes. `blkcalc` closes the loop by translating an offset in the `blkls` generated image back to its location in the original image, so a string you found at offset 900000 in the carved stream can be traced back to a specific unit in the evidence image. `blkstat` reports allocation status and group number for a single unit.

None of these tools writes to the image. That is the property that makes them usable in a case: the tools read, and you decide what to do with the output.

Timelines and hash lookups, the two workflows that need other tools

Two parts of a forensic workflow need more than the layer-by-layer tools. The first is time. `mactime` takes the body files produced by `fls` and `ils` and builds a merged timeline of file activity from the MAC times, and the README describes that merged timeline as the fastest way to get a picture of what happened on a system.

The second is known-file identification. A hash database lets you recognise a file even after it has been renamed, which the README gives as the reason hashing beats matching on names. The toolkit ships `md5` and `sha1` to generate hashes, and `hfind` to index a hash database and search it with a binary search algorithm. `hfind` can query the NIST National Software Reference Library as well as files generated by its own tools or by `md5sum`, so a known-good file list can be applied to an image without importing it first.

The README also describes file type identification using the `file` command, noting that a copy ships with most versions of UNIX. That is worth reading closely as a user: the tool that decides whether an extracted file is an image or an archive is a separate program with its own signature database, and its version affects what it recognises.

Building the library and what the 4.x releases changed

There are no prebuilt binaries here. The tree is a GNU autotools project, with `bootstrap`, `configure.ac`, `Makefile.am` and a `configure` entry at the top level, plus `INSTALL.txt` for the build steps and a separate `README_win32.txt` for Windows. A source build looks like the standard autotools sequence:

./bootstrap
make

The Windows build is a first-class path rather than an afterthought, with a `win32/` directory and AppVeyor configuration alongside the Travis file for the older Linux CI path. `debian/` carries packaging and `packages/` carries platform-specific packaging, which is what makes the toolkit installable through a distribution rather than only from source.

The release history is where this project is least predictable, and anyone pinning a version should read it. 4.13.0, published 2025-03-11, moved the C++ code to C++17, added experimental btrfs and xfs support, added Windows-only BitLocker support and introduced a Catch-based unit test framework. Then 4.14.0, published 2025-04-15, states plainly that it reverts many changes from 4.13.0 and is closer to 4.12.1, and that the experimental btrfs and bfs work will go into a future release, possibly as a version 5 so parallel releases can exist. The most recent release, 4.15.0 on 2026-04-15, is mostly hardening: bounds checks, NTFS overflow fixes from outside contributors, and a large number of memory bounds checks.

Two details in the repository metadata are worth knowing before you clone. The default branch is `develop-4.1x`, a name inherited from the era when 4.1x was current even though 4.15.0 is the newest release, so the branch name is a historical label rather than a version indicator. The metadata also records no license identifier, while the tree contains a `licenses/` directory alongside `SECURITY.md`; if license terms matter to your use, read that directory rather than relying on the repository field.

Where Autopsy fits and what the command line leaves to you

The most common question about this project is whether it competes with Autopsy. It does not, and the README is direct about the relationship: it recommends using these command line tools with the Autopsy Forensic Browser, which is a graphical interface to the same tools and automates many of the procedures, including image searching and MD5 image integrity checks.

What Autopsy adds over the command line is workflow: case management, a searchable index, a timeline view, reporting. What the command line keeps is transparency. Every result here is plain text you can inspect, re-run with different arguments and paste into a report, and the open source licensing is what allows an investigator to verify what a tool actually did with an image.

The README states that results found with The Sleuth Kit should be recreated with a second tool to verify the data. That is a methodological point rather than a caveat about the code, and it is the right frame for the whole project: it is deliberately low level, deliberately single purpose, and deliberately quiet about what it thinks you found. For a graphical workflow, drive it from Autopsy. For evidence handling where you need to show your work step by step, the layered commands are still the more defensible choice.

Editorial conclusion

The Sleuth Kit is at its best when you already know which layer of the evidence you need and want a tool that does exactly that one thing, with output you can paste into another tool or into a report. It is a poor fit as a one-click forensic suite: there is no case management, no timeline UI and no report writer in this repository. Read the tool overview page on the wiki before a case, build against the 4.1x development branch rather than the 4.15.0 tag if you need stability, and reproduce anything you find with a second tool, which is what the README itself tells you to do.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sleuthkit/sleuthkit on GitHub