Digital Forensics Practice Exam Review

Data Abstraction and Physical Storage Architecture

Data Abstraction Layers: The architectural hierarchy of data organization within a system identifies specific responsibilities for each layer: * Physical Media Layer: The actual hardware (platters, flash cells) where bits are stored. * Host Bus Adapter (HBA) Protocol Layer: The interface (SATA, SCSI, NVMe) through which the host communicates with the storage device. * Block Device Layer: Provides a logical representation of the storage as a sequence of blocks. * Filesystem Layer: Directly responsible for organizing block storage into files, directories, and managing associated metadata such as timestamps ( $atime$ , $mtime$ , $ctime$ ) and permissions.
Sector Configurations (Advanced Format): * Native 4K ( $4Kn$ ): Characterized by having $4096\,bytes$ for both logical sectors and physical sectors. * $512e$ : Uses $4096\,byte$ physical sectors but emulates $512\,byte$ logical sectors for compatibility.
Solid-State Drive (SSD) Internals and Forensic Implications: * Flash Translation Layer (FTL): A critical controller component performing several functions: * Wear Leveling: Distributes write operations evenly across all flash cells to prevent premature failure of specific blocks. * Garbage Collection: Reclaims flash pages marked invalid by the host to maintain write performance. * Bad Block Management: Identifies failed cells and remaps the addressable space to spare cells. * Over-provisioning: Maintains a reserve of spare capacity for background operations (e.g., swapping blocks during wear leveling). * Forensic Significance of Over-provisioning: This area is inaccessible through standard host commands and may retain remnants of deleted data that were never subject to $TRIM$ erasure. * Logical vs. Physical Mapping: Modern SSD controllers implement proprietary wear-leveling algorithms that decouple Logical Block Addresses ( $LBAs$ ) from actual physical locations on the storage medium. The $SATA/SCSI$ interface does NOT expose physical memory cells in their true sequential order. * $TRIM$ Command: Instructs the device to flag specified logical blocks as no longer in use, allowing the controller to proactively erase them.
SMART (Self-Monitoring, Analysis, and Reporting Technology): Provides historical and diagnostic data, including: * Cumulative power-on hours and total power cycle counts. * Number of sectors reallocated due to read/write errors. * Evidence of recent $ATA\,SECURITY\,ERASE\,UNIT$ command execution. * Historical read/write error rates and temperature records.

Forensic Acquisition Tools and Methodologies

