Digital Forensics Challenge: Basics, Mounting & Analyzing Disk Images (Day 1)

Hello folks, welcome to a new challenge of mine! I have been, admittedly, quite lazy with digital forensics itself. I’ve spent a lot of time on my Forensic Log Tracker and other details of forensics, like file systems, but my actual uni course, which is mostly about computer forensics.. meh, i’ve been rather idle.

Today marks the first day of my Forensics Challenge, where i’ll work through Digital Forensics with Open Source Tools by Cory Altheide and Harlan Carvey, to make amends and get up to speed in my prep for the course exam. Are you ready?

Chapter 1: Not so interesting for us, but definitely worth a read

Chapter 1 proved very interesting to discover more about terminology, processes in criminal forensics, and especially about Open Source culture, which i’m a great fan of.

We’ll skip it’s content here, but feel free to give it a read, i’m sure most of you can take something out of it for themselves!

Chapter 2: Open Source Examination Platform

Preparing our Lab

Most of the open source tools discussed in this book come in source form, so often times, we’ll need to generate the executable software code by ourselves. Also, some tools might require a specific interpreter to run. This section will take good care of that. We’ll

• Build Software (converting source code into usable form)
• Installing Interpreters (source applications written in interpreted or scripting languages like Perl, Python or Ruby require prerequisites that these applications rely on.)
• Introduce ourselves to working with Image Files aswell as File Systems

In this series, we’ll be using Kali Linux as the host, although the book also covers Windows, so you can choose freely!

Extracting Software

Linux source code usually is distributed in compressed archives, or tarballs - fittingly we will use the tar command and it’s useful flags to extract.

Use the tar command with the right flags depending on the compression type:

GZipped tarballs (.tar.gz or .tgz):

  tar xzf filename.tar.gz

BZipped tarballs (.tar.bz2, .tbz, or .tbz2):

  tar xjf filename.tar.bz2

Add -v for verbose mode to see the files being extracted:

  tar xzvf filename.tar.gz

🛠️ Preparing to Build From Source

Before compiling or analyzing binaries from source, make sure your system has the necessary tools installed.

On Ubuntu or Debian-based systems, install the essential build tools with:

sudo apt-get update
sudo apt-get install build-essential

This includes tools like gcc, make, and libc headers — all commonly required when working with source code.

Tip: Run apt-get commands with sudo, since package installation requires administrative privileges - BUT ONLY for known, trusted packages from official Ubuntu/Debian repositories. DON’T do sudo apt-get install ./not-trustworthy-file.deb.

GNU Build System

For most of the future software in use here we’ll be preparing and executing builds using the GNU Autotools system - a process generally involving three commands, in order:

1. ./configure
2. make
3. (sudo) make install

configure

An included configure script will set in any configurable options that might exist.

<YOUR_USER>@<YOUR_SYSTEM>:~/path/to/code$ ./configure --help

will enable you to view optional features, flags, to tune the options to your liking.

Combine these option descriptions with provided README’s to get to know more about dependencies and other important details.
E.g., what if, using this method, you found out your new software relied on openssl?

Different Linux distributions will have libraries packaged under different namesn, but generally, you’ll be able to locate them via searching for the development library name using:

apt-cache search LIBRARY

This might again differ depending on your linux distribution, but for us now it’s apt-cache search openssl | grep dev

apt-cache search openssl | grep dev
android-libboringssl-dev - Google's internal fork of OpenSSL for the Android SDK - devel
apache2-ssl-dev - Apache HTTP Server (mod_ssl development headers)
golang-github-mendersoftware-openssl-dev - OpenSSL bindings for Go.
golang-github-youmark-pkcs8-dev - Go package to parse and convert private keys in PKCS#8 format (library)
libbellesip-dev - SIP stack from the Linphone team (development files)
libconduit-lwt-ocaml-dev - network connection establishment library for Lwt (dev)
libconduit-ocaml-dev - network connection establishment library for OCaml (dev)
libcurl4-openssl-dev - development files and documentation for libcurl (OpenSSL flavour)
...

