IMAGING USING

FTK IMAGER
Proper forensic acquisition is one of the most important task
of a forensics investigator. The evidence acquired and its
acquisition process should be repeatable, accurate, authentic
and documented. Besides acquiring the evidence from the live
system, it is necessary to create an image of the evidence for
offline analysis. Such analysis allows access to the deleted files,
slack space and even to hidden areas on the evidence drive.

O
nce all the volatile information from a system has been acquired securely and the acquisition has
been properly documented, it is time to image the hard disk. An image is an exact bit stream copy
of all the sectors of the original disk drive by which every byte on the drive is collected, as well as
all its empty space, unallocated space, slack, bad or corrupted sectors etc. This imaging can be carried
out for any kind of media, i.e. hard disks, CDs, DVDs, etc. An image is also known as a clone, a bit-by-bit
copy or a sector-by-sector copy. It is also sometimes erroneously called mirror image or a ghost image;
they do not generate true forensic images. The most reliable method of imaging a hard disk drive is on
a computer that has been powered off, i.e. it is ‘dead’.

But this is not always possible – for example, servers cannot always be taken offline and powered off.
For such systems the imaging has to be done on a live system and can be performed by using a live
CD like Helix, or over the internal network with Guidance Software’s Encase or by running FTK Imager
Lite from a USB storage device connected to the system. There is a small tool that works independent
of the forensic imaging, F-Response, and can be used for over-the-network control of a suspect system.
F-Response is usually deployed on the system that needs to be imaged and the investigator’s system
connects with it over the network, getting access to the system’s physical disks which can then be imaged.
This is a particularly useful tool in situations where it is difficult to deploy a well-trained first responder.

With devices that are structured in a RAID array things get more complicated. While it is possible to
image each of the RAID drives individually, rebuilding the images acquired into a single, functioning,
RAID array image correctly is not an easy task. This would require detailed knowledge of the RAID array
was originally structured and the correct numbering of the disks in the array. Should the investigator opt
for this method of acquisition, a tool that does allow RAID image rebuilding is OSForensics by Passmark
Software. If the investigator chooses not to image individual member drives of a RAID array and then
rebuild them, there are two alternative methods that can be used. These methods find more favour with
investigators than the previous, more risky method. The first of these methods is to image the RAID array
when the system is ‘live’, thereby creating a single image for the entire RAID array. This can be done
by using a Linux live CD like Helix or Knoppix or by using FTK Imager or FTK Imager Lite. The other

23 www.eForensicsMag.com
 option is to employ software like Encase, WinHex or X-Ways Forensics which recognise RAID drives
and rebuild the image correctly. If, of course, the RAID drive is USB driven then it can be plugged into
a system and cloned as a single drive.

Figure 1. RAID array rebuild using OSForensics

When a drive (also known as the evidence drive) from a dead system is to be imaged, the normal pro-
cedure is to remove it from the computer system cabinet and to connect it to the investigator’s system.
This investigator’s system would have an imaging software installed on it, like FTK, FTK Imager, Encase,
SIFT, or any other flavour of Linux with ‘dd’ or ‘dc3dd’. This poses a problem, which is that if the evidence
drive is connected to an imaging system, it will naturally be read by that system. Also, if Autorun is en-
abled, the drive will open and the timestamps of its contents will change. The evidence drive would also
be scanned by the resident antivirus software on the investigator’s system. There is also the possibility
that any malware on the investigator’s system will infect this connected evidence drive. Any such activity
would, naturally, destroy the integrity of the evidence drive. To prevent such hazards the evidence drive
is connected to the investigator’s systems, and accessed by this system, through a write-blocker.

A forensic write-blocker is a specialized type of computer hard disk controller made for the purpose
of gaining read-only access to computer hard drives without the risk of damaging the drive’s contents.
While the write blocker can be a software or a hardware one, most investigators prefer a hardware write
blocker. Besides added reliability, hardware write blockers do not depend on the investigator’s system
for speed and therefore provide higher imaging speeds. The best recognised hardware write blockers
are provided by Tableau and come in many different kinds. Tableau also has drive imagers which are
different from write blockers. While a write blocker is a hardware interface between the imaging system
and the drive (or disk) being imaged and prevents the imaging system from writing back onto the evi-
dence drive, a drive imager comes pre-installed with an imaging software and interfaces between the
evidence drive and the drive onto which the evidence image is being written. Drive imagers have much
higher speeds and can image large drives in a lot less time. Write blockers should a mandatory part of
any investigator’s toolkit; and if the budget permits it a hardware forensic imager should also be included.

24 www.eForensicsMag.com
 Figure 2: Tableau Write Blocker and Tableau Forensic Imager TD3

FTK IMAGER / FTK IMAGER LITE

