9.2 Bit-Stream Disk Imaging, Physical vs. Logical vs. Targeted Acquisition Methodology

9.2 Bit-Stream Disk Imaging, Physical vs. Logical vs. Targeted Acquisition Methodology

Quick Answer: A bit-stream image (also called a forensic duplicate or bit-by-bit copy) is a complete, sector-level replication of a physical storage medium from Logical Block Address 0 (LBA 0) to its final addressable sector. Unlike a high-level file copy, a bit-stream image copies every allocated sector, unallocated cluster, file slack space, partition gap, volume boot record, and deleted file remnant. Forensic acquisition is categorized into Physical acquisition (entire disk including unallocated space and hidden partitions), Logical acquisition (only active file systems and directories), and Targeted/Sparse acquisition (specific triage artifacts collected into forensic containers like L01 or AD1).

---

The Science of Bit-Stream Imaging vs. File Copying

Novices often mistake a standard file copy (e.g., using Windows File Explorer, xcopy, or rsync) for forensic acquisition. In digital forensics, copying files is fundamentally flawed and legally indefensible when full media preservation is required.

PHYSICAL DRIVE LAYOUT:
+---------+--------------------+---------------+--------------------+---------+
| MBR/GPT | Partition 1 (OS)   | Partition Gap | Partition 2 (Data) | Unused  |
| (LBA 0) | [Allocated][Slack] | (Slack Space) | [Allocated][Slack] | Sectors |
+---------+--------------------+---------------+--------------------+---------+
                                      |                     |
======================================+=====================+==================
WHAT A FILE COPY CAPTURES:             |                     |
[BLOCKED]   [Allocated Files Only]       [IGNORED]       [Allocated Files]    [IGNORED]
(No MBR, No Unallocated Space, No Slack Space, Modifies Timestamps, Strips ADS)
===============================================================================
WHAT A BIT-STREAM IMAGE CAPTURES:
[======================= 100% BIT-FOR-BIT EXACT DUPLICATE =====================]
(LBA 0 to LBA max: Captures MBR, GPT, VBR, Allocated, Slack, Unallocated, Deleted)

Why File Copying Destroys Evidence

1. Destruction of Temporal Metadata: Accessing files through the operating system shell invokes file system drivers that automatically update the Last Access Timestamp ($STANDARD_INFORMATION and $FILE_NAME in NTFS). This alters the timeline of suspect activity.
2. Omission of Unallocated Space: In modern file systems (NTFS, FAT32, ext4, APFS), when a file is deleted, the operating system does not overwrite its physical data. Instead, it flips the allocation bit in the allocation bitmap (e.g., $Bitmap in NTFS) from 1 (allocated) to 0 (free/unallocated). Standard file copy utilities read only clusters marked as allocated, completely bypassing deleted files, malware staging archives, and residual contraband.
3. Omission of File Slack Space: Because data is allocated in discrete clusters (allocation units), files rarely end precisely on a cluster boundary. The residual space between the end of the file data and the end of the cluster is file slack, which can contain fragments of previously deleted files or memory dumps. File copies collect only the active file length, truncating slack space.
4. Stripping of Alternate Data Streams (ADS): On NTFS volumes, attackers frequently hide executables or configuration data in Alternate Data Streams (e.g., calc.exe:malware.dll). Standard file utilities drop secondary streams unless specialized flags are used.
5. Loss of Boot and Volume Structures: Master Boot Records (MBRs), GUID Partition Tables (GPTs), Volume Boot Records (VBRs), and unpartitioned disk gaps are ignored by file copy tools.

---

Structural Anatomy: Sectors, Clusters, and Slack Space

To master forensic acquisition, an investigator must understand the hierarchy of physical and logical disk geometry:

