Forensic Imaging of Storage Media

• Forensic Imaging of Storage Media
  • Write-Blocking Principles
    • Hardware Write Blockers
    • Software Write Blocking on Linux
  • Spinning Hard Drives (HDD)
    • Interfaces
    • Sector Sizes
    • Host Protected Area (HPA) and Device Configuration Overlay (DCO)
    • Bad Sector Handling
    • Degaussing
  • Solid State Drives (SSD)
    • TRIM
    • Garbage Collection
    • Wear Leveling
    • Over-Provisioning
    • Factory Access Mode
    • Self-Encrypting Drives (SED)
  • NVMe Drives
    • Physical Interfaces
    • Write-Blocking Challenges
    • Alternative: Boot-from-Alternate-Media
  • USB Drives and Flash Media
    • Write Blocking
    • Flash Translation Layer
    • Fake Capacity Drives
    • SD/microSD/CF Considerations
  • RAID Arrays
    • Imaging Strategy
    • RAID Level Implications
    • Reconstruction Parameters
    • Hardware RAID
    • Software RAID (Linux mdadm)
    • Reconstruction Tools
  • NAS (Network Attached Storage)
    • Network vs. Physical Acquisition
    • Proprietary Filesystems and RAID
    • Encryption
  • Optical Media (CD, DVD, Blu-ray)
    • Session and Track Structure
    • Forensic Differences by Media Type
    • File Systems
    • Disc Degradation
    • Imaging Optical Media
  • Imaging Formats
    • Raw / dd
    • E01 (EnCase Evidence File)
    • AFF4 (Advanced Forensic Format 4)
    • Format Comparison
  • Imaging Tools
    • Command-Line Tools
    • GUI Tools
    • Hashing
    • Verification Procedure
    • Partial / Targeted Imaging
  • Summary: Media-Specific Concerns
  • Further Reading

Forensic imaging is the process of creating a bit-for-bit copy of storage media for analysis. The copy must be verifiable (hash-matched), complete (including unallocated space), and created without altering the source. Different media types present different challenges to these requirements.

This page covers the imaging considerations specific to each major storage media type, write-blocking principles, imaging formats, and tools. For what to do with the image once you have it, see NTFS Analysis, File Systems, and File Carving.

Write-Blocking Principles

Before imaging any media, you must ensure no writes reach the evidence. Writes can come from the host operating system (auto-mounting, journal replay, Windows indexing) or from the media itself (SSD garbage collection). Different media types require different write-blocking strategies.

Hardware Write Blockers

Hardware write blockers sit physically between the host and the evidence drive, intercepting commands at the interface level. They allow read commands through and block all write, format, and erase commands.

The NIST Computer Forensics Tool Testing (CFTT) program publishes test results for write blockers, verifying that no writes reach the protected drive, all sectors are readable, and drive identification data passes through accurately. Always use CFTT-tested devices when possible.

Software Write Blocking on Linux

Linux can function as a forensic platform with proper configuration. Three layers of protection, in order of increasing safety:

1. Block device read-only (strongest):

blockdev --setro /dev/sdb

This sets the entire block device read-only at the kernel level. Target the parent device (/dev/sdb), not individual partitions. Any write attempt to this device – from any source, including filesystem drivers – is rejected by the kernel.

2. Mount options (necessary but not sufficient alone):

Why ro alone is insufficient: mounting a filesystem read-only prevents userspace writes, but the kernel’s filesystem driver may still write to the block device. Specifically:

• ext3/ext4 replays the journal on mount unless noload is specified
• XFS performs log recovery unless norecovery is specified
• NTFS replays the log file unless norecover is specified
• Some drivers update superblock metadata (mount count, last mount time) even on ro mounts

3. udev rules (automatic protection):

ACTION=="add", SUBSYSTEM=="block", ATTRS{removable}=="1", RUN{program}="/sbin/blockdev --setro %N"

This rule automatically sets any newly connected removable block device to read-only. Useful as a safety net, but should not replace deliberate write-blocking of specific evidence devices.

4. Kernel-level enforcement:

The msuhanov/Linux-write-blocker kernel patch adds read-only enforcement at the block layer, catching writes that bypass both mount options and blockdev. This is the most thorough software approach.

Best practice: use blockdev --setro on the device before any mount attempt, and always use the appropriate noload/norecovery/norecover option when mounting. For court-admissible work, prefer hardware write blockers.

Spinning Hard Drives (HDD)

Spinning hard drives are the simplest media to image forensically. The data is passive – platters hold magnetic charges that do not change without external writes. Power off the drive and it remains static indefinitely.

Interfaces

Legacy IDE drives require a PATA-capable write blocker (e.g., Tableau T5-PATA) or an IDE-to-SATA adapter bridge. Ensure the adapter does not introduce write operations.

Sector Sizes

Traditional drives use 512-byte sectors. Advanced Format (AF) drives use 4,096-byte (4K) physical sectors, often with 512-byte emulation (512e). Imaging tools must match the physical sector size to avoid incomplete capture of the final partial sector.

# Check physical and logical sector size
hdparm -I /dev/sda | grep -i "sector size"
blockdev --getpbsz /dev/sda
blockdev --getss /dev/sda

Host Protected Area (HPA) and Device Configuration Overlay (DCO)

These are ATA features that hide sectors from the operating system and standard tools. They can be used legitimately (recovery partitions, drive feature restrictions) or deliberately (hiding data from investigators).

HPA (ATA-4): reserves sectors at the end of the drive that the BIOS and OS cannot see. The drive reports a smaller capacity than it actually has.

DCO (ATA-6): sits above HPA and can further restrict reported capacity, disable SATA features, or mask transfer modes. A DCO can also hide the existence of an HPA.

Detection:

# Detect HPA: compare reported max vs actual
hdparm -N /dev/sda
# Output: 586070255/586072368 means HPA is hiding 2,113 sectors

# Detect DCO: shows actual max LBA and restricted features
hdparm --dco-identify /dev/sda

If HPA or DCO is present, the hidden area must be imaged. Tools such as Atola Insight Forensic and the Tableau TD1 Forensic Duplicator can detect and temporarily lift HPA/DCO, image the full drive, and restore the original configuration. On Linux, hdparm -N p[max_sectors] /dev/sdc permanently removes the HPA (document this action – it modifies the drive).

Forensic significance: any drive presented as evidence should be checked for HPA and DCO. Their presence may indicate an attempt to hide data, or may simply reflect a manufacturer’s recovery partition. Either way, the hidden area must be captured and examined.

Bad Sector Handling

Bad sectors are physical areas of the platter that cannot be reliably read. Imaging tools handle them differently:

• dc3dd: configurable error handling with retry counts and padding
• Guymager: logs bad sectors and continues by default
• Atola Insight Forensic: retries with varying read parameters (head repositioning, spin-down/spin-up cycles) before marking sectors unreadable

Document all bad sectors in your imaging log. A cluster of bad sectors in a specific area may indicate physical damage, or it may indicate a failed attempt to overwrite specific data.

Degaussing

Degaussing exposes the platters to a strong magnetic field, permanently destroying all data including firmware and servo tracks. A degaussed drive is non-functional and cannot be verified or hashed. This is a destruction method. Its forensic relevance is in explaining why no data is recoverable from a drive that was expected to contain evidence.

Solid State Drives (SSD)

SSDs are fundamentally different from spinning drives in ways that directly undermine forensic assumptions. The most critical difference: an SSD is not passive. Its controller actively modifies stored data even when the host issues no write commands.

TRIM

When the operating system deletes a file, it can issue a TRIM command telling the SSD controller which logical block addresses (LBAs) are no longer in use. The controller then schedules those blocks for erasure. After TRIM, the affected LBAs return either zeros or undefined data, depending on the controller’s behavior.

Three TRIM behaviors exist:

Check a drive’s TRIM support:

hdparm -I /dev/sda | grep -i trim

Research has shown that with TRIM enabled, only up to ~27% of deleted data blocks may survive, varying significantly by controller manufacturer. Without TRIM, nearly all deleted data remains recoverable through normal imaging.

