Forensics Challenge Day Three: Carving & Imaging

We’re back with Digital Forensics! I was quite sick throughout last week, not able to intensify my studies - yet now, here we are! Let’s get in, shall we? There are exciting topics ahead of us!

Partitioning, Layouts & Lost Volumes — Deep Disk Structures in Forensics

When you’re diving into a disk image, you need to start with a solid foundation: how is the disk laid out? Before we even get to files or metadata, we have to answer: Where are the volumes? What partitioning method is in use? Is anything missing or deleted?

MBR vs GPT – Who Rules the Disk?

Think of a hard drive like a parking lot. To make it useful, we need to draw lanes and assign spots — that’s what partitioning does.

There are two main ways to do that:

While MBR is still common on older systems and removable drives, most modern systems (especially UEFI-based) use GPT.

Slight Side-Quest | UEFI vs BIOS: What’s the Difference?

Before we go any deeper into partition schemes, we need to briefly visit a legendary fork in the road that impacts everything about disk layout:

➡️ UEFI vs BIOS

This isn’t just tech trivia — knowing the difference helps you understand why some disks use MBR while others use GPT, and even affects boot forensics or bootkit malware detection.

👴 BIOS: The OG Boot Manager

BIOS (Basic Input/Output System) is the grandparent of boot firmware. It dates back to the early days of PCs (1981!) and does a very specific job:

It initializes the hardware and hands control to the OS — usually via the first sector of the disk, aka the MBR.

BIOS Boot Process (Simplified):

1. CPU powers on and executes BIOS code from motherboard.
2. BIOS performs hardware checks (POST).
3. It reads the first 512 bytes of the primary disk (MBR).
4. Finds a bootloader there (e.g., GRUB).
5. That bootloader loads the OS.

⛔ Limitations:

• Supports disks only up to 2TB
• Can only boot from MBR-style disks
• No graphical interface, no mouse, no security features

BIOS systems almost always use MBR — meaning if you find such a disk, you know it likely came from an older or simpler system (think old laptops, VMs, embedded devices).

UEFI: BIOS on Steroids

UEFI (Unified Extensible Firmware Interface) is the modern replacement for BIOS. It’s smarter, more flexible, and has better security.

UEFI can:

• Boot from disks larger than 2TB
• Support GPT partitioning
• Launch bootloaders from a dedicated FAT32 partition
• Offer a GUI interface with mouse + keyboard support
• Validate firmware and OS components with Secure Boot

UEFI Boot Process:

1. UEFI firmware loads from motherboard.
2. It reads the EFI System Partition (ESP) — a small FAT32 volume.
3. Finds a bootloader binary (e.g., bootx64.efi).
4. Bootloader starts the OS.

The EFI Partition is usually 100–500 MB and contains files like:

EFI/
 ├── Boot/
 │    └── bootx64.efi
 └── Microsoft/
      └── Boot/

UEFI boots .efi binaries, not MBR code. These live on a visible volume you can investigate directly!

BIOS vs UEFI — Why It Matters in Forensics

🔍 In practice:

• If you see a GPT disk, you’re likely dealing with UEFI.
• If you’re analyzing a disk and find an EFI folder, bootx64.efi, or similar, you’re definitely in UEFI territory.
• BIOS disks may hide bootloaders in the MBR — you’ll need raw sector tools (dd, hexedit) to analyze those.

🎯 TL;DR: Think Like a Forensic Examiner

Partition Table Forensics – Do We Care?

Here’s the kicker: partition tables usually don’t hold juicy evidence.

But they do matter when:

• The table is corrupted or missing (accidental or malicious)
• You’re doing volume recovery
• You’re identifying hidden or deleted volumes

In those cases, tools like sigfind and mmls from sleuth kit help you reconstruct lost partitions.

Let’s do just that.

Case Study: Finding Lost Volumes with sigfind + mmls

We’ll use the test image from the Digital Forensic Tool Testing (DFTT) project: 👉 DFTT 10 - NTFS Auto-Detect

Installation

After we downloaded it , we can then:

unzip 10b-ntfs-autodetect.zip
....
ls

10b-ntfs-autodetect.zip  10-ntfs-autodetect 

sigfind Analysis

First, we run sigfind to look for MBR partition table signatures:

cd 10-ntfs-autodetect/

sigfind -t dospart 10-ntfs-disk.dd

What does this do?

• The dospart template looks for the 0x55AA signature — this is the magic number found at the end of every MBR partition sector.
• It scans every 512-byte block for this value.

Output:

Block size: 512  Offset: 510  Signature: 55AA
Block: 0 (-)
Block: 63 (+63)
Block: 96389 (+96326)
Block: 96390 (+1)
error reading bytes 192784

Note: The error reading bytes message simply means sigfind reached the end of the image — this isn’t a failure, just the tool hitting EOF (end of file).

📌 Interpretation:

Note: These are sector offsets, not byte offsets. Multiply by 512 to get byte values if needed.
Example: Sector \(63 \times 512 = 32,256\) bytes; this is the exact offset on disk where Volume 1 begins.

🧮 Cross-check with mmls:

mmls 10-ntfs-disk.dd

Output:

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

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000000062   0000000063   Unallocated
002:  000:000   0000000063   0000096389   0000096327   NTFS / exFAT (0x07)
003:  000:001   0000096390   0000192779   0000096390   NTFS / exFAT (0x07)
004:  -------   0000192780   0000192783   0000000004   Unallocated

Why compare both tools?

• sigfind shows raw byte-level evidence of partition headers.
• mmls interprets the partition table if it exists and is readable.

In this case, they match perfectly. This is great for verifying deleted partitions, spoofed layouts, or volume tampering.

If sigfind finds signatures but mmls shows no volumes, the partition table may be corrupted. This combo is powerful for detecting hidden or deleted partitions.

What About Other Systems?

The Sleuth Kit also supports these lesser-known layouts:

Not covered here — but if you stumble across them in a CTF or case, Sleuth Kit can help.

Bonus Tool: TestDisk to the Rescue

When the partition table is gone or tampered with, TestDisk is your friend.

It works on:

• Raw disk images
• E01 (Expert Witness) images

To install it on Ubuntu:

sudo apt install testdisk

You can then run:

testdisk 10-ntfs-disk.dd

It walks you through interactive recovery of partitions - perfect for educational cases and live investigations alike.

RAID: One Disk Is Never Enough

Let’s step into a special case: RAID (Redundant Array of Inexpensive Disks).

Think of RAID like combining multiple physical drives into one logical structure. Like Voltron — but with hard drives.

Here are the most relevant levels:

Nested RAID (like RAID 10, 50) combine features of these levels.

❌ Sleuth Kit Can’t Help Here

Sleuth Kit does not support RAID. That’s where tools like:

• raid_guess.py (from PyFLAG suite )
• Original RAID controller hardware
• Deep vendor knowledge

…come in handy.

Reconstructing RAID without knowing the original config is like putting together shredded paper — blindfolded.

The book goes on to talk about special containers a bit - we’ll skip that for now, as it is not relevant to my exam, though it might be interesting later.

Carving in Forensics

“When all else fails… we carve.” - Every forensic examiner ever

Carving is your last resort while also being a powerful strategy. When file systems fail you, names are lost, and metadata is gone, carving goes straight for the data itself.

What is Carving, Really?

Imagine you’ve got a shredded document and no folder, label, or metadata to help you.

Carving is trying to rebuild files by identifying the beginning and end of recognizable formats - like JPEGs, PDFs, or DOCX — and cutting them out of the raw data stream.

That’s exactly what we do in digital forensics:

• Search the raw binary stream for file headers/ magic bytes (e.g., FFD8 for JPEG)
• Try to find the footer (e.g., FFD9 for JPEG)
• Save everything in between to a new file

When do you Carve?

You’ll reach for carving when:

• Files were deleted and not linked in metadata anymore
• File system structures (like inodes or MFTs) are damaged
• You only have unallocated space or a memory dump
• You want to recover lost evidence

Tools of the Carving Trade

Let’s introduce the cast of characters, from “basic but powerful” to “next-level”.

Try this First: hachoir-subfile

Think of this tool as a smart file spotter - it scans binary data and tells you, “Hey! This looks like a DOCX!” But it won’t carve it out itself.

Use Cases:

• You want to identify possible files before committing to a full carve
• Reduces false positives