+-------------------------------------------------------------------------+
|                   FILE SLACK SPACE ARCHITECTURE                         |
+-------------------------------------------------------------------------+
|  Cluster Allocation Unit (e.g., 4096 Bytes = 8 Sectors of 512 Bytes)    |
|                                                                         |
|  Sector 1   Sector 2   Sector 3   Sector 4   Sector 5   Sector 6 ... 8  |
|  [================ File Data Ends Here ==============>]                 |
|  [------------- Active File Content -----------------]                  |
|                                    [-- RAM Slack ---]                   |
|                                    (End of data to    [-- Drive Slack --|
|                                     end of sector)    (Remaining unread |
|                                                       sectors in cluster)|
|  <--------------------------- FILE SLACK -----------------------------> |
+-------------------------------------------------------------------------+

Types of Slack Space

• RAM Slack: The space between the end of the file's data and the end of the specific sector in which the file terminates. In legacy operating systems (Windows 95/98/NT), the OS filled this partial sector with whatever residual data resided in the kernel memory buffer (which could include passwords, chat messages, or network packets). Modern operating systems zero-fill RAM slack, but the space remains inaccessible to normal users.
• Drive Slack (Cluster Slack): The remaining unread sectors within the assigned cluster following the sector containing the end of the file. If a 1,500-byte file is written to an NTFS volume with 4,096-byte clusters (8 sectors of 512 bytes):
  • File data occupies Sector 1, Sector 2, and 476 bytes of Sector 3.
  • Sector 3 contains 36 bytes of RAM slack (512 - 476 = 36 bytes).
  • Sectors 4, 5, 6, 7, and 8 (5 full sectors = 2,560 bytes) constitute drive slack.
  • These sectors hold whatever historical data previously occupied those physical disk sectors before the cluster was reallocated!
• Partition Slack (Volume Slack): Storage drives are partitioned along specific boundaries. When partitions are created, unallocated sectors frequently remain between the end of a partition and the beginning of the next partition or the physical end of the disk. Attackers can write directly to these raw sectors using low-level disk editors to bypass operating system detection.

---

Forensic Acquisition Types & Methodologies

Forensic acquisition is categorized based on evidentiary depth, investigative scope, and operational constraints:

When to Use Targeted (Sparse) Acquisition

While physical acquisition is the gold standard for criminal investigations, targeted acquisition is widely practiced in corporate enterprise incident response due to:

1. Storage Array Scale: An enterprise SAN or database server hosting 50 TB of data cannot be physically imaged during a brief incident response window.
2. Cloud Virtual Machines: Cloud platforms (AWS, Azure, GCP) often abstract physical hardware, requiring volume snapshots or targeted forensic collection.
3. Cross-Border Privacy Regulations (e.g., GDPR, CCPA): Corporate investigations in regulated jurisdictions legally forbid seizing entire personal drives containing non-work-related communications, employee health data, or personal photos. Targeted acquisition limits scope strictly to authorized directories.
4. Standard Containers: Targeted artifacts are packaged into cryptographically sealed forensic containers such as EnCase Logical Evidence Files (L01) or AccessData Logical Images (AD1), which maintain embedded hash integrity and case metadata.

---

Live vs. Dead (Post-Mortem) Acquisition Paradigms

[!IMPORTANT] If an examiner encounters a live workstation running Full-Disk Encryption (FDE) such as BitLocker or FileVault, powering off the machine (dead acquisition) without obtaining the decryption password or recovery key renders the physical disk image completely unusable ciphertext. In such cases, the examiner must perform live acquisition of the unlocked volume and dump physical RAM (which contains the Full Volume Encryption Key [FVEK]) before terminating power.

---

Command-Line Acquisition Tooling & Practical Syntax

1. GNU dd (Standard Bit-Stream Duplicator)

The standard Unix utility dd performs low-level raw block copying. However, dd lacks forensic hashing and terminates immediately upon encountering unreadable bad sectors unless specific conversion flags are supplied:

# Standard forensic dd invocation
# if = Input File/Device, of = Output Image File, bs = Block Size
# conv=noerror: Continues operation when physical read errors occur
# conv=sync: Pads failed unreadable blocks with NULL bytes to preserve LBA alignment
sudo dd if=/dev/sdb of=/evidence/suspect_drive.raw bs=64k conv=noerror,sync status=progress

2. dcfldd (DoD Computer Forensics Laboratory Enhanced dd)

Developed by the Defense Computer Forensics Laboratory (DCFL), dcfldd incorporates native cryptographic hashing, progress monitoring, image splitting, and piecewise hash logging:

# Physical acquisition with simultaneous dual-hashing (MD5 + SHA-256),
# 2048 MB volume splitting, and piecewise hashing every 100 MB
sudo dcfldd if=/dev/sdb of=/evidence/case901_sdb.dd. \
  split=2048M splitformat=aa \
  hash=md5,sha256 \
  md5log=/evidence/sdb_md5.log \
  sha256log=/evidence/sdb_sha256.log \
  hashwindow=100M hashlog=/evidence/sdb_piecemeal.log \
  conv=noerror,sync bs=4096 status=on

• split=2048M splitformat=aa: Automatically splits the output into 2 GB files named case901_sdb.dd.aa, case901_sdb.dd.ab, etc., preventing issues with FAT32 4 GB file size limitations on destination media.
• hashwindow=100M: Computes an independent hash for every 100 MB block of data, enabling forensic isolation of corrupted sectors.

3. dc3dd (DoD Cyber Crime Center Enhanced dd)

Developed by the Defense Cyber Crime Center (DC3), dc3dd provides improved error handling, verification passes, and bad sector logging:

# Physical acquisition with dc3dd including on-the-fly hashing and verification
sudo dc3dd if=/dev/sdb of=/evidence/case901_disk.raw \
  hash=sha256 log=/evidence/dc3dd_execution.log \
  badsectlog=/evidence/bad_sectors.log \
  conv=noerror,sync status=on

4. FTK Imager Command Line (ftkimager)

AccessData (Exterro) FTK Imager CLI is widely utilized in live Windows and Linux triage environments:

:: Capturing physical drive to an Expert Witness (E01) segmented image
ftkimager.exe \\.\PhysicalDrive1 E:\Evidence\Suspect_Drive.E01 --e01 ^
  --frag 2048M --compress 6 ^
  --case-number 2026-CHFI-902 --evidence-number Item-01 ^
  --description Suspect-Workstation-NVMe --examiner Lead-Specialist

---

Managing Read Errors and Bad Sectors During Acquisition

Storage drives seized from crime scenes frequently suffer from physical degradation, worn NAND cells, or damaged magnetic platter surfaces (bad sectors). When an imaging tool attempts to read an unreadable sector, the drive controller times out and issues an I/O error.

PHYSICAL READ ERROR HANDLING:

Physical Drive Sectors:
[ LBA 100 ] [ LBA 101 ] [ LBA 102 (BAD SECTOR) ] [ LBA 103 ] [ LBA 104 ]
                                    |
WITHOUT 'sync' FLAG (WRONG):        v
[ LBA 100 ] [ LBA 101 ]       [SKIPPED & DROPPED]   [ LBA 103 ] [ LBA 104 ]
Result in Image: LBA 103 is written to offset 102! ALL SUBSEQUENT SECTORS SHIFTED!
(File system corrupted, partitions fail to mount, MFT records broken)

WITH 'conv=noerror,sync' FLAG (CORRECT FORENSIC PROTOCOL):
[ LBA 100 ] [ LBA 101 ]  [ ZERO-BYTE PADDED (0x00) ]  [ LBA 103 ] [ LBA 104 ]
Result in Image: Exactly 512 null bytes inserted. Spatial alignment preserved!
(All subsequent LBAs remain at their exact physical sector offsets)

The Mandatory Role of conv=noerror,sync

1. conv=noerror: Instructs the imaging engine never to abort upon encountering a read error. Without this flag, dd halts immediately, leaving an incomplete image.
2. conv=sync: Instructs the engine to pad unreadable input blocks with null bytes (0x00) up to the block size (bs).
   • If an investigator specifies conv=noerror without sync, the utility skips the damaged sector without writing anything to the output file. Consequently, every subsequent byte in the image is shifted forward by 512 bytes. This misaligns cluster boundaries, breaks MFT record tables, and corrupts partition tables across the entire remaining image.

---

Real-World Case Scenario: The Encrypted Ransomware Server

The Incident

A healthcare network suffered an enterprise ransomware attack. Threat actors compromised domain credentials and deployed ransomware that encrypted critical file shares. The incident response team arrived while several backend servers were still powered on.

Forensic Decision-Making

1. Evaluating Acquisition Strategy: The primary database server utilized hardware-managed BitLocker full-disk encryption with a TPM protector, and the domain controller hosting the BitLocker recovery passwords was offline and corrupted. Powering off the server (dead acquisition) would leave the disk encrypted and completely inaccessible.
2. Executing Live Triage:
   • Examiners attached a write-blocked storage target over the local network.
   • Examiners extracted volatile physical RAM using winpmem.exe, capturing running processes, active C2 network sockets, and the unencrypted BitLocker Full Volume Encryption Key (FVEK).
   • Using FTK Imager CLI, examiners performed a live physical disk acquisition of the unlocked physical volume (\\.\PhysicalDrive0) to an E01 image container.
3. Carving and Recovery:
   • Because the live volume was acquired in its mounted state, forensic analysts recovered the ransomware binary from unallocated space before it could execute its self-deletion routine, extracted active C2 IP addresses from memory, and recovered the private decryption key from transient LSASS memory blocks, enabling full database recovery without paying the ransom.