Damn, that’s a lot…

Sidequest: Finally learning less

I’ve had enough of my professor flexing off his amazing terminal skills, of which less has been a great part - the speed and efficiency of actions is always marvelous watching him.

Let’s take a minute to grasp it’s basics here, as we need to search in the above results for a specific entry. I’ve used this article .

Okay, so less can display contents of a file or command outputs one page at a time - it has more advanced features than more? Ironic.

How to use less - the Basics

less [OPTIONS] filename

for files, or for commands:

<COMMAND> | less

Navigating with less

• Going forward (next page): f or Space bar
• Going back to previous page: b
• Moving down n lines: n f or n Space bar
• Moving up n lines: n b
• Scroll forward one line: Down arrow or enter
• Scroll backward one line: Up arrow
• Quitting and going back to the command line: q

When you’re at the file’s/ command output’s end, the string (END) will show.

Searching for a pattern with less

To search for a pattern, type / followed by the (Regex) pattern you want to search. Hitting Enter will search forward for matches, Or change the / for a ? to search backwards.

Less Options

less -N <FILE>

will show line numbers.

less -X <FILE>

will prevent the contents from getting cleared once you exit less.

less -X <FILE>

tells less to watch for changes, good for e.g. working with log files.

See this very well-crafted post for more commands

Using less to search in config

To apply what we’ve learned, let’s continue our earlier example.

apt-cache search openssl | grep dev | less

using the above commands came in very handy to comprehend the books search, discovering the libssl-dev and zlib1g-dev dependencies we then installed via sudo apt-get install zlib1g-dev libssl-dev.

This way, all is ready for the ./configure to be run. Mind that simple programns without third-party dependencies might not have such a script, but maybe a prebuilt makefile. Check their README’s, maybe you’ll also need to compile the code yourself.

A successful execution of the configure script will generate a makefile - this build script will be read by the make command.

make

Reading through the previously generated makefile, this command compiles and links each of the executable files and libraries making up the respective program.

This will take a lot of time and generate a lot of output.

After completion, we go along with:

sudo make install

That will copy the finished executables, libraries, docs, any materials and move them to their configured locations - generally, under /usr/local.

Other Build Systems than GNU Autotools

GNU Autotools is the most commonly used build system, yet two of the most popular alternatives are cmake and scons .

Scons is Python-based - a popular choice for software in.. well Python lol. Cmake is a really interesting one, it generates native build files for each target for it’s cross-platform clients: Makefiles for Unix(ish) systems, Visual Studio Solution files for Windows targets, …

Interpreters

As mentioned earlier, we’ll need to be able to execute programs written in interpreted/ scripting languages.

On Kali, all three, Ruby, Perl and Python are preinstaled, but if you want to check out installation for them , feel free to do so.

Now, the real fun begins. We’ll be getting into working with images and start out with the tools - let’s gooo.

Working with Images

What if one of the following fancy tools doesn’t work as expected? They could malfunction, possibly even contaminating our forensic material at hand.

To give us some safety here, we need to be able to work with image files natively - using “native system functionality”, as the book calls it.

⚠Warning: Automounting of Volumes on Ubuntu

One of the key reasons forensic analysts prefer Linux is the level of control it offers — especially over things like mounting drives. But as popular distributions like Ubuntu become more user-friendly, they adopt behaviors that can be risky in forensic scenarios.

What’s the issue?

By default, Ubuntu will detect and automatically mount external storage devices (USBs, hard drives, etc.) — just like Windows. This means that as soon as you plug in a drive, it’s mounted and potentially written to by the OS (e.g., indexing, timestamps).

For forensic work, that’s a big problem — it violates the principle of non-intrusiveness, possibly modifying evidence.

🐉 Kali Linux: Better For Forensics?

In contrast, Kali Linux does not automount drives by default, making it more suitable for forensic handling out of the box. You’ll usually have to mount devices manually (we’ll come to that in a minute).