We’ll return to this when we talk about file format forensics in depth, for now if you’re interested, you can check it out here

Carving with Foremost

Let’s go full carving now.

Foremost is a classic carving tool built for real cases. It’s simple, effective and supports:

• JPEGs, PNGs
• ZIP, DOC, PDF and maany more

It works by scanning for known headers/footers and optionally using internal format knowledge.

Installing Foremost

sudo apt install foremost

Or compile from source here

A great choice of datasets

The CFReDS (Computer Forensic Reference Data Sets) from NIST (also) provides curated forensic datasets, including a File Carving collection. These are ideal for training and exam prep

The data set we’ll use is here , while you can find many more very interesting ones in the general overview . Our dataset leads us to an overview , where i chose L0_Documents.dd. It focuses on document files, it’s non-fragmented and perfect to demonstrate foremost.

Foremost Carving Lab

Unpacking .bz2 Files

bunzip2 L0_Documents.dd.bz2

bunzip2 decompresses .bz2 files, the result’ll be L0_Documents.dd.

Foremost Analysis

foremost -v -i L0_Documents.dd -o output_documents

Discover more flags with man foremost if you want something specific! Get used to man!

1
2
3

ls output_documents
 
audit.txt  docx  jpg  pdf  png  pptx  xlsx

Exploring Foremost Features

-c foremost.conf - Custom File Carving Rules

Foremost uses a config file to define how it recognizes file headers/footers. You can modify it to:

• Enable or disable formats (e.g., only carve PDFs or DOCXs)
• Add support for non-standard or rare file types (e.g., SQLite, SQLite WAL, raw executables)

cp /etc/foremost.conf .
nano foremost.conf

you’ll find sections like:

#---------------------------------------------------------------------  
# MICROSOFT OFFICE 
#---------------------------------------------------------------------  
#
# Word documents
#       (NOTE THIS FORMAT HAS A BUILTIN EXTRACTION FUNCTION)
#       doc     y       12500000  \xd0\xcf\x11\xe0\xa1\xb1
#
# Outlook files
#       pst     y       400000000 \x21\x42\x4e\xa5\x6f\xb5\xa6
#       ost     y       400000000 \x21\x42\x44\x4e

...

#---------------------------------------------------------------------  
# SOUND FILES
#---------------------------------------------------------------------  
#       (NOTE THIS FORMAT HAS A BUILTIN EXTRACTION FUNCTION)
#       wav     y       200000  RIFF????WAVE
#
# Real Audio Files
#       ra      y       1000000 \x2e\x72\x61\xfd
#       ra      y       1000000 .RMF


...

#---------------------------------------------------------------------  
# WINDOWS REGISTRY FILES
#---------------------------------------------------------------------  
# 
# Windows NT registry
#       dat     y       4000000 regf
# Windows 95 registry
#       dat     y       4000000 CREG
#
#       lnk     y       5000    \x4C\x00\x00\x00\x01\x14\x02\x00\x00\x00\x00\x00\xC0\x00\x00
#       chm     y       100000  \x49\x54\x53\x46\x03\x00\x00\x00\x60\x00\x00\x00\x01\x00\x00
#       cookie  n       4096    id=
#       rdp     y       4096    \xFF\xFE\x73\x00\x63\x00\x72\x00\x65\x00\x65\x00\x6E\x00\x20\x00\x6D

...

Change around y to n to disable/ n to y to enable, or add your own custom format if you have header/footer data.

-a - Aggressive Mode

foremost -a -v -i L0_Documents.dd -o output_aggressive

This skips some file validation and dumps everything matching a header, even if the footer is missing or malformed. Great for fragmented images or when data is partially corrupted.

This can lead to many false positives - use only if your evidence is degraded.

-q - Quick Mode

foremost -q -v -i L0_Documents.dd -o output_quick

Only scans on 512-byte boundaries (sector-aligned). Very fast, great for large images.

Less accurate, but useful in triage or live analysis.

Good to know - the Output Audit File

Inside your output_documents/audit.txt, you’ll find a summary like:

pdf: 3
docx: 5
xlsx: 1
pptx: 2

Use this for:

• Quick report summaries
• Evidence logging
• Comparison between tools (e.g., vs Scalpel or PhotoRec)

Summary

