Unit 2: Understanding Hard Disks and File Systems

I. Foundations of Digital Storage and File-System Analysis

Digital storage preserves information as addressable binary values, while a file system organizes those values into named files, directories, metadata, and allocation units. Forensic analysis examines both allocated data and residual evidence without altering the original medium.

• Core principles:
  • Binary representation: Disks store bit patterns interpreted as files, timestamps, partitions, or executable instructions according to a defined structure.
  • Physical versus logical view: Physical storage concerns sectors and hardware; the logical view concerns partitions, volumes, directories, and files.
  • Metadata: File systems record attributes such as size, ownership, allocation status, and timestamps.
  • Persistence: Deleting a file usually removes or changes metadata before its data blocks are overwritten.
  • Forensic integrity: Examiners acquire bit-stream images through write-blocking and verify them with hashes such as SHA-256.
  • Interpretation: The same bytes may represent text, integers, instructions, or pixels depending on encoding and file format.

II. Disk Drive Technologies

A. Types of Disk Drives

Disk-drive types differ in recording technology, performance, interfaces, and the forensic traces they retain.

• Hard disk drive (HDD): An HDD stores data magnetically on rotating platters.
  • Platters are divided into tracks and sectors.
  • Read/write heads move across platter surfaces.
  • Common rotational speeds include 5,400 and 7,200 revolutions per minute.
  • Mechanical failure may affect heads, motors, or platter surfaces.
• Solid-state drive (SSD): An SSD stores charge in NAND flash cells and has no moving parts.
  • A controller performs wear levelling, bad-block management, and garbage collection.
  • The TRIM command informs the SSD that logical blocks are no longer needed.
  • TRIM and garbage collection can erase deleted evidence before examination.
• Hybrid drive: A solid-state hybrid drive combines magnetic storage with flash cache, improving access to frequently used data while retaining HDD capacity.
• Optical drive: CD, DVD, and Blu-ray media encode data as optical marks arranged along a spiral track; recordable and rewritable variants have different persistence properties.
• Removable flash storage: USB drives and memory cards use NAND flash but may expose controller-managed storage through USB, SD, or microSD interfaces.
• Drive interfaces: SATA commonly connects internal HDDs and SSDs; NVMe uses PCI Express for lower latency; USB and Thunderbolt commonly connect external devices.
• Forensic significance: Device type determines acquisition strategy, especially where encryption, damaged media, volatile caches, or SSD background operations may affect evidence.

III. Disk Organization

A. Logical Structure of a Disk

A disk’s logical structure maps raw sectors into partitions, volumes, file-system structures, and user-accessible files.

• Sector: The smallest traditionally addressable disk unit is commonly 512 bytes, although Advanced Format devices commonly use 4,096-byte physical sectors.
• Logical block addressing (LBA): Modern systems identify sectors using sequential numbers, such as LBA 0 for the first addressable sector.
• Partition: A partition is a defined range of sectors treated as an independent storage region.
• Master Boot Record (MBR): Located in the first logical sector, MBR contains boot code, a partition table with four primary entries, and the signature 55 AA.
• GUID Partition Table (GPT): GPT supports large disks and many partitions, stores partition entries with GUIDs, and maintains primary and backup headers with integrity checks.
• Volume: A volume is a logical storage unit on which a file system may be created; it may correspond to one partition or span multiple devices.
• Allocation unit: File systems group sectors into clusters or blocks. A 10,000-byte file stored in 4,096-byte clusters requires three clusters, leaving 2,288 bytes of slack in the last cluster.
• Key evidence regions:
  • Allocated space: Clusters currently assigned to files.
  • Unallocated space: Clusters not presently assigned but potentially containing deleted data.
  • File slack: Unused bytes between a file’s logical end and the end of its final allocated cluster.
  • Partition gaps: Unpartitioned sectors that may hold remnants or deliberately concealed data.

IV. Operating-System Startup

A. Booting Process of Windows and Linux

Booting moves a computer from firmware initialization to a running kernel and user environment, leaving configuration and event artifacts useful in forensic reconstruction.

1. Windows boot sequence:

   • Firmware: BIOS performs hardware initialization and loads MBR boot code, while UEFI firmware reads an EFI executable from the EFI System Partition.
   • Windows Boot Manager: bootmgr on legacy systems or bootmgfw.efi on UEFI systems reads the Boot Configuration Data store.
   • OS loader: winload.exe or winload.efi loads the Windows kernel, hardware abstraction layer, boot drivers, and system registry data.
   • Kernel initialization: ntoskrnl.exe initializes memory, processes, devices, and kernel services.
   • User space: Session Manager (smss.exe) starts essential subsystems; wininit.exe, Service Control Manager, and winlogon.exe establish services and interactive logon.

2. Linux boot sequence:

   • Firmware: BIOS or UEFI initializes hardware and selects a boot device.
   • Bootloader: GRUB commonly presents boot entries and loads the selected kernel plus an initial RAM file system.
   • Kernel: The Linux kernel initializes memory, drivers, scheduling, and storage before mounting a temporary root supplied by initramfs.
   • Root transition: Startup scripts locate and mount the persistent root file system.
   • Init system: systemd, commonly process identifier 1, starts units and reaches a configured target such as multi-user or graphical mode.
   • Analytical value: BCD entries, EFI files, boot logs, kernel command lines, service definitions, and system journals can reveal boot devices, startup persistence, failures, and altered configurations.

V. Operating-System File Systems

A. File Systems of Windows and Linux

Windows and Linux file systems define how files are named, allocated, protected, timestamped, journaled, and recovered.