This manual process is ideal — it gives you the chance to:

• Attach the disk as read-only
• Decide whether to use a hardware write blocker
• Control exactly what’s being accessed and logged

Best Practice for working with Images

If you’re using Ubuntu for forensics:

• Disable automount behavior, or
• Use a live environment like Kali or Tsurugi Linux
• Always pair with a hardware write blocker when handling original evidence

Perfect — this is an essential forensics workflow, and your audience will really appreciate a clear, example-driven section that explains not just the commands, but why and how they work, especially with disk images.

Here’s a polished, blog-ready section you can plug directly into your post — focused on deep understanding, safe usage, and practical application.

Mounting Raw Disk Images for Forensic Analysis (Using losetup + mmls)

In forensics, we often work with raw disk images (.img files) acquired from physical drives. To safely examine these images without altering them, we use a series of powerful Linux tools: losetup, mmls (from The Sleuth Kit), dd, and mount.

Let’s break it down.

What is a loop device?

A loop device lets Linux treat a file like a disk image, as if it were a physical block device. This is perfect for mounting disk images for forensic review.

Step 1: Analyze the Disk Image with mmls

First, we inspect the image’s partition table to find the exact offset (in sectors) where a partition starts.

mmls /mnt/forensic/testimg/testimg.img

What the output might look like:

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot    Start       End         Length      Description
00:     Meta        0           0           1 Primary Table (#0)
01:     -----       0           16064       16065 Unallocated
02:     00:00       16065       312496379   312480315 NTFS (0x07)

💡 We want to mount the NTFS partition, which starts at sector 16065.

Step 2: Calculate the byte offset

losetup needs the offset in bytes, not sectors. Multiply the sector offset by sector size (typically 512 bytes, as to be read above):

16065 * 512 = 8225280

Step 3: Create a read-only loop device using losetup

sudo losetup -r -o 8225280 /dev/loop0 /mnt/forensic/testimg/testimg.img

(The target folder structure is a mere example, you can mkdir -p create/your/own)

Explanation of flags:

• -r: read-only — protects the image from accidental modification.
• -o: offset in bytes — tells losetup where the desired partition starts.

You can see all losetup options with:

man losetup

Step 4: Verifying the Filesystem in the Loop Device

Before mounting anything, we want to be absolutely sure the data at the offset is a valid, recognizable filesystem — to avoid errors and confirm our math.

We use a combo of dd (low-level read) and file (magic-bytes detection):

sudo dd if=/dev/loop0 bs=512 count=1 | file -

What’s happening here?

• dd reads just the first 512 bytes from /dev/loop0, which represents the start of the partition.
• The result is piped into file, which checks the binary data against known file signatures.

Example output:

/dev/stdin: x86 boot sector, code offset 0x52, OEM-ID "NTFS", ...

This confirms that you’re at the start of an NTFS file system.

📚 Common dd Options (Quick Reference)

Example:

dd if=/dev/sdb of=disk.img bs=1M status=progress conv=noerror,sync

This creates a full disk image of /dev/sdb, reading in 1MB blocks, showing progress, and gracefully handling read errors.

Step 5: Mounting the Partition (Read-Only!)

Once you’ve confirmed there’s a valid filesystem, you can safely mount it to explore its contents.

mkdir -p /mnt/testimg
sudo mount -o ro /dev/loop0 /mnt/testimg/

mount Command Breakdown

Why -o ro?

• This is critical in forensics — it ensures that the mounted volume is not modified (no new access times, metadata changes, etc.)
• It helps preserve evidentiary integrity and supports chain-of-custody compliance

🛑 Never mount suspect evidence read/write unless you’re working on a copy.

Then list the contents:

ls /mnt/testimg/

Expected output might look like:

AUTOEXEC.BAT  Documents and Settings  Windows  pagefile.sys ...

If you see familiar Windows directories, you’ve successfully mounted the NTFS partition from the image 🎯

Pro Tips

To unmount when you’re done:

sudo umount /mnt/testimg
sudo losetup -d /dev/loop0

• For scripting: use losetup --show to capture the created loop device dynamically.
• Want to explore deeper without mounting? Use fls and icat from SleuthKit instead - we’ll come to them soon!

Summary Workflow

📚 Resources

• man losetup
• man mmls
• file command info
• TSK (The Sleuth Kit)

☕ Welcome to the Forge..

Before the real magic begins, for a moment consider supporting me in my endless pursuit of free educational content :D 🛠 Every coffee helps fuel more content like this — cheatsheets, walkthroughs, and more hacker-fueled documentation.

🔗 Visit: ko-fi.com/niklasheringer

Sidequest: Mounting Split Raw Images (Multi-Part .img Files)

When working in digital forensics, especially when exchanging disk images between teams or tools, you’ll often run into split raw images — a full disk image divided into multiple smaller chunks, typically around 2 GB each.

This format is commonly used to:

• Bypass filesystem limitations (e.g. FAT32’s 4GB file size cap)
• Simplify transfer over network or physical media
• Align with tooling that handles data in segments (e.g., some forensic suites)

Example of Split Raw Files:

disk.E01
disk.E02
...
OR
disk.img.001
disk.img.002
disk.img.003

These files don’t represent full, mountable disk images individually. You can’t losetup them directly because each segment contains only a portion of the full image.

❌ Why can’t we just mount them?

The Linux loop device requires a complete, linear image file. Trying to mount disk.img.001 will fail or produce corrupted results, since the partition table and file structure are incomplete.

🛠️ Solution: Combine with poorcase

To automate the reconstruction of split raw images, you can use poorcase , a Perl script by Richard Harman. It:

• Detects and orders split image segments
• Virtually reassembles them into a single image
• Creates a unified loopback mountable device without altering the original files

🔗 poorcase project page (archived)

💡 Alternative: You can manually concatenate with cat, but only if you are absolutely sure the segments are raw and in the correct order:

cat disk.img.001 disk.img.002 disk.img.003 > full_disk.img

Once reassembled, you can apply the usual mmls, losetup, and mount steps as with any raw image.

Summary

Let’s get on - the side missions are going crazy today hehe.

FUSE - “File Systems In User Space”

FUSE not only lets us interprete filesystems, but through various FUSE modules, interpreting volumes and containers, allowing for access to their contents, is all possible.

There are maany FUSE modeuls - everything from cloud-based file systems to encrypted local file systems.. to Wikipedia as a file system? You can read more about FUSE here

sudo apt-get install zfs-fuse python-fuse fuse-zip sshfs

will install us:

• ZFS-Fuse - a driver for Sun’s ZFS file system
• Python-Fuse - a python API for implementing FUSE file systems
• Fuse-Zip - a FUSE module presenting ZIP archives as file systems
• SSHFS - a FUSE module transparently presenting remote file systems as local over SSH (SFTP/SCP)

Sidequest: apt vs apt-get — What’s the Difference?

We’ve now seen commands like

sudo apt install package-name

or

sudo apt-get install package-name

But what’s the difference?

apt (modern, user-friendly frontend)

• Introduced as a newer, simplified interface for package management
• Combines common features of apt-get, apt-cache, etc.
• Cleaner output, progress bars, and safer defaults for interactive use

sudo apt install nmap
sudo apt update
sudo apt upgrade

Recommended for day-to-day use by users and sysadmins

⚙️ apt-get (lower-level backend tool)

• Older, more script-friendly tool used in automation
• Offers fine-grained control and stability in scripts or package handling logic

sudo apt-get install nmap
sudo apt-get update
sudo apt-get dist-upgrade

Recommended for scripts and legacy systems

📌 apt install vs apt-get install

TL;DR

Use apt for everyday use. Use apt-get if you’re scripting or need full control.

Both do the same thing — manage packages via APT, the Advanced Package Tool.

Mounting .E01 Forensic Images with ewfmount (Modern Tool)

In digital forensics, it’s common to encounter EWF (Expert Witness Format) disk images — typically split across .E01, .E02, etc. These contain not only the raw disk data, but also case metadata, examiner info, and built-in integrity checks.

To extract and mount these images safely, we now use ewfmount, which comes with the ewf-tools suite.

The book uses mount_ewf.py here, which is now outdated, replaced by the ewfmount functionality in the ewf-tools.

Installing ewf-tools on Kali Linux

sudo apt update
sudo apt install libewf-dev ewf-tools

Verify installation:

ewfmount --help

What is ewfmount?

• Mounts .E01 images as read-only raw disk files
• Uses FUSE
• Outputs a raw device-like file (e.g. ewf1) that you can interact with directly

Mount an EWF image

Let’s say you have WinXP2.E01 (example from the book):

mkdir ~/mount_points/ewf
ewfmount WinXP2.E01 ~/mount_points/ewf

This will create a virtual file at:

~/mount_points/ewf/ewf1

This ewf1 file acts just like a raw .img disk — ready for file, mmls, losetup, or mounting.

Workflow After Mounting

Once ewf1 is exposed, treat it like a raw image:

1. Check the image info:

ewfinfo WinXP2.E01

2. Inspect partition layout:

mmls ~/mount_points/ewf/ewf1

3. Calculate offset, then attach as a loop device:

sudo losetup -r -o 8225280 /dev/loop0 ~/mount_points/ewf/ewf1

4. Mount read-only:

sudo mkdir /mnt/ewf_disk
sudo mount -o ro /dev/loop0 /mnt/ewf_disk

Other ewf-tools

We’ll probably do a practical runthrough of this in a later session, currently there are too many tools to show each of them, as it sidetracks what i need to really learn for my uni course.

Absolutely — here’s a brief, blog-friendly section summarizing the context around AFF and its relevance today, so readers can decide if it’s worth diving into:

⚠️ AFF: Outdated, But Not Gone

The Advanced Forensic Format (AFF) was once a widely used open-source format for forensic imaging — but it’s now largely superseded by newer formats like:

• AFF4 – adds support for logical evidence, faster access, better metadata handling
• ZFF – simpler structure, faster processing, and modern design

Why AFF Is Rarely Used Today

• Modern tools prefer AFF4 or .E01
• ZFF offers better speed and simplicity
• Legacy only: AFF may still appear in older case files or forensic archives

TL;DR

Unless you’re working with legacy evidence or specific older tools, you likely don’t need to learn AFF in depth. Focus instead on AFF4, EWF (.E01), or raw image workflows.

XMount

While MountEWF (and also AFFuse) both present a “raw “dd” style image”, XMount is able to present a container’s contents as a VirtualBox or VMWare format disk image. It can on-the-fly convert via FUSE, making it extremely useful for a Linux-based examiner, wishing to boot a virtual instance of an imaged system.

XMount will redirect any writes to a cache file in a directory specified by the examiner.

Unfortunately, since 2021, XMount received no updates .. Maybe we’ll have to examine further here.

Yes! The uname command is exactly what’s being used here — it’s a standard Linux utility to display system information, especially kernel version info, which is important in forensic setups for checking compatibility, file system support, and module paths.

Here’s a mini info section you can use in your blog:

Understanding uname (Kernel Info)

The uname command lets you query basic system and kernel information — essential for locating kernel modules or checking compatibility.

Common Usage

uname -a

Sample output:

Linux ubuntu 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux

What does this show?

Why it’s useful in forensics:

You need the exact kernel version to:

• Browse file system modules in /lib/modules/<kernel>/kernel/fs/
• Check whether certain modules (like ntfs, xfs, etc.) are compiled in or loadable
• View available file system support with:

ls /lib/modules/$(uname -r)/kernel/fs/

That’s it for today, that was chapter 2. Tomorrow the real work here can begin after this introduction round.