Introducing Scalpel - Foremost’s Mutated Cousin

Now let’s bring in Scalpel, the tool born from Foremost’s DNA; rebuilt for performance, control, and modern formats.

Scalpel is a fork from Foremost version 0.69 and completely reworked.

Scalpel vs. Foremost

Scalpel Setup

sudo apt install scalpel

sudo nano /etc/scalpel/scalpel.conf

Uncomment what you want to carve - by default, all/ almost all is disabled, you must enable manually and singularly.

Running Scalpel

scalpel -c scalpel.conf -o output_scalpel L0_Documents.dd

This command presumes you copied your scalpel.conf for a custom version:

1
2
3

cp /etc/scalpel/scalpel.conf .
nano scalpel.conf
# Editing what you want

Strengths of Scalpel

• Handles large images faster via multi-threaded carving
• Can carve embedded or partial files more reliably
• Gives better performance on fragmented datasets

Carving Recap

In real-world forensic investigations, you often don’t get nice directory trees and intact metadata. Files are deleted, renamed, fragmented, hidden - and your filesystem layer tools come up empty.

That’s when carving becomes your data recovery lifeline.

Core Scenario: You’re tasked with finding deleted documents, but all metadata is gone — no inode, no filename, no path.

In such cases, your first move is to extract unallocated space using blkls, like so:

blkls suspect.img > unallocated.raw

Then, carve from that raw space:

foremost -i unallocated.raw -o carve_foremost/
# or
scalpel -c scalpel.conf -o carve_scalpel/ unallocated.raw

Why extract unallocated space first?

• It avoids fragmentation from active files
• Speeds up carving
• Maximizes recovery from deleted file remnants

Foremost vs. Scalpel – TL;DR For Exam Memory

Use Foremost first for fast triage. Use Scalpel for fine-grained, high-fidelity recovery.

EXIFTool Cheat Sheet: Metadata Forensics Mastery

ExifTool is a Swiss Army knife for file metadata. It supports thousands of formats (not just images) and reveals timestamps, authorship, camera info, software tags, and hidden data.

Installing EXIFTool

sudo apt install exiftool

When To Use It

• Inspect photo origin and history (camera, lens, software)
• Analyze modification and creation timestamps
• Detect image editing or manipulation
• Extract GPS coordinates and create maps
• View document metadata (PDFs, DOCX, etc.)
• Detect hidden thumbnails, author tags, and version trails

🛠️ Common Commands

Metadata Red Flags in Investigations

Example

exiftool output_documents/docx/00061210.docx 


ExifTool Version Number         : 13.10
File Name                       : 00061210.docx
Directory                       : output_documents/docx
File Size                       : 4.4 kB
File Modification Date/Time     : 2025:06:26 10:11:26-04:00
File Access Date/Time           : 2025:06:26 10:11:26-04:00
File Inode Change Date/Time     : 2025:06:26 10:11:26-04:00
File Permissions                : -rw-rw-r--
File Type                       : DOCX
File Type Extension             : docx
MIME Type                       : application/vnd.openxmlformats-officedocument.wordprocessingml.document
Zip Required Version            : 20
Zip Bit Flag                    : 0
Zip Compression                 : Deflated
Zip Modify Date                 : 2012:08:09 15:09:54
Zip CRC                         : 0xc381d398
Zip Compressed Size             : 290
Zip Uncompressed Size           : 783
Zip File Name                   : [Content_Types].xml
Creator                         : tester
Company                         : NIST
Meta Xmlns                      : http://schemas.apple.com/cocoa/2006/metadata
Meta Generator                  : CocoaOOXMLWriter/1138.47

What an amazing level of detail!

Forensic Imaging: Cloning the Digital Crime Scene

Imagine if a forensic team at a murder scene could replicate the crime scene and store it in a container. They could revisit it, test hypotheses, break stuff, and always go back to the original. Sounds wild?
That’s exactly what forensic imaging allows us to do, but for digital evidence.

What is a Forensic Image?

A forensic image is a sector-by-sector, byte-perfect copy of the original media: a hard drive, a USB stick, a virtual disk, or even RAM.

It includes:

• Active files (e.g., report.docx)
• Deleted files
• File system metadata (MFT, inodes, timestamps)
• Hidden partitions
• Slack space, unallocated space
• Boot sectors and volume headers

