FTK Imager

FTK Imager is a popular program for making forensically-sound images of various storage media including both a conventional hard disks and solid-state drives. FTK Imager supports various types of image files, including EnCase Physical (.e01), SMART, Advanced Forensic Format (.AFF), DD (.001, .img), and many others, which makes it an indispensable tool for reading and converting from various image formats. While the command-line version was last updated in 2012, and remains at version 3.1.1, it is more than adequate at creating initial forensic images of a given device.

Dockerizing FTK Imager CLI was relatively straightforward. Since it is a command-line application, there is no need to worry about ${DISPLAY} or /tmp/.X11-unix. Also, while it is best practice to run Docker containers as a user other than root, FTK Imager requires device access, so in this case, the image is built to intentionally to run as root.

FROM ubuntu:cosmic
LABEL maintainer "djds djds@ccs.neu.edu"

ENV DEBIAN_FRONTEND="noninteractive"

RUN mkdir /setup
WORKDIR /setup

RUN apt-get update && apt-get dist-upgrade -y \
    && apt-get install -y \

RUN wget "https://ad-zip.s3.amazonaws.com/ftkimager.3.1.1_ubuntu64.tar.gz" \
    && tar -xf ftkimager.3.1.1_ubuntu64.tar.gz \
    && chmod +x ftkimager \
    && mv ftkimager /usr/local/bin/

RUN mkdir /data \
    && rm -rf /var/lib/apt/lists/* \
    && rm -rf /setup


ENTRYPOINT ["/usr/local/bin/ftkimager"]

This image is again based on Ubuntu 16.10 (Cosmic Cuttlefish), which is the most current Ubuntu release, meaning it is relatively up to date and has good security support. The DEBIAN_FRONTEND environment variable is set to noninteractive so that no user input is prompted for during the building of this image. The next step is to make a /setup directory to download the ftkimager.3.1.1_ubuntu64.tar.gz tarbal from AWS S3 storage. The next RUN directive updates the base image and installs wget which is needed within the image to download ftkimager. Next the binary is unpacked and moved to the /usr/local/bin directory and made executable. Next a /data directory is created which will be used as a place to share arbitrary data with the host (such as image files). Finally, some cleanup is run to reduce the size of the final image. The ENTRYPOINT directive specifies the default process for a container to run when using this image. In this case, running the container will activate FTK Imager, so that the container behaves as if the program were being invoked directly on the host.

Building the image is the first step in the process, but it is not very useful without the proper run-time parameters. This can easily be put into a script, or wrapped in a bash function and sourced from ${HOME}/.bashrc or so.


docker run --rm -it \
    -c 4 \
    -m 4096M \
    -v /etc/localtime:/etc/localtime:ro \
    -v /dev/shm:/dev/shm \
    -v "$(pwd):/data" \
    --name ftkimager \
    "${REGISTRY}/${user}/${repo}:${tag}" "${@}"

The ${@} will allow us to pass arbitrary arguments to the container, as if it were running natively on the host. For example, by wrapping the above script in a Bash function, called ftkimager(), we can call the program as ftkimager, and receive the following (as if we had passed the --help parameter).

$ ftkimager
AccessData FTK Imager v3.1.1 CLI (Aug 24 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Usage:  ftkimager source [dest_file] [options]
source can specify a block device, a supported image file, or `-' for stdin
if dest_file is specified, proper extension for image type will be appended
if dest_file is `-' or not specified, raw data will be written to stdout
  --help        : display this information
  --list-drives : show detected physical drives
  --verify      : hash/verify the destination image,
                  or the source image if no destination is specified
  --print-info  : print information about a drive or image and then exit
  --quiet       : do not show create/verify progress information
  --no-sha1     : do not compute SHA1 hash during acquire or verify
(The following options are valid only when dest_file is specified):
  --s01         : create a SMART ew-compressed image
  --e01         : create an E01 format image
  --frag x{K|M|G|T} : create image fragments at most x {K|M|G|T} in size
                  also accepts kB, MB, GB, and TB for powers of 10 instead of 2
  --compress C  : set compression level to C (0=none, 1=fast, ..., 9=best)
  e01/smart metadata (use quote marks when X contains spaces):
    --case-number X
    --evidence-number X
    --description X
    --examiner X
    --notes X
AD Encryption Options:
  --inpass P      : decrypt source file using password P
  --incert C [P]  : decrypt source file using certificate C with password P
  --outpass P     : encrypt dest file using password P
  --outcert C [P] : encrypt dest file using certificate C with password P

The above output shows the syntax to create and verify images, as well as display metadata, and encrypt image files. To create an image, it is necessary to modify the docker run command to mount the device to image inside the container, but adding the --device=/dev/sdX, line in the body of the script. For example it is possible to create an image of a USB drive, /dev/sda, with the following command line parameters:

$ ftkimager /dev/sda ftk_test \
    --verify \
    --e01 \
    --case-number "docker_001" \
    --examiner "djds"

Creating image...
Image creation complete.
Verifying image...
Image verification complete.
 Computed hash: e500c070f017f7bb83db6df9c4963cb6
 Image hash:    e500c070f017f7bb83db6df9c4963cb6
 Report hash:   e500c070f017f7bb83db6df9c4963cb6
 Verify result: Match
 Computed hash: 0b4696cbdb31733941bf53da3c867a7331f77773
 Image hash:    0b4696cbdb31733941bf53da3c867a7331f77773
 Report hash:   0b4696cbdb31733941bf53da3c867a7331f77773
 Verify result: Match

It is then possible to check that the assigned metadata was embedded in the image by calling the --print-info command:

Physical Evidentiary Item (Source) Information:
[Device Info]
 Source Type: Physical
[Verification Hashes]
 MD5 verification hash: e500c070f017f7bb83db6df9c4963cb6
 SHA1 verification hash: 0b4696cbdb31733941bf53da3c867a7331f77773
[Drive Geometry]
 Bytes per Sector: 512
 Sector Count: 493792
 Image Type: E01
 Case number: docker_001
 Evidence number:  
 Examiner: djds
 Acquired on OS: 5.0.7-0
 Acquired using: ADI3
 Acquire date: Sun Apr 21 12:38:45 2019
 System date: Sun Apr 21 12:38:45 2019
 Unique description: untitled

It is now possible to build this image on any (Linux) host with a recent Docker installation, or alternatively pull it from the (currently) public container registry hosted on GitLab.

$ docker pull registry.gitlab.com/bghost/docker-forensics/djds/ftkimager:latest

Once fktimager is built and running, it is possible to create forensic images. The next step is to analyze them using a variety of tools. The first of these is the open source Autopsy, a graphical application which allows for all sorts of automated ingest and the recovery of deleted files.