Appendix A: The Coroner's Toolkit and related software

A.1 Introduction

The Coroner's Toolkit is a collection of forensic utilities by Wietse Venema and Dan Farmer [Farmer and Venema, 2004]. The software was presented first in 1999, in a one-day forensic analysis class at the IBM T.J. Watson Research Center. The first general release was in 2000, via the author's websites. The software was extended in various ways by Brian Carrier, who makes his version available as the Sleuth Kit [Carrier, 2004a]. This appendix presents an overview of TCT and of some of its extensions.

A.2 Data gathering with grave-robber

The grave-robber command collects forensic information. This tool can be used either on a "live" victim machine, or on a disk image from a victim's file system. In "live" collection mode, grave-robber aims to respect the Order Of Volatility (see Appendix B). It uses many of the utilities that are part of TCT to collect information in the following order:

All this information is stored in a "vault", a protected directory structure that is named after the host and the time of the start of data collection. For each file that is stored into the vault, grave-robber also computes the MD5 hash. At the end, as the vault is closed, grave-robber computes the MD5 hash over all individual file hashes.

By definition, grave-robber is exposed to information that comes from the untrusted victim machine. It frequently uses this information while executing TCT commands and system commands. While doing so, it takes great care to never expose that untrusted information to a shell command interpreter. For more of the philosophical issues behind grave-robber, see Appendix B.

A.3 Time analysis with mactime

The mactime command takes file attribute information from a body file that was produced by grave-robber, and produces a chronological report of all file access methods by file name. Alternatively, mactime can generate a body file on the fly while it scans a file system. This tool was written several years before the authors started work on the TCT, and was adapted to fit into the grave-robber framework. mactime is introduced in chapter 2, "Time machines", and a larger example can be found in chapter 4, "File system analysis".

As an example of the kind of insight that mactime can give, listings A.1 and A.2 present different views of the same remote login session. The first shows what the remote user sees, and the second shows the corresponding MACtime report. For educational reasons the example uses a very old machine so that the MACtimes are spread out over time. This allows us to see a clear separation between the start-up of the telnet server and login software, the access of system files while the user logs in, and the start-up of the user's login shell process.

$ telnet
Connected to
Escape character is '^]'.

SunOS UNIX (sunos)

login: zen
Last login: Thu Dec 25 09:30:21 from
Welcome to ancient history!

Listing A.1: User view of a remote login session.

Time        Size MAC Permission Owner Group File name
19:47:04   49152 .a. -rwsr-xr-x root  staff /usr/bin/login
           32768 .a. -rwxr-xr-x root  staff /usr/etc/in.telnetd
19:47:08     272 .a. -rw-r--r-- root  staff /etc/group
             108 .a. -r--r--r-- root  staff /etc/motd
            8234 .a. -rw-r--r-- root  staff /etc/ttytab
            3636 m.c -rw-rw-rw- root  staff /etc/utmp
           28056 m.c -rw-r--r-- root  staff /var/adm/lastlog
         1250496 m.c -rw-r--r-- root  staff /var/adm/wtmp
19:47:09    1041 .a. -rw-r--r-- root  staff /etc/passwd
19:47:10  147456 .a. -rwxr-xr-x root  staff /bin/csh

Listing A.2: MACtime view of the listing A.1 remote login session. The MAC column indicates the file access method (Modify, read Access, or status Change). Files names with the same time stamp are sorted alphabetically.

A.4 File reconstruction with lazarus

As discussed in chapters 3 and 7, modern file systems minimize file access times by keeping related information closely together. Among other things, this reduces the fragmentation of individual files. The TCT program lazarus takes advantage of this property when attempting to reconstitute the structure of deleted file content.

lazarus is a simple program whose goal is to give unstructured data some form that is both viewable and manipulatable by users. It relies on a few simple principles and heuristics:

With these in mind lazarus implements a sort of primitive digital X-ray device. It creates a map of the disk that essentially makes the drive transparent -- you can peer into the disk and see the data by content type, but the highly useful filesystem abstraction is lost. Figure A.1 shows an example of the interface and a once-deleted image file.

Figure A.1: lazarus uncovering a deleted image.

In the map of a disk, lazarus uses simple text characters to represent data chunks. A capital letter is used for the first block of a chunk, while lower case is used for its remainder. For example, "C"'s represent C source code, "H"'s are hypertext, "L"'s are log files, "M"'s mail, "U"'s uuencoded content, and "."'s unrecognized binary data.

In order to keep the map manageable, lazarus compresses large chunks using a logarithmic (base 2) scale. This means a single character is 1 block of data, the second character 2 blocks, the third 4, etc. This allows large files to be visually significant but not overwhelming - with a 1024 byte block size, a megabyte file would only take up ten times the space of a single block file.

lazarus demonstrates that UNIX file systems like to keep related information within the same file system zone. For example, figure A.1 shows that email files (indicated with "Mmmm") tend to be clustered together. The figure also shows that email with lots of hypertext or uuencoded content is likely to be mis-identified. The clustering of files and file activity has important consequences for the persistence of deleted information, as we see in chapter 7, "Persistence of Deleted File Information".

Software such as lazarus presents a problem of non-trivial scope. While lazarus takes care to neutralize active content in hypertext etc. by rendering it as plain text, it does no sanity checks on other data such as images, and may trip up bugs in a very large and complex web browser program.

lazarus has not evolved since its initial release. People who want to browse disks should consider using Brian Carrier's Autopsy tool [Carrier, 2004b].

A.5 Low-level file system utilities

The TCT comes with a number of utilities that bypass the file system layer. This allows the software to access existing file as well as deleted file information. Instead of file names, these programs use the abstraction of inode numbers and bitmap allocation blocks, or the even lower-level abstraction of disk block numbers. These lower-level concepts are introduced in chapter 3, "File system basics".

The TCT supports popular UNIX file systems such as UFS (BSD and Solaris), and EXT2FS and EXT3FS (Linux). The Sleuth Kit also adds support for non-UNIX file systems such as NTFS, FAT16 and FAT32 (Microsoft Windows).

Utilities that are part of the original TCT distribution:

The Sleuth Kit adds a number of other low-level utilities, such as:

The success rate of low-level file system tools with deleted file information is highly dependent on the file system type, and even on the version of the operating system software. Section 4.11, "what happens when a file is deleted", discusses how much information is lost and what is preserved when a file is deleted.

A.6 Low-level memory utilities

The tools described in this section are more for exploratory use than rock-solid analysis. The reason for this is that their output contains little or no structural meta information, so that it is suitable only for processing with tools that don't take advantage of such information.


[Carrier, 2004a] Brian Carrier's Sleuth Kit.
Available from:

[Carrier, 2004b] Brian Carrier's Autopsy Forensic Browser.
Available from:

[Farmer and Venema, 2004] The Coroner's Toolkit software by Dan Farmer and Wietse Venema.
Available from: