Table of Contents for

Practical Forensic Imaging

3
FORENSIC IMAGE FORMATS

This chapter provides an overview of the various acquisition tools, evidence containers, and forensic image formats commonly used today. Forensic image formats and evidence containers are the structures that store the forensically acquired image together with additional case data, such as the time and duration of the acquisition, how the image was acquired, size, errors, hashes, and so on. Additional features of forensic formats typically include compressed files and encryption. This chapter demonstrates command line forensic tasks using several forensic formats.

You’ll find an informative introductory paper describing various forensic formats on the Digital Forensic Research Workshop (DFRWS) website at http://www.dfrws.org/CDESF/survey-dfrws-cdesf-diskimg-01.pdf.

You can identify the commonly used forensic formats described in this chapter by using the Sleuth Kit command img_stat:

# img_stat -i list
Supported image format types:
        raw (Single or split raw file (dd))
        aff (Advanced Forensic Format)
        afd (AFF Multiple File)
        afm (AFF with external metadata)
        afflib (All AFFLIB image formats (including beta ones))
        ewf (Expert Witness format (encase))

In addition to these formats, this chapter introduces an ad hoc method using SquashFS as a practical forensic container for use with standard forensic tools.

Raw Images

Raw images are not a format per se but a chunk of raw data imaged from an evidence source. Raw images contain no additional metadata aside from the information about the image file itself (name, size, timestamps, and other information in the image’s own inode).

Extracting a raw image is technically straightforward: it is simply the transfer of a sequence of bytes from a source device to a destination file. This is normally done without any transformation or translation.

Disk block copying tools, such as dd and variants, are most commonly used to extract raw images. These are discussed in the following sections.

Traditional dd

To create raw images, the simplest tool available, as well as the oldest, is the original Unix dd utility. It was not designed for evidence collection, but its simple byte-by-byte transfer is useful for imaging disk devices, because it makes a complete low-level copy of individual sectors of a disk (preserving the filesystem structure, files, directories, and metadata). However, features such as logging, error handling, and hashing are either inadequate or nonexistent; dd can be used when a better alternative isn’t available. The Computer Forensic Tool Testing (CFTT) Project has tested several standard dd versions. You’ll find the test results on the CFTT website at http://www.cftt.nist.gov/disk_imaging.htm.

The dd utility was created in the 1970s on early UNIX systems for byte-order conversion and block copying. It was initially developed to convert EBCDIC-encoded data from the mainframe world into ASCII encoding, which was preferable in the UNIX environment. The program simply takes blocks of data from a source, optionally performs a conversion or transformation, and then places the blocks in a specified destination (on another device or in a file). Modern versions of dd have enhancements that make it useful for performing forensic acquisition of data from devices, such as disks and tapes.

Forensic dd Variants

Because the original dd tool was not designed for use in a forensic context, certain features are missing. Subsequently, tools based on dd were developed to include desired forensic features, such as:

• Cryptographic hashing

• Improved error handling

• Logging

• Performance enhancements

• Verification checking

• Progress monitoring (forensic imaging can take many hours)

The two most commonly used variants of the dd utility are dcfldd, created by Nicholas Harbour at the US Department of Defense Computer Forensics Lab (DCFL) in 2002, and dc3dd, created in 2007 by Jesse Kornblum while he was at the US Department of Defense Cyber Crime Center (DC3).

The dcfldd tool is based on GNU dd and included additional features, such as hashing, improved logging, and splitting output files, among others. Although there have been no updates since 2006, the tool is still used today. Alexandre Dulaunoy created a patched version of dcfldd that included some Debian bug fixes, which you’ll find at https://github.com/adulau/.

The more recent dc3dd tool is implemented as a patch and can more easily follow code changes to GNU dd. The tool is currently maintained, and recent updates have been made. It includes similar forensic features as dcfldd and implements improved logging and error handling.

Both dcfldd and dc3dd originated from traditional dd and have similar features. Although neither tool has built-in support for writing to forensic formats (FTK, Encase, AFF), compression, or image encryption, you can use command piping and redirection for these tasks. Examples of both tools are shown throughout this book. Test reports from CFTT exist for dcfldd and dc3dd.

Data Recovery Tools

Several data recovery tools are worth mentioning because of their robust error handling and aggressive recovery methods. Although these tools were not written with forensics in mind, they can be useful in situations where all other forensic tools have failed to recover data from severely damaged media.

GNU ddrescue and dd_rescue have similar names but are different tools, developed independently. As of this writing, both tools were under active development, each with different useful features. Although they both reference dd in their names, neither tool uses the dd command syntax.

GNU ddrescue was created in 2004 by Antonio Diaz Diaz and is packaged under Debian using the package name gddrescue. It uses aggressive and persistent methods to attempt the recovery of bad areas of a disk.

The dd_rescue tool was created in 1999 by Kurt Garloff and has an elaborate plugin system that supports compression, encryption, hashing, and other plugins.

Other similar storage media recovery tools include myrescue and safecopy. Some of these tools will be demonstrated in Chapters 6 and 7.

