Unit 2: Understanding Hard Disks and File Systems - Subjective Questions

A disk drive is a hardware device that stores and retrieves digital data using magnetic, electronic, or optical storage technology.

Major types include:

• Hard Disk Drive (HDD): Stores data magnetically on rotating platters. It provides high capacity at a relatively low cost but contains mechanical parts.
• Solid-State Drive (SSD): Uses NAND flash memory and has no moving parts. It offers faster access, lower power consumption, and greater shock resistance.
• Optical Drive: Reads or writes CDs, DVDs, and Blu-ray discs with a laser. Optical media may contain software, backups, or evidentiary data.
• USB flash drive: A portable flash-based storage device connected through a USB interface.
• External drive: An HDD or SSD housed in an external enclosure and connected through USB, Thunderbolt, or another interface.
• Hybrid drive: Combines magnetic storage with a small flash-memory cache to improve performance.

In digital forensics, each drive type requires suitable acquisition methods because deleted-data behavior, interfaces, and internal data management differ.

Technical differences:

Forensic differences:

• An HDD commonly retains deleted data until the relevant sectors are overwritten.
• An SSD may use TRIM, which informs the controller that deleted blocks are no longer required.
• SSD garbage collection may erase or reorganize blocks even when the operating system is idle.
• SSD controllers perform wear leveling, so the logical block address visible to the operating system may not correspond to a fixed physical location.
• HDD acquisition is generally more predictable at the sector level.
• Both devices should be acquired using validated forensic tools and write-blocking mechanisms.

Thus, recovery of deleted data is often more difficult and time-sensitive on an SSD than on an HDD.

A hard disk can be understood through its physical and logical organization.

Physical organization:

• A platter is a circular magnetic surface on which data is stored.
• A track is a concentric circular path on a platter.
• A sector is a subdivision of a track and is traditionally 512 bytes, although modern disks commonly use 4096-byte physical sectors.
• A read/write head accesses the magnetic surface.
• A cylinder traditionally refers to tracks at the same radius across multiple platter surfaces.

Logical organization:

• Modern systems address sectors using Logical Block Addressing (LBA) rather than physical cylinder-head-sector values.
• A cluster, or allocation unit, consists of one or more sectors and is the smallest unit normally allocated by a file system.
• A disk may be divided into partitions, and each partition may contain a file system.
• File systems maintain metadata that maps files to allocated clusters.

If the sector size is bytes and a cluster contains sectors, the cluster size is:

Understanding these structures helps investigators locate partitions, recover deleted files, and interpret file slack.

The MBR contains bootstrap code, a partition table, and the boot signature. GPT normally contains a protective MBR, a primary GPT header, partition entries, usable partition space, backup entries, and a backup header.

From a forensic perspective, investigators should examine both primary and backup GPT data. Inconsistencies between them may indicate corruption, manipulation, or incomplete disk imaging.

A partitioned disk generally contains:

1. Partitioning metadata, such as an MBR or GPT.
2. One or more partitions, each covering a defined range of logical sectors.
3. File-system structures, including boot records, allocation metadata, directories, and file data.
4. Unallocated disk regions, which are not assigned to an active partition.

Forensic significance:

• Unallocated space: Clusters not currently assigned to files may contain deleted file content, fragments, or historical data.
• File slack: Unused bytes between the logical end of a file and the end of its final allocated cluster may preserve remnants of previous data.
• Partition gaps: Sectors located between declared partitions may contain old structures or deliberately concealed information.
• Hidden partitions: A partition may be omitted from normal mounting, assigned a hidden type, or created outside expected boundaries.
• Host Protected Area (HPA) and Device Configuration Overlay (DCO): Certain drives can report less capacity than physically available, potentially concealing sectors.

An examiner should therefore analyze the entire physical image rather than only mounted file systems.

The Windows boot process on a BIOS and MBR system proceeds broadly as follows:

1. Power-on and POST: The BIOS performs the Power-On Self-Test and initializes hardware.
2. Boot-device selection: The BIOS selects a bootable device according to its configured order.
3. MBR execution: The first disk sector is loaded into memory. Its bootstrap code examines the MBR partition table.
4. Active partition selection: MBR code locates the partition marked active and loads its volume boot record.
5. Windows Boot Manager: The boot record starts BOOTMGR.
6. BCD processing: BOOTMGR reads the Boot Configuration Data (BCD) store and displays boot choices when necessary.
7. Operating-system loader: winload.exe loads the Windows kernel, Hardware Abstraction Layer, boot-start drivers, and system registry data.
8. Kernel initialization: The kernel initializes subsystems, mounts the system volume, and starts the Session Manager.
9. User environment: Windows services start, followed by the logon interface and user session.