Garbage Collection

Garbage collection (GC) is an internal SSD controller process that reclaims blocks by consolidating valid data pages and erasing blocks containing only invalid (TRIMmed or overwritten) pages. GC runs autonomously on the controller’s firmware, independent of the host operating system.

The critical forensic problem: GC resumes the moment a drive is powered on, even behind a hardware write blocker. A write blocker prevents host-initiated writes but cannot prevent the controller’s internal firmware operations. Evidence can be destroyed simply by powering on an SSD.

This means:

• Time is the enemy – image SSDs as quickly as possible after seizure
• Minimize power-on time before imaging is complete
• Document whether the drive was powered on at seizure and for how long
• Consider whether the GC has had time to run (controllers vary in how aggressively they schedule GC)

Wear Leveling

The controller distributes writes across NAND cells to equalize wear. This means old copies of data may persist in remapped cells that are inaccessible through normal LBA addressing. The data is physically present on the NAND but the FTL no longer maps to it.

Cell types affect data persistence:

Over-Provisioning

SSDs reserve 5-15% of physical NAND capacity beyond the user-addressable LBA range. This area (over-provisioning or OP) is used for garbage collection working space and bad block replacement. Data migrated into OP during wear leveling or GC is inaccessible through standard interfaces.

Research has demonstrated that data – and potentially hidden malware – can exist in the OP area with no way to access it through the normal storage interface.

Factory Access Mode

The only method to access OP, remapped cells, and raw NAND data is through factory access mode – a controller-specific diagnostic interface. The procedure varies by controller family:

1. Short PCB service pins to block normal NAND access
2. Send OEM-specific activation commands to the controller
3. Upload microcode to controller RAM
4. Extract the flash translation table and raw NAND data

The primary tool is the ACELab PC-3000 SSD Suite (~$3,000+ hardware, requires training). No universal standard exists. Procedures differ by controller family (Silicon Motion, Phison, Marvell, Samsung, etc.).

Factory access mode is expensive and specialized, but it is the only way to perform a truly complete forensic acquisition of an SSD.

Self-Encrypting Drives (SED)

Many consumer and enterprise SSDs implement hardware AES encryption (TCG Opal standard). The data encryption key (DEK) is stored on the drive; all data written to NAND is encrypted transparently.

A 2019 IEEE S&P paper (“Self-encrypting deception”) found that some SED implementations stored the DEK unprotected, allowing key extraction without the user password. BitLocker in hardware-encryption mode delegated to the SSD’s Opal implementation, inheriting these weaknesses. Microsoft subsequently changed BitLocker defaults to use software encryption.

Forensic implication: if a drive uses hardware encryption and is powered off, the data is encrypted at rest. If the drive is powered on and unlocked (user has authenticated), the data is readable through the normal interface. Capture images while the drive is unlocked when possible.

NVMe Drives

NVMe drives communicate over PCIe rather than SATA. They share all the SSD concerns above (TRIM, garbage collection, wear leveling, over-provisioning, SED) with the additional challenge that traditional SATA write blockers are physically and logically incompatible.

Physical Interfaces

Write-Blocking Challenges

NVMe-specific hardware write blockers exist but introduce a bandwidth bottleneck. They bridge NVMe to USB, which limits throughput:

Real-world throughput through a USB write blocker tops out around 1 GB/s. Benchmarks from ElcomSoft (October 2024) imaging a Samsung 980 Pro 256 GB: FTK Imager reached 525 MB/s through a USB bridge; OSForensics achieved 1007 MB/s on USB 4.0. For a 4 TB NVMe drive at 500 MB/s, expect approximately 2.2 hours for a raw image.

Thermal throttling, pSLC cache exhaustion, and inadequate power delivery (battery vs. AC power) all degrade sustained imaging speeds further.

Alternative: Boot-from-Alternate-Media

Instead of using a USB write blocker, boot the host system from a forensic Linux live USB (Paladin, CAINE, Tsurugi), set the NVMe device to read-only via blockdev --setro /dev/nvme0n1, and image directly over the native PCIe bus at full speed.