Forensic Formats

Several issues with raw images have led to the creation of forensic file formats. When imaging storage media as evidence, there is metadata about the investigation, the investigator, the drive details, logs/timestamps, cryptographic hashes, and so on. In addition to metadata, there is often a need to compress or encrypt an acquired image. Specialized forensic formats facilitate the implementation of these features, and the most common formats are described here.

Forensic file formats are sometimes called evidence containers. Some research work has also outlined the concept of digital evidence bags.¹ Tools to perform acquisition into forensic formats are demonstrated in Chapter 6.

EnCase EWF

Guidance Software, one of the oldest forensic software companies, produces its flagship EnCase forensic software suite, which uses the Expert Witness Format (EWF). The EWF format supports metadata, compression, encryption, hashing, split files, and more. A reverse engineered, open source library and tools, libewf was created in 2006 by Joachim Metz and support can be compiled into Sleuth Kit.

FTK SMART

AccessData’s FTK SMART format is a direct competitor to EnCase EWF. It’s a proprietary format that also includes metadata, compression, encryption, hashing, split files, and more. The command line ftkimager tool (which is free but not open source) is available from AccessData and is demonstrated in Chapters 6 and 7.

AFF

The Advanced Forensic Format (AFF) was created by Simson Garfinkel as an open, peer-reviewed, published format. It includes all the expected features of a forensic format and also includes additional encryption and signing features using standard X.509 certificates. The AFFlib software package contains a number of tools for converting and managing the AFF format.

AFF version 3 is separately maintained at http://github.com/sshock/AFFLIBv3/. In 2009, a paper on AFF version 4 was published.² The Current AFF version 4 website can be found at http://www.aff4.org/. The Advanced Forensic Format 4 Working Group (AFF4 WG) was announced in summer 2016 with the first meeting held at the DFRWS conference in Seattle.

SquashFS as a Forensic Evidence Container

Throughout this book, I’ll demonstrate a technique for creating a hybrid forensic container that combines simple raw imaging and allows storage of supporting case information in a similar way as more advanced forensic formats. The technique uses SquashFS as a forensic evidence container together with a small shell script, sfsimage, which manages various aspects of the container. This method creates a compressed image combined with imaging logs, information about the disk device, and any other information (photographs, chain of custody forms, and so on) into a single package. The files are contained in a read-only SquashFS filesystem, which you can access without any special forensic tools.

SquashFS Background

SquashFS is a highly compressed, read-only filesystem written for Linux. It was created by Phillip Lougher in 2002 and was merged into the Linux kernel tree in 2009, starting with kernel version 2.6.29.

SquashFS was designed more for use with bootable CDs and embedded systems, but it has a number of features that make it attractive as a forensic evidence container:

• SquashFS is a highly compressed filesystem.

• It is read-only; items can be added but not removed or modified.

• It stores investigator’s uid/gid and creation timestamps.

• It supports very large file sizes (theoretically up to 16EiB).

• It is included in the Linux kernel and trivial to mount as a read-only filesystem.

• The filesystem is an open standard (tools exist for Windows, OS X).

• The mksquashfs tool uses all available CPUs to create a container.

The use of SquashFS as a forensic evidence container is a practical alternative to using other forensic formats, because it facilitates the management of compressed raw images acquired with dd. The sfsimage tool, described next, provides the functionality you need to manage SquashFS forensic evidence containers.

SquashFS Forensic Evidence Containers

Modern Linux kernels include support for SquashFS filesystems by default. No additional kernel modules or recompiling are necessary to mount and access a SquashFS filesystem. However, to create a file, append a file, or list the contents of a SquashFS file, the squashfs-tools package is required.³ Additional forensic software packages for imaging (dcfldd, dc3dd, ewfacquire) may be required, depending on your preferred imaging tool.

My sfsimage shell script is available at http://digitalforensics.ch/sfsimage/. Running sfsimage without any options provides you with some help text that describes its usage:

$ sfsimage
Sfsimage: a script to manage forensic evidence containers with squashfs
Version: Sfsimage Version 0.8
Usage:
       sfsimage -i diskimage container.sfs
       sfsimage -a file ... container.sfs
       sfsimage -l container.sfs ...
       sfsimage -m container.sfs ...
       sfsimage -m
       sfsimage -u container.sfs ...
Where:
diskimage is a disk device, regular file, or "-" for stdin
container.sfs is a squashfs forensic evidence container
file is a regular file to be added to a container
and the arguments are as follows:
  -i images a disk into a newly created *.sfs container
  -a adds a file to an existing *.sfs container
  -l lists the contents of an existing *.sfs container
  -m mounts an *.sfs container in the current directory
  -m without options shows all mounted sfs containers
  -u umounts an *.sfs container

To configure sfsimage, you can edit the script or create separate sfsimage.conf files for the script to use. The config file is documented with comments and examples, and it allows you to define the following parameters:

• Preferred imaging/acquisition command (dd, dcfldd, dc3dd, and so on)

• Preferred command to query a device (hdparm, tableu-parm, and so on)