Nothing is left behind, not even remnants in unallocated blocks.

Why Image Instead of Investigating the Original?

Think of digital evidence like a biological sample: touching it can destroy it.

Reasons we image first:

• Non-destructive: We preserve the original and only work on the copy
• Repeatable: If our analysis goes wrong, we can re-image and start fresh
• Court-viable (!): Imaging provides chain-of-custody integrity
• Deep analysis: Only images allow us to recover deleted or hidden data

Deleted Doesn’t Mean Gone

Here’s where digital forensics gets juicy. Just because a file is “deleted” doesn’t mean it’s gone — it might be hiding in plain sight.

Let’s break down the four states of deleted files:

1. Deleted Files (Unlinked)

The file is deleted from the directory view, but:

• Its filename is gone
• Its metadata structure (inode or MFT entry) is marked as free
• Its data blocks still sit quietly on disk

These are most easily recoverable. File carving is usually not needed, tools like fls, icat, or extundelete can help.

2. Orphaned Files

These have lost the link between file name and metadata.

It’s like finding someone’s suitcase with no ID tag. You know what’s in it, but not who it belonged to.

Recovery is possible but harder: we find metadata (inode/MFT) and relink it to the data blocks — but not to a file name.

3. Unallocated Files

Everything is unlinked:

• No filename
• No metadata
• Just data blocks left in raw space

These can only be recovered by carving — using tools like foremost, scalpel, or photorec, which look for file headers and footers.

This is your “last chance” category. No metadata = no timestamps, no owner info.

4. Overwritten Files

Some or all of a deleted file’s blocks are reused by another file. The deeper the overwrite, the less you can recover.

Sometimes you recover a fragment — the start of a DOCX file, or the tail end of a ZIP.

Overwritten = the closest thing to digital death (but not always complete!)

File Slack: Where Ghosts Live

Let’s say you save a tiny text file containing just the letter a. Your OS saves it to disk:

• Filesystem allocates 1 full block (e.g., 4096 bytes)
• Only the first byte is from you (61 hex = a)

The rest? Not (necessarily) zeroed! It might be:

• Leftover junk from a previously deleted file
• Sensitive memory from another process
• Random past life data

This is file slack: unused space in an allocated block.

Slack space is often not zeroed, especially on HDDs or old file systems.

RAM Slack – Vintage Memory Spills

Older OSs (like MS-DOS) didn’t zero-fill sectors. Instead, they padded sectors with whatever was sitting in RAM nearby.

That means a file written by WordPerfect in 1993 might contain leftover RAM from earlier that day: including passwords, crypto keys, or sensitive docs.

This is RAM slack, potentially revealing, though less relevant in modern systems (thanks to null-padding and SSD TRIM).

Volume or Disk? Depends.

You’ve probably used:

dd if=/dev/sda of=image.dd bs=1M

(We’ll come to it again in a second if not) This is a physical disk image: all sectors, all partitions.

But sometimes, that’s not ideal:

• In RAID setups, reconstructing RAID from physical disks is difficult
• With SANs, you can’t access physical drives
• In volume-based analysis, you’re only interested in /dev/sda3

Solution: Image the volume, not the whole disk:

dd if=/dev/sda3 of=volume-only.dd bs=1M

Know your target: whole-disk vs single-partition images serve different purposes.

Summary Table on Forensic Imaging

dd Cheatsheet

dd stands for Disk Dump - a simple, yet powerful Unix tool for block-based copies of files and devices.

dd Basics

dd if=<INPUT_FILE> of=<OUTPUT_FILE> [options]

• if= | input file (e.g. /dev/sda, image.img)
• of= | output file (e.g. backup.img, /dev/sdb)

Now let’s get into the different commands.

A useful command you’ll need for calculating offsets and other info:

Analyzing the partition table

fdisk -l image.img

Commands

1. Create a drive image

dd if=/dev/sdX of=~/disk.img bs=4M status=progress

2. Extracting only the boot sector (first 512 bytes)

dd if=image.img of=bootsector.img bs=512 count=1

3. File system check (without mount)

dd if=image.img bs=512 skip=1054720 count=1 2>/dev/null | file -

4. Mounting a partition from .img