This avoids the USB bottleneck but:

• Requires a validated software write-blocking configuration
• Carries the SSD garbage collection risk (the drive is powered on)
• May not be accepted in all jurisdictions as equivalent to hardware write blocking

Document your approach and justify it in your forensic report.

USB Drives and Flash Media

USB flash drives, SD cards, microSD cards, and CF cards all use NAND flash with a flash translation layer (FTL), but they are simpler than SSDs and generally more straightforward to image.

Write Blocking

Standard USB write blockers (CRU WiebeTech USB v3.1 WriteBlocker, Tableau T8-R2 Forensic USB Bridge) intercept USB mass storage commands and strip write operations. These are well-tested and widely accepted.

For SD/microSD/CF cards, use a card reader – the reader presents the card as a USB mass storage device, and the same USB write blocker applies.

Flash Translation Layer

USB flash drives use a simplified FTL compared to SSDs. Most lack sophisticated wear leveling or aggressive garbage collection. Deleted data typically persists in unmapped NAND pages until those pages are reused, making recovery more feasible than on SSDs.

However, the FTL still means that some physical NAND pages are inaccessible through the USB interface – data in remapped or reserved pages cannot be reached without chip-off analysis.

Fake Capacity Drives

Counterfeit USB drives reprogram the controller firmware to report a larger capacity than the physical NAND supports (e.g., 256 GB reported, 8 GB actual). Data written beyond the real capacity silently wraps or is lost.

Forensic implication: imaging a fake-capacity drive at its reported size produces a corrupt image with repeated or garbage data beyond the real boundary.

Detection tools:

If a drive fails capacity verification, image only the verified real capacity.

SD/microSD/CF Considerations

Same NAND + FTL principles apply. Key considerations:

• Ensure the card reader supports the full capacity and speed class of the card
• UHS-II microSD cards have a second row of pins that some readers ignore, potentially causing incomplete reads
• CF cards exist in PATA (CF Type I/II) and newer interfaces (CFast uses SATA, CFexpress uses PCIe) – match the reader to the card interface
• SD cards have a physical write-protect switch, but it is advisory – the host controller enforces it, not the card itself. Do not rely on it for forensic write blocking.

RAID Arrays

RAID adds a layer of complexity because the data you need is distributed across multiple physical drives. The imaging strategy depends on whether you have access to the RAID controller.

Imaging Strategy

Two approaches:

1. Image the logical array through the RAID controller: the controller presents a single reconstructed volume. Imaging this volume is equivalent to imaging a single drive. This is simpler but depends on a functioning controller.

2. Image individual member disks: remove each disk, image it independently through a write blocker. Reconstruct the array offline from the member images. This is more work but provides maximum evidence preservation – if the controller fails or metadata is corrupted, member images allow reconstruction.

Best practice: image both if feasible. Always image individual members at minimum, because the controller is a single point of failure for the logical approach.

RAID Level Implications

Reconstruction Parameters

Reconstructing a RAID from member disk images requires five parameters:

1. Disk order: which physical disk occupies which position in the array
2. RAID level: 0, 1, 5, 6, 10, etc.
3. Stripe/chunk size: the size of each data block distributed across members (commonly 64 KB, 128 KB, or 256 KB)
4. Start offset: where the RAID data begins on each member disk (skipping any metadata superblock)
5. Parity rotation scheme (RAID 5/6 only): left-symmetric, left-asymmetric, right-symmetric, or right-asymmetric

If any of these parameters are unknown, reconstruction becomes a trial-and-error process. Some tools automate this; others require manual experimentation.

Hardware RAID

Hardware RAID controllers (Dell PERC, HP Smart Array, LSI MegaRAID) store configuration metadata on the member disks and/or in controller NVRAM. The controller presents a single logical volume to the host.

Imaging through the controller: boot from forensic media, configure the controller to not modify the array, and image the logical volume as you would a single drive. This is the simplest approach when the controller is available and functioning.

Imaging members directly: remove each disk and image individually. Reconstruction tools can read the controller’s on-disk metadata to determine array parameters.

