Concepts of Forensic Imaging

Table of Contents

Sharing is caring

This entry is part 1 of 2 in the series Digital Forensics and Incident Response

Core Concepts

The process of imaging a disk starts by identifying the target drive, preparing it for imaging, and then creating the image file which is later verified for integrity. This needs to be performed in an environment that allows us to perform these tasks and also ensures the process is properly logged.

Each operating system has specific file system structures and configurations that require different imaging tools and techniques.

The use of open-source software for image acquisition is an advantage in many cases since it can satisfy guidelines for evidential reliability that need to be fulfilled. The Linux kernel also supports many file systems, which is a big advantage when analyzing different media types.

Write-Blockers

It is important to mention that write-blockers are usually required when manipulating physical disks. A write-blocker is a device used to prevent any modifications to data on a storage device during analysis. It ensures reading data without risking changes to the original evidence.

Write-blockers work by physically intercepting all drive commands that write data sent between the disk being imaged and the OS attached to it.

Audit Trail

An audit trail is a chronological record that tracks actions and events within a system, providing a detailed history for accountability and security. It ensures traceability by documenting each step. This step can be performed with different parameters depending on the legal or compliance framework required by the task.

We can manually or automatically record the actions and events with varying detail levels. Since we need to preserve the evidence and keep track of our activities, let’s explore some methods for tracking tasks and automating command-line activity logging to help us have this audit trail of our process.

If we are using bash, the history command can help us log our activity. It can be saved using a timestamp and preserved in a file. Below, we can observe a chart with some commands recommended to use during our session.

`set -o history`	Enables command history in the shell, allowing it to record the commands you enter.
`shopt -s histappend`	Ensures that the command history is appended to the history file instead of overwriting it when the shell exits.
`export HISTCONTROL=`	Clears any settings that control which commands are saved in the history, ensuring all commands are recorded.
`export HISTIGNORE=`	Clears any settings that ignore specific patterns of commands, so all commands are saved in the history.
`export HISTFILE=~/.bash_history`	Sets the file where the command history is saved.
`export HISTFILESIZE=-1`	Sets no limit on the number of lines stored in the history file.
`export HISTSIZE=-1`	Sets no limit on the number of commands retained in the shell history.
`export HISTTIMEFORMAT="%F-%R "`	Formats timestamps in the history as “YYYY-MM-DD HH” for each command.

Another good practice is to log all sessions. Tools like ttyrec, can help here.

Finally, we should always save the output of any command we execute to a file if possible.

Accessing the File System

While the disk and devices used may differ depending on the requirements and the environment, the process is similar for all disks physically or virtually attached to the Linux/Windows/MAC OS.

Drives are attached as devices under the /dev directory. In the output above, the current disk used by the OS is listed under /dev/root. The device that needs to be imaged is not mounted yet, and since it is a Virtual Disk attached to a loop interface, it will not appear using the command df. This is also common for physical disks when not directly attached.

We can still list block devices using the lsblk command with the -a option to list all devices, as shown below.

Above, we can observe the loop10 interface initialized with 1.1 GB, which is the Disk that needs to be copied/imaged for Forensics. This should also be noticed since we need to know that we have enough space to create the images either on the disk we will copy it or on the disk where we will save the image. In our case, is the xdva block, which corresponds to the /dev/root/. The partition is 40 GB in size.

We can get more info about the device using the losetup command with the -l option to list the device and the assigned interface path, in this case /dev/loop10.

It is possible to acquire further information like the UUID of the image using the blkid with the interface as an argument, as demonstrated in the following example.

Creating a Forensic Image

List of some common tools used to create images.

`dd`	A standard Unix utility for copying and converting files, often used for creating raw disk images
`dc3dd`	An enhanced version of `dd` with additional features for forensic imaging, including hashing and logging
`ddrescue`	A data recovery tool that efficiently copies data from damaged drives, attempting to rescue as much data as possible
`FTK Imager`	A GUI-based tool for creating forensic images, widely used for its ease of use and comprehensive features
`Guymager`	A GUI-based forensic imaging tool that supports various image formats and provides detailed logs
`EWF tools (ewfacquire)`	Tools for creating and handling Expert Witness Format (EWF) images, often used in digital forensics

Imaging using dc3dd

Let’s execute the dc3dd command with the following parameters:

sudo dc3dd if=/dev/loop10 of=example1.img log=imaging_loop10.txt

The if option (input file), indicates the device we want to copy; in this case, /dev/loop10
The of option (output file) indicates where we want to write the disk bytes, in this case, a file named example1.img
The log options will save all the output into a file. In our example, imaging_loop10.txt

Command execution in progress,

Imaging completed.

From the output above, we can confirm that the operation seemed to be successful and that we created a file of the same size, as shown below.

Checking the Integrity of the created image