Forensic examination of the MBR, boot sector, BCD store, and boot files can reveal boot configuration changes, malware, or damaged startup structures.

On a UEFI-based Windows system, the process is generally:

1. UEFI firmware initializes hardware and performs startup checks.
2. Firmware reads boot entries stored in non-volatile memory.
3. It accesses the EFI System Partition (ESP), normally formatted with FAT.
4. The Windows firmware boot manager, commonly bootmgfw.efi, is executed.
5. Windows Boot Manager reads the BCD store.
6. winload.efi loads the Windows kernel, required drivers, and supporting components.
7. The kernel initializes the operating system and starts services and logon processes.

Differences from legacy BIOS:

• UEFI loads an executable from the ESP instead of executing MBR bootstrap code.
• GPT generally replaces the MBR partition table.
• UEFI supports larger disks and more partitions.
• Secure Boot can verify signatures of boot components and help prevent unauthorized boot loaders.
• Boot options are stored as firmware variables rather than relying only on an active-partition flag.

Investigators may examine the ESP, EFI executables, GPT structures, firmware boot entries, and Secure Boot configuration for evidence of boot-level tampering.

The Linux boot process contains several stages:

1. Firmware initialization: BIOS or UEFI initializes hardware and selects a boot device.
2. Boot-loader execution: A boot loader such as GRUB is loaded from boot sectors or the EFI System Partition.
3. Configuration selection: GRUB reads its configuration and allows selection of a kernel and boot parameters.
4. Kernel loading: The compressed Linux kernel and an initial RAM file system, such as initramfs, are loaded into memory.
5. Kernel initialization: The kernel detects hardware, initializes memory management and drivers, and mounts the temporary root environment.
6. Root file-system mounting: Scripts and drivers in initramfs locate and mount the actual root file system.
7. Init process: The kernel starts process ID 1, commonly systemd or another init system.
8. Service startup: The init system starts targets, services, networking, logging, and device-management components.
9. Login environment: A text login prompt or graphical display manager is presented.

Forensically important artifacts include GRUB configuration files, kernel command-line parameters, initramfs images, system logs, service definitions, and startup scripts.

Similarities:

• Both begin with BIOS or UEFI firmware initialization.
• Both use a boot manager or boot loader.
• Both load a kernel and hardware drivers.
• Both initialize system services before presenting a login interface.

Differences:

• Windows commonly uses BOOTMGR, BCD, winload.exe, or their UEFI equivalents.
• Linux commonly uses GRUB, a selected kernel image, initramfs, and an init system such as systemd.
• Windows configuration is strongly tied to the BCD store and Registry, whereas Linux boot settings are often held in text-based configuration files.
• Linux commonly permits multiple kernels and flexible kernel command-line parameters.

Forensic evidence:

• MBR, GPT, and volume boot records.
• EFI System Partition contents.
• BCD entries and Windows boot logs.
• GRUB configuration and boot-loader files.
• Kernel and initramfs timestamps.
• Startup services, scheduled startup tasks, and systemd units.
• Secure Boot records and altered EFI executables.

Such artifacts can reveal unauthorized operating systems, persistence mechanisms, bootkits, configuration changes, and approximate system activity.

FAT32:

• Uses a File Allocation Table to track cluster chains.
• Offers broad compatibility with operating systems and embedded devices.
• Does not provide native file permissions, journaling, encryption, or compression.
• Has a maximum individual file size of approximately 4 GiB.

exFAT:

• Designed mainly for flash media and large removable devices.
• Supports files larger than the FAT32 limit.
• Uses allocation structures optimized for large storage media.
• Does not provide the complete security and journaling features of NTFS.

NTFS:

• Uses the Master File Table (MFT) to store file and directory records.
• Supports access-control lists, journaling, compression, encryption, hard links, and alternate data streams.
• Stores file metadata as attributes.
• Provides better reliability and forensic metadata than FAT-based systems.

Forensic tools interpret these structures to identify files, deleted entries, timestamps, cluster allocation, and concealed data.