1. Windows file systems:

   • FAT32: Uses a File Allocation Table linking clusters. Directory entries store names, starting clusters, sizes, and limited timestamps; deleted entries mark the first filename byte while cluster contents may remain.
   • exFAT: Designed for flash media and large files, avoiding FAT32’s 4 GiB minus 1 byte maximum file-size limitation.
   • NTFS: Represents files through records in the Master File Table ($MFT). Attributes may be resident inside a record or non-resident in external data runs.
   • NTFS evidence: $LogFile supports journaling, $Bitmap tracks cluster allocation, and $UsnJrnl records change events. Alternate data streams can associate additional content with a filename.
   • Timestamps: NTFS commonly records creation, modification, MFT-entry modification, and access times in both $STANDARD_INFORMATION and $FILE_NAME attributes.

2. Linux file systems:

   • ext4: Uses inodes for metadata and extents for efficient block mapping. Directory entries associate names with inode numbers.
   • Journaling: ext4 records pending metadata changes in a journal, reducing corruption after an unexpected shutdown.
   • XFS: A scalable journaling file system using allocation groups and B-trees, commonly deployed for large or high-throughput storage.
   • Btrfs: Uses copy-on-write structures and supports checksums, snapshots, subvolumes, and multi-device storage.
   • Permissions: Inodes record owner ID, group ID, and read, write, and execute bits; access control lists may add finer-grained rules.
   • Critical contrast: NTFS centers analysis on MFT attributes, whereas ext-family analysis centers on inodes and directory entries. Linux filenames are normally case-sensitive; Windows NTFS access is commonly case-insensitive.

VI. Forensic File-System Examination

A. File System Examination Using Autopsy

Autopsy is a graphical digital-forensics platform built around The Sleuth Kit and used to examine forensic images, file systems, metadata, and extracted artifacts.

• Case creation: The examiner creates a case, records identifying details, and adds a data source such as a raw image, E01 image, local disk, or logical files.
• Integrity controls: The source image should be acquired with a write-blocker and verified against a recorded cryptographic hash before analysis.
• Ingest modules: Configurable modules calculate hashes, identify file types, extract archives, parse recent activity, search keywords, and detect known or notable files.
• File-system navigation: Autopsy presents partitions, directories, allocated files, deleted entries, unallocated space, and metadata in a structured tree.
• Timeline analysis: Timestamp data can be arranged chronologically to correlate file creation, modification, access, deletion, and system activity.
• Keyword searching: Exact terms, regular expressions, or indexed searches locate relevant content across files and extracted text.
• Data carving: File signatures can recover content from unallocated space even when directory metadata is absent, although filenames and original paths may be unrecoverable.
• Reporting: Tagged items, hash values, comments, and artifact details can be exported into a report while preserving links to their source evidence.
• Limitations: Results depend on parser support, ingest settings, image quality, encryption state, and correct timestamp interpretation; automated findings require manual validation.

VII. Storage Architectures

A. Storage Systems

Storage systems combine devices, controllers, network protocols, and redundancy methods to provide capacity, availability, and performance.

• Direct-attached storage (DAS): Storage connects directly through SATA, SAS, USB, or PCIe and is managed by the attached host.
• Network-attached storage (NAS): A network appliance provides file-level access through protocols such as SMB or NFS.
• Storage area network (SAN): A SAN supplies block-level storage through technologies such as Fibre Channel or iSCSI; hosts treat logical units as disks.
• Cloud storage: Providers expose object, file, or block storage through remote services. Evidence acquisition may require provider APIs, credentials, audit logs, and legal authority.
• RAID:
  • RAID 0: Stripes data across disks for performance but provides no redundancy.
  • RAID 1: Mirrors data, permitting continued operation after one member fails.
  • RAID 5: Uses distributed parity and tolerates one failed disk.
  • RAID 6: Uses dual parity and tolerates two failed disks.
  • RAID 10: Combines mirroring and striping for performance and redundancy.
• Forensic challenge: RAID examination requires correct disk order, stripe size, parity layout, and member offsets; an incorrect reconstruction produces misleading byte sequences.
• Virtual storage: Virtual machines may use VHD, VHDX, VMDK, or QCOW2 files, including snapshots and differencing disks that must be examined as a related chain.

VIII. Data Representation and Low-Level Inspection

A. Encoding Standards and Hex Editors

Encoding standards map abstract characters to numeric values, while hex editors expose the exact bytes stored in evidence.

• ASCII: Represents 128 characters using values 0x00 to 0x7F; uppercase A is decimal 65 or hexadecimal 41.
• Unicode: Assigns each character a code point, written in forms such as U+0041.
• UTF-8: Encodes Unicode using one to four bytes and preserves ASCII’s single-byte representation for its first 128 characters.
• UTF-16: Uses 16-bit code units and may require surrogate pairs for characters outside the Basic Multilingual Plane.
• Endianness: Multi-byte numbers may store the most significant byte first (big-endian) or least significant byte first (little-endian). The value 0x1234 appears as 34 12 in little-endian storage.
• Hexadecimal notation: One hexadecimal digit represents four bits, so one byte is displayed as two digits from 00 through FF.

Bytes: 48 65 6C 6C 6F
UTF-8/ASCII interpretation: Hello

• Hex-editor functions: Tools such as HxD, WinHex, or xxd display offsets, hexadecimal bytes, and text interpretations, permitting examination of headers, sectors, slack, and embedded data.
• File signatures: JPEG files commonly begin FF D8 FF, while PDF files begin with bytes representing %PDF; signatures help detect renamed files and support carving.
• Forensic discipline: Examiners should work on verified copies or use read-only mode because changing one byte alters evidence and its cryptographic hash.