Integrity checking in digital forensics imaging is crucial for ensuring that the forensic copy of data is identical to the original. This process uses cryptographic hash functions, such as MD5, SHA-1, or SHA-256, to generate unique hash values for both the original and the copied data. By comparing these hash values, investigators can confirm that the evidence was not altered during the imaging process, maintaining its reliability and admissibility in legal proceedings.

Methods for integrity checking include using tools that automatically calculate and verify hashes during the imaging process. Tools like dc3dd generate and compare hash values in real-time, providing an added layer of assurance. Regular integrity checks throughout the investigation ensure that data remains unchanged, preserving the chain of custody.

Let’s list all block devices.

analyst@tryhackme:~$ sudo lsblk -l
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0  24.9M  1 loop /snap/amazon-ssm-agent/7628
loop1    7:1    0  25.2M  1 loop /snap/amazon-ssm-agent/7993
loop2    7:2    0 105.4M  1 loop /snap/core/16574
loop3    7:3    0 104.2M  1 loop /snap/core/17200
loop4    7:4    0  55.7M  1 loop /snap/core18/2812
loop5    7:5    0  55.7M  1 loop /snap/core18/2829
loop6    7:6    0  63.9M  1 loop /snap/core20/2105
loop7    7:7    0    64M  1 loop /snap/core20/2318
loop8    7:8    0  67.9M  1 loop /snap/lxd/22526
loop9    7:9    0  91.9M  1 loop /snap/lxd/24061
loop10   7:10   0   1.1G  0 loop 
xvda   202:0    0    40G  0 disk 
xvda1  202:1    0    40G  0 part /
xvdh   202:112  0     1G  0 disk

We can observe that the device is still listed in /dev/loop10. Let’s ensure our imaging process was successful. To do that, let’s calculate the MD5 hash of the image we created, example1.img, and let’s do the same for the device/dev/loop10. The results should match.

analyst@tryhackme:~$ sudo md5sum example1.img 
483ca14c7524b8667974a922662b87e8  example1.img
analyst@tryhackme:~$ sudo md5sum /dev/loop10
483ca14c7524b8667974a922662b87e8  /dev/loop10

As shown above, the calculated hash indeed matches, passing the integrity check for this image we created. Thus, we can confirm that the imaging process has been successful through hashing.

Other Types of Imaging

Remote Imaging	Involves creating an image over the network, allowing it to acquire data without physical access to the device.
USB Images	Creates an image of a USB drive’s contents.
Docker Images	While not strictly an image, it creates a snapshot of a Docker container’s filesystem and configuration.

Once we have an image, we can also verify that the image is working and can be used to inspect it; for that, we could mount the image to verify the process is complete correctly. Let’s go ahead and mount the image we created, example1.img.

As we observed before, our disk assigned to the loop interface loop10 is not mounted as the command df displays.

analyst@tryhackme:~$  df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        39G  8.2G   31G  22% /
devtmpfs        973M     0  973M   0% /dev
tmpfs           981M     0  981M   0% /dev/shm
tmpfs           197M  1.2M  195M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           981M     0  981M   0% /sys/fs/cgroup
/dev/loop0       25M   25M     0 100% /snap/amazon-ssm-agent/7628
/dev/loop4       56M   56M     0 100% /snap/core18/2812
/dev/loop1       26M   26M     0 100% /snap/amazon-ssm-agent/7993
/dev/loop6       64M   64M     0 100% /snap/core20/2105
/dev/loop2      106M  106M     0 100% /snap/core/16574
/dev/loop7       64M   64M     0 100% /snap/core20/2318
/dev/loop3      105M  105M     0 100% /snap/core/17200
/dev/loop5       56M   56M     0 100% /snap/core18/2829
/dev/loop8       68M   68M     0 100% /snap/lxd/22526
/dev/loop9       92M   92M     0 100% /snap/lxd/24061
tmpfs           197M     0  197M   0% /run/user/1000
tmpfs           197M  8.0K  197M   1% /run/user/114
tmpfs           197M  4.0K  197M   1% /run/user/1001

Let’s mount it using the mount command

First, create a mount point directory /mnt/example1 with the command sudo mkdir -p /mnt/example1
Then, use the command sudo mount -o loop example1.img /mnt/example1 to mount the image
After that, we can verify by exploring the mount point we created using the ls command.

analyst@tryhackme:~$ sudo mkdir -p /mnt/example1
analyst@tryhackme:~$ sudo mount -o loop example1.img /mnt/example1
analyst@tryhackme:~$ ls /mnt/example1/
dir01  dir03  dir05  dir07  dir09  dir11  dir13  dir15  dir17  dir19  dir21  dir23  dir25
dir02  dir04  dir06  dir08  dir10  dir12  dir14  dir16  dir18  dir20  dir22  dir24  lost+found

The contents of the drive is visible. Now, we have a full copy of the compromised disk and we can continue the investigation with it.

Series NavigationIncident Response >>