NTFS organizes information through metadata files and attribute-based records. Its central structure is the Master File Table (MFT).

Important NTFS components:

• $MFT: Contains a record for almost every file and directory.
• $MFTMirr: Stores a backup of critical initial MFT records.
• $Bitmap: Identifies allocated and unallocated clusters.
• $LogFile: Contains file-system transaction journal information.
• $Boot: Contains the NTFS volume boot record.
• $UsnJrnl: May record changes made to files and directories.

An MFT record contains attributes such as:

• $STANDARD_INFORMATION, including timestamps and flags.
• $FILE_NAME, including a name, parent reference, and another set of timestamps.
• $DATA, containing file content or references to external data runs.

Small files may be resident, meaning their content is stored inside the MFT record. Larger files are non-resident and are stored in disk clusters described by data runs.

The MFT is forensically important because it can reveal deleted files, multiple filenames, parent directories, allocation status, timestamps, alternate data streams, and storage locations. Comparing different timestamp attributes may also help identify timestamp manipulation.

The ext family is widely used in Linux:

• ext2: A non-journaling file system.
• ext3: Adds journaling to improve recovery after an improper shutdown.
• ext4: Supports large volumes and files, extents, delayed allocation, and other performance improvements.

Main structures:

• Superblock: Stores critical information such as file-system size, block size, status, and inode counts.
• Block groups: Divide the file system into manageable regions.
• Block bitmap: Records used and free data blocks.
• Inode bitmap: Records used and free inodes.
• Inode table: Contains inode structures.
• Inode: Stores metadata such as ownership, permissions, size, timestamps, link count, and references to file data.
• Directory entry: Maps a filename to an inode number.
• Journal: Records pending metadata or data changes, depending on the journaling mode.

An inode generally does not store the filename; the filename is held in a directory entry. Therefore, forensic reconstruction may require correlating directory entries, inode metadata, journal records, and data blocks.

Forensic implications:

• NTFS provides rich metadata through the MFT, $LogFile, and USN Journal.
• ext4 examination requires correlation of inodes, directory entries, bitmaps, extents, and journal data.
• Deleted NTFS records may retain filenames and attributes until reused.
• Deleted ext4 data recovery may be complicated when inode and extent information is cleared or reused.
• Timestamp meanings and update rules differ, so they must be interpreted in file-system context.

Neither file system should be mounted read-write during examination because mounting can alter metadata and journals.

Deleting a file usually removes or modifies its metadata reference and marks its storage space as available; the data may remain until overwritten.

Examination process:

• Inspect deleted directory entries, MFT records, or inodes.
• Determine the clusters or blocks previously assigned to the file.
• Recover content through metadata-based recovery when allocation information remains.
• Use file carving when metadata is unavailable. Carving identifies data through file headers, footers, and internal structure.
• Search unallocated space for keywords, fragments, and known file signatures.
• Inspect file slack, which is the unused portion of a file's final allocated cluster.

Limitations:

• Reallocated blocks may contain overwritten or mixed content.
• Fragmented files are difficult to carve accurately.
• Compression or encryption may prevent meaningful recovery.
• SSD TRIM and garbage collection may remove deleted content.
• Carving can produce false positives because a signature does not necessarily prove that a complete file exists.

Recovered material must be documented with its source offsets and validated where possible.

A typical Autopsy workflow includes:

1. Preserve the original: Acquire a forensic image with a write blocker and retain the original evidence securely.
2. Verify integrity: Calculate and record cryptographic hashes of the acquired image.
3. Create a case: Enter a case name, examiner details, and storage location in Autopsy.
4. Add a data source: Select a disk image, local disk, or supported logical data source. Configure the correct time zone.
5. Select ingest modules: Enable modules for file-type identification, hash lookup, keyword searching, web artifacts, recent activity, embedded files, and other relevant analysis.
6. Review file systems: Examine partitions, directories, allocated files, deleted files, unallocated space, and orphan files.
7. Analyze artifacts: Review browser history, downloads, accounts, documents, images, communications, metadata, and operating-system artifacts.
8. Build a timeline: Correlate file-system and application timestamps while accounting for time-zone differences.
9. Tag findings: Add comments, bookmarks, and tags to relevant evidence.
10. Export and report: Export selected files when needed and generate a report containing findings and provenance.
11. Validate results: Confirm significant findings with another tool or direct structure examination when appropriate.

