Acquiring a physical drive
The first part of my FOR-240 work covered physical evidence acquisition. I connected a SATA SSD to the forensic workstation through a hardware write blocker, then acquired E01 images with FTK Imager and EnCase.
The write blocker protected the source device from normal operating-system writes. That boundary was supported by a simple evidence record containing the device model, serial number, physical condition, connection method, imaging tool, and output format.
Both tools calculated MD5 and SHA-1 values during acquisition. The submitted note compared the resulting image-container hashes, which differed because the E01 files were produced by different tools and at different times. For forensic verification, the important comparison is the hash of the acquired source data recorded by each imaging process, alongside the tool logs and segment metadata, rather than expecting two container files to be byte-for-byte identical.
This exercise established the order of work I continued using in later investigations:
- identify and photograph the device
- prevent writes to the source
- acquire into a recognised forensic format
- record tool and acquisition metadata
- verify the captured data
- analyse a working copy
Opening a BitLocker-protected image
A second exercise supplied a 250 MB NTFS image protected with BitLocker. I analysed it from Ubuntu 20.04 using Dislocker and ExifTool.
I first inspected the partition table and calculated the byte offset of the encrypted partition from its starting sector. Dislocker then exposed a decrypted volume file, which I mounted into a separate directory with read-only options.
Keeping the stages separate was useful:
- the original image remained unchanged
- the encrypted partition was addressed at the correct offset
- Dislocker produced the decrypted view
- the decrypted NTFS volume was mounted only for examination
The file system contained an IoT Devices directory with text, RTF, and image files related to a fictional plan targeting network-connected devices. I recorded file metadata with ExifTool and calculated MD5 and SHA-1 values for the examined files.
The evidence included device lists, a short targets document, and photographs of connected products. Creation and modification metadata placed several files in the same historical period. I used the names, contents, timestamps, and hashes together rather than relying on the directory title alone.
Testing The Sleuth Kit
The Sleuth Kit exercise did not proceed cleanly against the supplied E01 image because the tool could not determine its partition table. Instead of forcing an interpretation, I passed a physical test drive into the virtual machine, created a new image, and used that to validate the commands and workflow.
That failure belongs in the record. Forensic tools depend on image format support, intact partition metadata, correct offsets, and the way a virtualised device is presented. Changing to a controlled test image separated a tooling problem from the evidence under examination.
Reconstructing a Linux RAID set
The RAID exercise used two supplied raw images. I attached each image to a read-only loop device with partition scanning enabled, then inspected the devices and partitions with ls and fdisk.
mdadm rebuilt the array from the two loop devices using the supplied RAID level and chunk size. I checked /proc/mdstat to confirm the array state before examining /dev/md0.
The reconstructed partitions were mounted with forensic restrictions. The options documented in the lab included:
roto prevent writesnodevto ignore device filesnoloadto avoid replaying the file-system journalnoatimeto avoid updating access timestampsnosuidto prevent set-user-ID execution
These flags reduce avoidable changes and execution risk on the analysis host. They do not replace source verification or a write blocker, but they make the mounted working view less intrusive.
From acquisition to interpretation
The four labs covered different storage problems: a physical SSD, an encrypted NTFS volume, a tool that could not parse an image, and a multi-device Linux array. The common workflow was:
- preserve the source
- understand the container and partition layout
- make the minimum transformation needed for access
- mount or parse through a controlled view
- record hashes and metadata
- distinguish acquisition facts from investigative interpretation
The software versions and hash choices reflect an early 2021 teaching environment. Current work should use supported toolchains and modern hash algorithms such as SHA-256 alongside any format-required legacy values. The evidence-handling principles remain the same.