FTK Imager is, probably, one of the most well used Windows based acquisition tools and is included in
many forensic toolkits like Helix and SIFT (the SANS SIFT Workstation). There is also a portable version
called FTK Imager Lite which can be run of a CD or an USB device. For the purpose of understanding
how to use FTK Imager, we will with the scenario where the hard disk drive of a system has removed
and is being connected, for imaging, to the investigator’s system. At this time, it is prudent to initiate the
Chain-of-Custody document for this evidentiary item and make note of its serial number, the manufac-
turer’s name, the model number of the drive, its capacity and any unique markings, scratches or damage
to the drive. Some investigators prefer to attach photographs of the evidentiary items to the Chain-of-
Custody documentation.

A Chain-of-Custody document is a chronological document that has a description of the item of evi-
dence, as well as information about its seizure, custody, storage, control, transfer, analysis and, possibly,
its destruction. The item of evidence could be either physical or electronic. This document is very impor-
tant to prove the integrity and authenticity of the evidence item in a court of law. A chain-of-custody form
would also track the movement of the item of evidence and when this item of evidence is transferred from
the custody of one person to the custody of another, for instance from the custody of the first responder
to that of the examiner, an entry is made in the chain-of custody form and is duly signed by both parties.

Figure 3. Sample Chain-of-Custody document

25 www.eForensicsMag.com
 Once the evidence drive has been connected to investigator’s system via the write blocker, it is time
to image the said drive. With FTK Imager being used for the imaging, the first step is to start the tool and
run FTK Imager.exe. Once the application starts, select Create a Disk Image from the File menu and
choose the source of your image, i.e. choose the drive that needs to be imaged. (The screenshots at-
tached here are of the imaging of a pendrive, but the process stays the same irrespective of the kind of
drive being imaged.)

Figure 4. Create Disk Image using FTK Imager

FTK Imager gives you option of selecting a Physical Drive which is the entire drive attached, a Logical
Drive where the investigator can select a logical partition from the entire drive, an Image File by which
a previously acquired image can be reimaged, the Contents of a Folder which would give the logical con-
tents of the folder but will not image the unallocated space etc., and the Fernico Device allowing imaging
of multiple spooled CDs or DVDs. The investigator selects the source depending on the investigation’s
requirements. The next window would provide a drop-down list of all the attached drives and, in the case
of the Logical Drive selection, will also provide the file format of the drives.

Figure 5. Source selection and Drive selection while imaging in FTK Imager

The next window that is the Create Image window and requires the investigator to provide the image
destination for the acquired image. This is done by clicking the Add button. The window also has three
options which can be checked. When the Verify images after they are created option is checked, FTK
Imager will calculate MDS and SHA1 hashes of the acquired image and compare them with the hashes
it has calculated for the original drive. These hashes are to be added to the Chain-of-Custody docu-
ment. The Precalculate Progress Statistics calculates the estimated time for the acquisition and verifica-
tion of the image, while the Create directory listings... option creates the directory listing for the directory
structure in the image. If the investigator checks the Directory listings box then the output file generated
should be attached to the case documentation, maybe as an appendix. FTK Imager allows the investi-
gator to select the type of image that will be created. The Raw image is the raw or dd type and uses the

26 www.eForensicsMag.com
 .001 extension which works with all open source forensic tools, the E01 type creates an image that can
only be analysed using Encase, while the SMART and AFF types are special forensic imaging file types.

Figure 6. FTK Imager Create image and select Image Type

The next window requests case information which should be filled in accurately by the investigator.
Once this is done, it is time to select the image destination, which can be done in the following window.
Here the investigator selects the image’s destination folder as well as provides the image with its file
name. Remember, the file extension has selected earlier when the image type was selected. Depending
on the image type selected, the investigator might be able to fragment the acquired image. This fragmen-
tation is performed if the image is to be stored on to a location/s that does not have the required space,
for example on DVDs. This window also allows the investigator to compress the image file with a scale of
0 to 9, with 0 being the no compression and 9 providing the maximum available compression. Compres-
sion, however, adds to the time taken for imaging and the higher the level of compression, the more time
it takes. Once all the options are decided on, the investigator is taken back to the preceding window and
can Start the acquisition. This will start the imaging process and a progress window will appear. Once the
acquisition is complete, the image summary is displayed. This image summary, in greater detail, is also
stored as a .txt file in the same destination folder as the image and has the same name as the image file.

Figure 7. FTK Imager imaging progress window and drive verification results

Here ends the imaging process using FTK Imager. Some minor analysis can be done at this time
through FTK Image, but the bulk of the analysis of evidence should be done through a proper forensic
analysis software.

27 www.eForensicsMag.com
 EXERCISE: ACQUIRE AN IMAGE OF A DRIVE USING FTK IMAGER
• Disconnect a drive from a system
• Initiate a Chain-of-Custody document
• Enter all relevant details into the Chain-of-Custody document
• Connect the drive to your system
• Image the drive using FTK Imager

LINUX DD AND DC3DD