Every action should be documented to maintain repeatability, integrity, and chain of custody.

Ingest modules automatically process a data source and extract selected categories of information. They may identify file types, parse application artifacts, calculate hashes, extract archives, and detect notable files.

Hash sets are used to:

• Identify known files through cryptographic hash comparison.
• Exclude known benign operating-system or application files.
• Flag files known to be relevant, prohibited, or malicious.
• Reduce the amount of material requiring manual review.

Keyword searching helps locate names, email addresses, phrases, identifiers, and regular-expression patterns. Searches should consider Unicode encodings, case variations, and false positives.

Timeline analysis arranges events by timestamps obtained from file systems and application artifacts. It can reveal creation, modification, access, deletion, execution, browsing, and download activity.

Investigators must verify time zones, clock drift, timestamp semantics, and potential manipulation. Automated results are investigative leads and should be validated against the underlying evidence.

Direct-Attached Storage (DAS): Storage connected directly to a computer, such as an internal SATA drive, external USB drive, or locally attached disk array.

Network-Attached Storage (NAS): A network appliance that provides file-level access through protocols such as SMB or NFS.

Storage Area Network (SAN): A specialized network that provides block-level storage, commonly through Fibre Channel or iSCSI. A server may treat SAN storage as a locally attached disk.

Forensic relevance:

• NAS evidence may include user shares, snapshots, access logs, and appliance metadata.
• SAN data may be distributed across logical units, controllers, and multiple physical disks.
• Live acquisition may be required when shutting down a business system is impractical.
• Investigators must preserve permissions, timestamps, snapshots, configuration records, and logs.
• A logical copy of a share may omit deleted files, unallocated blocks, and storage-level metadata.

RAID combines multiple disks to improve performance, availability, or both.

Forensic challenges:

• Disk order, stripe size, parity rotation, and starting offset must be identified correctly.
• A controller may store proprietary RAID metadata.
• Missing or failed members may require reconstruction using parity or mirror copies.
• Imaging disks separately without recording slot order can make reconstruction difficult.
• Controller caches and write-back behavior may affect consistency.
• Virtual disks presented by the controller may not reveal the complete physical organization.

Investigators should document controller configuration, disk serial numbers, bay positions, RAID level, stripe parameters, and acquisition method before altering the array.

ASCII is a character-encoding standard that represents basic English letters, digits, punctuation, and control characters using 7-bit values.

Unicode defines code points for characters from many writing systems. Common Unicode transformation formats include:

• UTF-8: Uses one to four bytes per code point. ASCII characters retain their original one-byte values.
• UTF-16: Uses one or two 16-bit code units. Characters outside the Basic Multilingual Plane use surrogate pairs.
• UTF-32: Uses a fixed 32-bit code unit for each code point, although storage byte order still matters.

Endianness specifies byte order for multi-byte values:

• Little-endian: Least significant byte appears first.
• Big-endian: Most significant byte appears first.

A byte order mark (BOM) may identify an encoding or byte order, such as UTF-16LE or UTF-16BE.

Encoding is forensically important because an incorrect interpretation can hide keywords, corrupt filenames, or produce misleading text. Search tools should test relevant encodings, and examiners should distinguish character encoding from encryption or compression.

A hex editor displays raw data as hexadecimal byte values, usually alongside an ASCII or Unicode interpretation. It enables an examiner to inspect structures without relying entirely on file-system software.

Common uses include:

• Examining MBR, GPT, and volume boot records.
• Confirming sector signatures and file-system identifiers.
• Locating file headers, footers, and embedded content.
• Interpreting timestamps, flags, offsets, and numeric fields.
• Checking little-endian and big-endian values.
• Viewing file slack and unallocated data.
• Validating results produced by automated forensic tools.

For example, the bytes 4D 5A commonly appear at the beginning of a Windows PE executable, while 25 50 44 46 represents the ASCII characters %PDF.

Precautions:

• Work on a verified forensic copy rather than original evidence.
• Open the image in read-only mode.
• Record byte offsets and sector numbers for important findings.
• Use the correct sector size, structure specification, and byte order.
• Avoid assuming that a file signature proves the existence of a complete or authentic file.
• Recalculate hashes if an authorized working copy is modified.

A hex editor is powerful but requires careful interpretation because incorrect offsets or endianness can produce false conclusions.