Standard Utility: $dd$ : * $conv=noerror$ : Instructs the utility to continue the copying process after a read error occurs rather than aborting. * $conv=noerror$ without $sync$ : If a read error occurs, the output image becomes shorter than the source because error blocks are skipped without being replaced, causing a misalignment of all subsequent data. * $conv=noerror,sync$ : Padds every input block with zeros when an error occurs, preserving the block alignment and total size of the image.
Enhanced Tool: $dc3dd$ : Provides capabilities beyond standard $dd$ , including: * Integrated hashing for multiple algorithms (e.g., $MD5$ , $SHA-1$ , $SHA-256$ , $SHA-512$ ). * Detailed activity logging with timestamps and specific error counts. * On-the-fly hash verification during the acquisition process. * Support for splitting output into multiple files of a designated size.
Recovery Tool: $GNU\,ddrescue$ : * Primary Use Case: Acquiring data from physically failing drives containing bad sectors. * Methodology: Uses a mapfile (or logfile) to track progress. A typical command sequence is $ddrescue\,-n\,/dev/sda\,case.dd\,case.map$ . * Retry Logic: If sectors remain failed (-$ symbol in the mapfile), the examiner should use ddrescue\,-d\,-r\,3\,/dev/sda\,case.dd\,case.map $to perform direct disc access and retry failed sectors three times.</li><li>Acquisition Standards and Integrity: * Minimum Hash Standard:$ SHA-256 $is currently recommended as the minimum cryptographic hash standard for new forensic acquisitions. * Pseudo-physical Acquisition: A term by Casey describing block-level imaging. It is "pseudo" because not all physical areas (such as reallocated sectors or Host Protected Areas ($ HPA $)) are accessible through the standard$ HBA $interface.</li></ul><h3 id="78264a98-8855-4c5b-a126-2abf98886bdf" data-toc-id="78264a98-8855-4c5b-a126-2abf98886bdf" collapsed="false" seolevelmigrated="true">Evidence Container Formats</h3><ul><li>Expert Witness Format ($ E01 $/$ EWF $): An industry-standard container that provides: * Built-in Compression: Reducing the storage requirements for the image. * Embedded Metadata: Stores examiner name, case number, and notes within the header. * Chunk-level Integrity: Employs$ CRC32 $checksums embedded within each compressed data chunk for fine-grained verification. * Automatic Splitting: Automatically handles the creation of sequentially numbered segments.</li></ul><h3 id="3fe98127-a223-4cdd-9979-bec0e8060cfe" data-toc-id="3fe98127-a223-4cdd-9979-bec0e8060cfe" collapsed="false" seolevelmigrated="true">Storage Partitioning and Logical Volumes</h3><ul><li>Master Boot Record ($ MBR $): * Size: Occupies the first$ 512\,byte $sector of a disk. * Partition Table: Reserved size of$ 64\,bytes $within the$ MBR $. * Type Codes: The code$ 0x83 $identifies a Linux native filesystem (e.g.,$ ext2 $,$ ext3 $,$ ext4 $). * Device Naming (Linux): Logical partitions (inside an extended partition) typically start numbering at$ /dev/sdb5 $, regardless of the number of primary partitions.</li><li>GUID Partition Table ($ GPT $): Part of the$ UEFI $specification, providing improvements over$ MBR $: * Removes the$ 2\,TiB $per-disk capacity ceiling. * Supports more than four primary partitions natively. * Includes a primary$ GPT $header at$ LBA\,1 $. * Features a redundant backup partition table at the physical end of the disk. * Uses$ CRC32 $checksums for the header and partition entry array.</li><li>Logical Volume Management ($ LVM $): Layers organized from lowest (physical) to highest (filesystem-ready): 1. Physical Volume ($ PV $): The raw disk partitions. 2. Volume Group ($ VG $): A pool of space from one or more$ PVs $. 3. Logical Volume ($ LV $): The virtual partition presented to the filesystem.</li><li>Linux RAID ($ md $): * RAID 1: Fault tolerance via mirroring (each disk is a complete copy). * RAID 5: Uses distributed parity; survives the loss of exactly one member disk. Minimum of three disks usually required. * Management: Metadata is stored in a superblock on each member disk; the tool$ mdadm $is used for reassembly.</li></ul><h3 id="ec1fed82-8e94-45a3-b793-439b76006033" data-toc-id="ec1fed82-8e94-45a3-b793-439b76006033" collapsed="false" seolevelmigrated="true">Data Discovery and Advanced Analysis Tools</h3><ul><li>$ bulk_extractor $: * Scanning Methodology: Reads the entire image as a flat byte stream, ignoring filesystem structures entirely. This allows it to find data in deleted regions and swap partitions. * Recursive Decompression: Capable of scanning content inside$ ZIP $,$ GZIP $, and$ BASE64 $containers. * Parallel Processing: Divides images into fixed-size pages. Default is$ 16\,MiB $pages with a$ 4\,MiB $overlap margin to ensure artifacts spanning a boundary are not missed. * Forensic Paths: A path like$ 2097152-ZIP-4096-BASE64-128 $means the artifact is at byte$ 128 $of a$ BASE64 $blob, which is at offset$ 4096 $within a$ ZIP $archive starting at image byte$ 2,097,152 $. * Stop Lists: Used to filter noise. A mechanical stop list suppresses features found in a reference image (e.g., a clean OS install) to focus on user-specific data.</li><li>$ sdhash $(Approximate Matching): * Function: Produces a similarity score on a continuous scale ($ 0-100 $) rather than a binary (yes/no) match. * Feature Selection: Selects$ 64\,byte $sequences based on an entropy-based measure of statistical improbability. * Bloom Filters: Uses bitwise overlap between Bloom filters to estimate shared byte-level features. A digest for a$ 1\,GB $file typically consists of an ordered sequence of$ 256\,byte $Bloom filters, totaling approximately$ 500\,KB $.</li><li>Entropy Analysis: * Shannon Entropy Scale: Ranges from$ 0 $to$ 8.0\,bits/byte $. * Interpretations: High entropy ($ 7.9+ $) indicates significant randomness, which is consistent with encryption, compression, or deliberate random fill. Entropy alone cannot distinguish between these sources. * Validation: The$ Chi-square $distribution is often used alongside entropy to test for randomness.</li></ul><h3 id="de661a53-3165-4fc3-b0ba-567377451172" data-toc-id="de661a53-3165-4fc3-b0ba-567377451172" collapsed="false" seolevelmigrated="true">The Sleuth Kit ($ TSK $) and File Recovery</h3><ul><li>Command Sequence for Deleted Files: * Identify deleted files using$ fls $. An asterisk ($ $) denotes a deleted entry (e.g.,$ r/r\,\,13: termination_notice.docx $). * Inspect Metadata: Use$ istat\,-o\,[offset]\,image.dd\,13 $. * Recover Content: Use$ icat\,-o\,[offset]\,image.dd\,13\,>\,recovery.docx $. * Limitation: Recovery depends on whether the data blocks have been overwritten (allocation status) and if the filesystem is fragmented.</li><li>$ mmls $vs$ fdisk $:$ mmls $displays unallocated inter-partition gaps and alignment regions, which$ fdisk\,-l $often ignores.</li></ul><h3 id="8881ded9-4dec-45c7-83ca-853da8c7ecbd" data-toc-id="8881ded9-4dec-45c7-83ca-853da8c7ecbd" collapsed="false" seolevelmigrated="true">Anti-Forensics and Timeline Analysis</h3><ul><li>Timestomping: The deliberate modification of timestamps ($ MAC $times) to hide activity. If four unrelated files across different directories share identical$ m/a/c $timestamps to the second (e.g.,$ Mon\,Jan\,15\,2024\,03:47:12), it strongly suggests the use of anti-forensic tools.
Verification: A legitimate alternative explanation (like a system-wide update or bulk copy) must be ruled out by checking installer logs or system activity records.

Questions & Discussion

Q: How do you confirm a block's allocation status?
A: Analyze the metadata structures (like the bitmap in ext4 $or$ MFT $in$ NTFS$$) to see if the bit corresponding to that block is set to allocated or free.
Q: What is the risk of a stop list based on an HR directory?
A: If an attacker uses an internal email address to exfiltrate data, a stop list containing all company addresses would suppress that evidence, leading to a false negative.