Software RAID (Linux mdadm)

Linux software RAID stores metadata in superblocks on each member disk. Superblock versions (0.90, 1.0, 1.1, 1.2) differ in where the superblock is located on the disk.

# Read the superblock to determine array parameters
mdadm --examine /dev/sda1
# Shows: UUID, RAID level, chunk size, member count, disk role

# Assemble the array read-only for imaging
mdadm --assemble --readonly /dev/md0 /dev/sda1 /dev/sdb1

Always use --readonly when assembling for forensic purposes.

Reconstruction Tools

NISTIR 7276 (“The Impact of RAID on Disk Imaging”) documents RAID imaging methodology and validation procedures.

NAS (Network Attached Storage)

NAS devices combine RAID arrays with proprietary firmware, often running embedded Linux. They present a file-level interface (SMB/NFS) to the network, which is insufficient for forensic imaging.

Network vs. Physical Acquisition

Network acquisition (imaging via SMB, NFS, or iSCSI) captures only the file-level view. Unallocated space, deleted files, filesystem metadata, and slack space are all inaccessible. This is a logical acquisition, not a forensic image.

Physical acquisition (pulling the drives and imaging each individually) captures everything, including all the data that network acquisition misses. Always pull drives and image individually when legally and physically possible.

iSCSI exception: if the NAS presents block-level iSCSI LUNs, these can be attached as block devices and imaged:

# Discover iSCSI targets
iscsiadm -m discovery -t sendtargets -p <NAS_IP>

# Login to target (read-only)
iscsiadm -m node -T <target_name> -p <NAS_IP> --login

# The LUN appears as /dev/sdX -- apply write blocking and image
blockdev --setro /dev/sdc
dc3dd if=/dev/sdc hof=nas_lun.raw hash=sha256 log=nas.log

This provides block-level access including unallocated space, but depends on network bandwidth and trust in the NAS firmware not to alter data during the session.

Proprietary Filesystems and RAID

Synology SHR is a proprietary wrapper around Linux mdadm that allows mixed-size drives. The underlying mdadm metadata is standard and can be read with mdadm --examine.

For QNAP ZFS-based NAS units:

# Import the ZFS pool read-only on a forensic workstation
zpool import -o readonly=on <pool_name>

Encryption

Important: Btrfs and ZFS copy-on-write semantics mean that old unencrypted data blocks may persist on disk even after encryption is enabled at a later date. Imaging the raw member disks may recover pre-encryption data.

Optical Media (CD, DVD, Blu-ray)

Optical media is passive and read-only (for pressed and write-once media), making it forensically straightforward in some respects. The primary challenges are multisession discs, disc degradation, and ensuring complete capture.

Session and Track Structure

Optical media organizes data into sessions, each containing one or more tracks. The Table of Contents (TOC) in the lead-in area of each session describes that session’s tracks.

Multisession discs contain multiple sessions written at different times. Standard OS drivers typically mount only the last session, making earlier sessions invisible. This is a significant forensic concern – an examiner using standard tools may miss data written in earlier sessions.

Forensic Differences by Media Type

For write-once media (CD-R, DVD-R), earlier sessions are physically present even if a later session’s TOC does not reference them. IsoBuster can enumerate and extract all sessions.

File Systems

Disc Degradation

Organic dye layers in recordable media degrade over time (“disc rot”). Lifespan varies dramatically:

• Phthalocyanine dye (gold/silver discs): estimated 100-200 years under ideal conditions
• Cyanine dye (blue/green discs): estimated 5-10 years
• Azo dye (dark blue discs): estimated 15-50 years

Environmental factors (light, heat, humidity) accelerate degradation. Always image optical media promptly – a disc that is readable today may not be next year.

Imaging Optical Media

Basic imaging:

dd if=/dev/sr0 of=disc_image.iso bs=2048

This captures the default session. It misses multisession data, subchannel data, and lead-in/lead-out areas.

Complete forensic capture: use IsoBuster, which:

• Enumerates all sessions in a tree structure
• Extracts data from hidden earlier sessions
• Captures subchannel data (particularly the Q subchannel, which contains disc metadata)
• Supports ISO 9660, Joliet, Rock Ridge, UDF, and HFS
• Can recover from read errors with configurable retry logic

Hidden data areas: lead-in and lead-out areas can contain data not accessible through file systems. Subchannel data can carry hidden information. A forensically complete image should capture raw sectors including subchannel data where possible.

FTK Imager can image optical media but provides less granularity for multisession and subchannel capture than IsoBuster.

Imaging Formats

Raw / dd

A bit-for-bit copy of the source media. No metadata, no compression, no embedded hashing.

• Pros: simple, universally compatible, no vendor lock-in
• Cons: no embedded hash or case metadata, file size equals source size
• Split raw: large images can be split into segments (.001, .002, etc.) to accommodate filesystem size limits or removable media

E01 (EnCase Evidence File)

The industry standard forensic image format. Compressed (zlib), segmented, with embedded metadata and hash verification.

• Stores: case metadata (examiner name, case number, description, media model/serial), MD5 and/or SHA-1 hash per data chunk, verification hash of the entire image
• Pros: compression reduces storage requirements, metadata makes the image self-documenting, widely accepted in court
• Cons: proprietary format (though libewf provides open-source read/write), compression adds CPU overhead during acquisition
• Supported by: EnCase, FTK, X-Ways, Autopsy, Guymager, ewfacquire, and virtually all forensic tools

AFF4 (Advanced Forensic Format 4)

An open-source, vendor-neutral format designed to address E01 limitations.

• Uses Snappy or LZ4 compression (~2x faster than E01’s zlib on encrypted/compressed data)
• ZIP-based container with RDF metadata
• Supports linear and sparse images
• AFF4-L variant designed for logical acquisitions
• Supported by: Evimetry, GRR, Rekall, with growing support in other tools

Format Comparison

Imaging Tools

Command-Line Tools

dd:

dd if=/dev/sda of=image.raw bs=4M conv=noerror,sync status=progress

Basic imaging. conv=noerror,sync skips bad sectors and pads with zeros. No built-in hashing, limited error handling, no logging.

dc3dd (DoD Cyber Crime Center fork of dd):

dc3dd if=/dev/sda hof=image.raw hash=sha256 log=image.log

Adds on-the-fly hashing, progress display, split output, and comprehensive error logging. Preferred over plain dd for forensic work.

ewfacquire (libewf):

ewfacquire -t evidence -c deflate:best /dev/sda

Creates E01 images on Linux/macOS from the command line.

GUI Tools

Hashing

Best practice: compute both MD5 and SHA-256 during acquisition. MD5 provides backward compatibility with existing databases and tools; SHA-256 provides cryptographic strength.

Verification Procedure

1. Compute a hash of the source media before imaging (if the tool supports it)
2. Create the image
3. Compute a hash of the image and compare to the source hash
4. Log: start and end time, source device serial number and model, image hash values, examiner name, tool version
5. Store the hash log separately from the image

E01 and AFF4 images embed verification hashes automatically. Raw images require separate hash files.

Partial / Targeted Imaging

When full imaging is impractical (multi-TB arrays, time constraints, scope limitations), alternatives include:

• Logical imaging: capture specific files and directories rather than the full volume. FTK Imager’s “Custom Content Image” and AFF4-L support this.
• Sector range imaging: use dd with skip and count to image specific sector ranges
• KAPE triage collection: collect specific forensic artifacts rather than the full disk (see Windows Investigation Guidelines for details)

Always document the scope limitation in your forensic report. A partial image cannot support conclusions about data that was not captured.

Summary: Media-Specific Concerns

Further Reading

• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
• NISTIR 7276: The Impact of RAID on Disk Imaging
• NIST CFTT Hardware Write Block test results
• ElcomSoft: Imaging Fast NVMe Drives (2024)
• ElcomSoft: Life After TRIM – Factory Access Mode for SSD Imaging
• msuhanov/Linux-write-blocker – kernel-level write blocking for Linux forensic platforms