• Default directory to mount the evidence container (the current working directory is the default)

• How to manage privileged commands (sudo, su, and so on)

• Permissions and uid/gid of created files

The sfsimage script uses *.sfs as the naming convention for SquashFS forensic evidence containers. The sfsimage(1) manual page is included with the script and provides more details.

To image a disk into a SquashFS forensic evidence container, run sfsimage using the -i flag, the disk device, and the name of the evidence container. An evidence container will be created with the image and initial metadata about the device just imaged. In this example, sfsimage is configured to use dc3dd as the imaging tool:

$ sfsimage -i /dev/sde kingston.sfs
Started: 2016-05-14T20:44:12
Sfsimage version: Sfsimage Version 0.8
Sfsimage command: /usr/bin/sfsimage -i /dev/sde
Current working directory: /home/holmes
Forensic evidence source: if=/dev/sde
Destination squashfs container: kingston.sfs
Image filename inside container: image.raw
Acquisition command: sudo dc3dd if=/dev/sde log=errorlog.txt hlog=hashlog.txt
    hash=md5 2>/dev/null | pv -s 7918845952
7.38GiB 0:01:19 [95.4MiB/s] [========================================>] 100%
Completed: 2016-05-14T20:45:31

Here, a SquashFS container is created, and a regular raw image is produced within it. Additional logs and information are also created or can be added separately.

You can add additional evidence to a container using sfsimage with the -a flag. For example, if you need to add a photograph of the physical disk to the forensic evidence container previously made, the following command will perform the task:

$ sfsimage -a photo.jpg kingston.sfs
Appending to existing 4.0 filesystem on kingston.sfs, block size 131072

To list the contents of a SquashFS forensic evidence container, run the sfsimage script with the -l flag as follows:

$ sfsimage -l kingston.sfs
Contents of kingston.sfs:
drwxrwxrwx holmes/holmes        135 2016-05-14 20:46 squashfs-root
-r--r--r-- holmes/holmes        548 2016-05-14 20:45 squashfs-root/errorlog.txt
-r--r--r-- holmes/holmes        307 2016-05-14 20:45 squashfs-root/hashlog.txt
-r--r--r-- holmes/holmes 7918845952 2016-05-14 20:44 squashfs-root/image.raw
-rw-r----- holmes/holmes     366592 2016-05-14 20:45 squashfs-root/photo.jpg
-r--r--r-- holmes/holmes        431 2016-05-14 20:45 squashfs-root/sfsimagelog.txt

This command output shows the contents of the *.sfs container (without mounting it). Also shown are the correct times when the files were created or added. The error log, hash log, and sfsimage log contain documentation about activity and errors. The photo.jpg is the photograph that was subsequently added to the container.

By mounting the *.sfs file, you can access an acquired image and added metadata files in the SquashFS container. The contents become accessible as a regular part of the filesystem. Because the SquashFS filesystem is read-only, there is no danger of the contents being modified.

In the following example, the *.sfs file is mounted with the -m flag, and regular forensic tools (sleuthkit mmls in this example) are used on the acquired image:

$ sfsimage -m kingston.sfs
kingston.sfs.d mount created
$ mmls kingston.sfs.d/image.raw
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0015466495   0015464448   Linux (0x83)

Note that the mounted *.sfs container (by default) appears as a *.sfs.d directory. Once mounted, you can access the files inside the directory by using regular OS tools or forensic tools or even by exporting the files as a shared drive over a network.

When the *.sfs.d mount is no longer needed, unmount it with the -u flag as follows:

$ sfsimage -u kingston.sfs.d
kingston.sfs.d unmounted

Running sfsimage -m without a mount point will list all mounted SquashFS containers. You can also mount multiple containers on a single system.

Disk image file sizes have always been difficult to work with in a forensic setting. Large disk sizes create space issues and logistical hurdles. Practical compression methods such as SquashFS help manage this problem. To illustrate the practicality of having a compressed filesystem, sfsimage was used to image an 8TB subject disk (bonkers) on an investigator system containing only 2TB of disk space. The entire acquisition took more than 16 hours, and the resulting compressed SquashFS file was only 1TB. The mounted SquashFS file provides access to the full 8TB as a raw image file. The image is compressed on the fly without needing any temporary files. The file sizes of the *.sfs file and the image file are shown here:

$ ls -l bonkers.sfs bonkers.sfs.d/bonkers.raw
-rw-r----- 1 holmes root 1042820382720 Jun 28 13:06 bonkers.sfs
-r--r--r-- 1 root root 8001562156544 Jun 27 20:19 bonkers.sfs.d/bonkers.raw

The use of SquashFS is a practical and effective solution for using raw files in a compressed way and offers an alternative forensic evidence container.

Closing Thoughts

This chapter introduced you to various forensic image formats. I provided a short overview and history of different tools that can be used to forensically acquire a drive. You also learned about the SquashFS filesystem and the sfsimage script used to create and manage SquashFS forensic evidence containers. The tools and formats presented in this chapter will be used in examples throughout the rest of the book.