sudo mount -o loop,offset=540672000 image.img /mnt

then

df -T /mnt
# → shows e.g. ext4, xfs etc.

5. Destruction of a Disk

dd if=/dev/urandom of=/dev/sdX bs=1M status=progress

CARE: This WIPES everything!

Calculating the Offset

Offset (in bytes) = starting sector * sector size

So e.g. for GPT:

# Example: partition starts at sector 1054720
echo "$((1054720 * 512))"
# → 540672000 Bytes

Overview: dd parameters

Example: Analyze and mount GPT image

fdisk -l image.img
# e.g.: → shows: image.img3 begins at 1054720

# calculating offset
echo "$((1054720 * 512))"
# → 540672000

# Mount:
sudo mount -o loop,offset=540672000 image.img /mnt

# Show filesystem:
df -T /mnt

Forensic Imaging with dcfldd

dcfldd is an enhanced version of dd, developed by the U.S. DoD’s Digital Computer Forensics Lab (DCFL). It supports hashing, multiple outputs, split images, and direct verification — ideal for digital forensics.

Why Use dcfldd?

Basic Syntax

dcfldd if=<input> of=<output> [options]

dcfldd Command Cheat Sheet

1. Create Forensic Image with Hash & Log

sudo dcfldd if=/dev/sdX of=image.dd \
hash=sha256 hashlog=image.hash.txt statusinterval=1

This will:

• Create a byte-exact image
• Compute SHA256 hash
• Show progress every second
• Log results to image.hash.txt

2. Hash Only (No Imaging)

sudo dcfldd if=/dev/sdX hash=sha256 hashlog=hashonly.txt

Just calculates and logs the hash, without writing to an image.

3. Restore Image to Device

sudo dcfldd if=image.dd of=/dev/sdX hash=sha256 hashlog=restore_hash.txt

Overwrites target drive — use with extreme caution!

Advanced Options

Full Imaging Example

sudo dcfldd if=/dev/sdb of=/mnt/evidence/disk.dd \
hash=sha256 hashlog=/mnt/evidence/disk.hash.txt statusinterval=1

Sample hashlog Output

hashwindow: 0x0 hashfinal: 4681f1e6...a2bf1a

Compare with: sha256sum disk.dd

Warnings

• Always use with sudo or root.
• Target device must not be mounted.
• Be extremely careful with of=/dev/sdX — accidental overwrites are permanent.
• Verify source and target devices with:

lsblk
fdisk -l

Forensic Imaging with dc3dd

dc3dd is a forensics-optimized imaging tool based on dd, enhanced with hashing, logging, and progress reporting. It was developed by the U.S. DoD Cyber Crime Center (DC3).

Why Use dc3dd Instead of dd?

Basic Syntax

dc3dd if=<input> of=<output> [options]

dc3dd Command Cheat Sheet

1. Create Forensic Disk Image with Hash and Logs

sudo dc3dd if=/dev/sdX of=image.img hash=sha256 hlog=hashes.txt log=dc3dd.log progress=on

Creates a sector-exact image with:

• SHA256 hash of input and output
• Logs of hashing and disk activity
• Live progress view

2. Hash Only (No Imaging)

sudo dc3dd if=/dev/sdX hash=sha256 hlog=hash.txt

Just computes the hash of the source — no output image is written.

3. Restore Image to a Device

sudo dc3dd if=image.img of=/dev/sdX hash=sha256 hlog=hash.txt log=restore.log progress=on

Warning: Overwrites the destination disk completely.

Full Imaging Example

sudo dc3dd if=/dev/sdb of=/mnt/evidence/disk1.img \
hash=sha256 hlog=/mnt/evidence/disk1.hashes.txt \
log=/mnt/evidence/disk1.log progress=on

Sample hlog Output

dc3dd 7.2.641 started at 2025-05-04 14:55:02 +0200
hash=sha256
input file hash (sha256): a45f30...91ec
output file hash (sha256): a45f30...91ec

Hash equality confirms that input and output are identical.

Warnings

• Always run as sudo or root.
• Make sure target device is not mounted.
• Use lsblk or fdisk -l to correctly identify devices before running any commands.

That’s it folks! The next sessions will be on the actual practice sheets we got in class. See you there!