The dd command, available by default in Linux and Unix-like operating systems, is a simple tool which is
both versatile and powerful. It is also the oldest forensic imaging tool. The main purpose of the dd com-
mand is to convert and copy files. It can be used to copy from a source to a destination or block-by-block
and can be used on any operating systems or file systems. The dd command can and is used for foren-
sic imaging as well and most forensic investigators prefer to use dd from a live CD or a liveUSB while
imaging. Obviously, it is better to be cautious when using dd, because if used improperly it can destroy
data. There is a new and much easier variant of the dd command, which has been developed by the U.S.
Department of Defence – the ‘dc3dd’ command. The dc3dd command comes packaged with specialised
computer forensic features.

The most common mistake made by responders and investigators, when using the dd and the dc3dd
commands, is to mix up the order of the input file (if=) and the output file (of=) when performing the imag-
ing, with the result that the evidence drive is overwritten by the blank sectors of the investigator’s image
drive. Here again, it is important to ensure that the destination image drive has the capacity to host the
image, i.e. its capacity is equal to or greater than the capacity of the evidence drive. It is not possible to
compress the image as dd creates images in the raw format which does not permit compression, but can
be fragmented (as was seen in FTK Imager).

Once the live CD has be run on the system in question, it is recommended that the investigator switch
to the Root which can be done by typing the su command and providing the password. Live CDs often
have the word ‘root’ as both the username and the password. It is better to ensure that no partitions form
the system’s hard disk drive have been mounted at this time.

Depending on the case brief and its requirements, the investigator would decide if the entire disk need
to be imaged or just a partition of the disk. This is comparable to the Physical drive and Logical drive
options in FTK Imager. Once the investigator has decided this, the evidence drive is then mounted on
to Linux. This can be done with the help of the mount command # mount -t vfat /dev/sda1 /mnt/sda1.
Here a FAT32 drive is being mounted onto the system. If the investigator is uncertain about the evidence
drive’s file system, the fdisk –l command can be used to get more information.

Once the drive has been successfully mounted, it is time to image it. If the investigation requires the
entire disk to be imaged onto another drive, including the MBR, all partitions etc., then the command
used is dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync, where ‘if’ is the input file or
the evidence drive, ‘of’ is the output file or the image drive and ‘bs’ is the block size which is being set to
4kb, an optimal size for a hard disk read/write efficiency and by extension, imaging speed. The ‘notrunc’
instruction is so that dd does not truncate, or cut out, any data, thereby maintaining the integrity of the
drive and its image, while ‘noerror’ instructs dd to ignore any read errors and to continue the imaging op-
eration. This instruction is necessary as the default practice of dd is to halt operations should it encounter
any error. The ‘sync’ instruction prevents the data offsets from getting skewed by asking dd to write ze-
roes for any read errors. If the investigator chooses to image a partition from the evidence drive, then the
same command would be used with the partition name being used instead of the drive notation. So the
command would be dd if=/dev/sda1 of=/dev/sdb1 bs=4096 conv=notrunc,noerror,sync. Here, sda1
is the notation of the relevant partition on the evidence drive, while sdb1 is the image. As can be seen,
imaging with dd requires a lot of caution and needs the first responder or the investigator to be very com-
fortable with Linux and its commands.

After the imaging is complete, it is essential to verify the image. For this hash values of the original
evidence drive and the image drive are computed and compared. If they match, the imaging process
was proper, if not then something went drastically wrong. The hash values can be computed by using

28 www.eForensicsMag.com
 the md5sum /dev/sd* where the command is run separately for the evidence drive and the image drive,
with the relevant drive name being inserted in place of sd*, and the output is compared.

The more common practise is, of course, to create a image file of the evidence drive, rather than
creating an image drive. This can be achieved by the dd if=/dev/hda of=evidence1.img bs=4096
conv=noerror,sync. As verification is essential for forensic purposes, the command which would perform
the imaging and hashing processes dd if=/dev/hda of=evidence1.img bs=4096 conv=noerror,sync
--md5sum --verifymd5 --md5out=evidence1.img.md5. Another variant of the dd command that can be
used is the dc3dd command, which was specially designed for forensic purposes. The use of the ‘dc3dd’
command certainly simplifies the life of an examiner. The command used would be dc3dd if=/dev/sda
of=evidence1.img hash=md5. While dd creates images in the raw format only, dc3dd allows the inves-
tigator to create a .aff image as well. Certain flavours of Linux, for example Caine, come with a GUI for
dc3dd, further simplifying the life of the examiner.Images created by dd and dc3dd can then be imported
and analysed using any forensic analysis tool, like Helix, FTK, Encase, WinHex or SIFT.

EXERCISE: CREATE A DRIVE IMAGE USING LINUX DD AND DC3DD

• Run a live CD of linux
• Change user to root
• Mount the evidence drive
• Create an image of the evidence drive (as disk image as well as image file)
• Verify the hash (If the hash generated for the evidence drive and the hash generat-
ed for the image are the same, then the hash is verified)
• Create an image using dc3dd and verify the image

DOWNLOAD LINKS

• FTK Imager – http://accessdata.com/product-download?/support/product-downloads

• Helix – https://www.e-fense.com/store/index.php?_a=viewProd&productId=11
• Dc3dd – http://sourceforge.net/projects/dc3dd/

29 www.eForensicsMag.com