Storage Forensics and File System Analysis practice questions

HFS+

Why wrong: HFS+ (Hierarchical File System Plus) is a file system developed by Apple for managing files and directories, not a partition table. A partition table (like MBR or GPT) resides in the first sector(s) of a disk and defines how the disk is divided into partitions. HFS+ operates within a partition to store files, so it cannot be the correct answer to a question about partition-table size limits.

GPT

Why wrong: GPT (GUID Partition Table) is a modern partition-table standard that uses 64-bit logical block addresses and supports disks far larger than 2 TB, with a maximum partition size of 8 ZiB in theory. Because the question specifically identifies a maximum partition size of 2 TB—a characteristic of the legacy MBR scheme—GPT is incorrect here. Unlike MBR, GPT also stores multiple protective headers and checksums for redundancy.

APFS

Why wrong: APFS (Apple File System) is the current default file system for macOS and iOS, designed for SSDs with features like snapshots, encryption, and copy-on-write. It is not a partition table; it is a file system that lives inside partitions. Thus, APFS cannot be the correct answer when the distinguishing clue is a 2 TB partition-size cap tied to MBR.

Master File Table (MFT)

Why wrong: The Master File Table is the central metadata database of the NTFS filesystem, where each file or directory has a record containing security IDs, timestamps, data attributes, and resident/non-resident data pointers. FAT32 does not use an MFT at all; its file metadata is stored in 32-byte directory entries and its data layout is governed by the File Allocation Table. Since the evidence filesystem is FAT32, there is no MFT to parse or recover from, making this answer incorrect for the recovery scenario.

Journal

Why wrong: A journal is a transactional log that journals major filesystem changes so they can be replayed after an unclean shutdown; it is present in journaling file systems such as NTFS ($LogFile) and ext3/ext4, but FAT32 is a non-journaled file system. FAT32 has no journal structure, so there are no journal entries containing the deleted file's metadata, cluster runs, or directory updates that could be replayed. Therefore, any attempt to locate a journal on a FAT32 volume for deleted-file recovery would be fundamentally impossible.

Inode table

Why wrong: The inode table is a filesystem metadata structure used by ext2, ext3, ext4, and other Unix-style file systems; each inode stores file permissions, ownership, timestamps, and direct/indirect block pointers. FAT32 stores files using directory entries and the File Allocation Table, which is a flat array of cluster pointers rather than a table of inode objects. Because the target filesystem is FAT32, there are no inodes available—recovering the file would require parsing directory entries and FAT chain entries, not inode table records.

dd

Why wrong: dd is a low-level disk imaging tool that performs a raw, bit-for-bit copy of an entire block device or partition. It does not interpret ext4 metadata such as the inode table, superblock, or directory entries, so it cannot locate or recover a specific file based on its inode number. While dd is essential for creating forensic images for offline analysis, it is not itself a file-recovery mechanism.

scalpel

Why wrong: scalpel is a file carver that recovers data by scanning raw disk blocks for known file header and footer byte signatures, completely bypassing the filesystem's inode structure. It has no knowledge of ext4 inodes, directory entries, or allocation bitmaps, so it cannot target a file by its inode. Carving may recover files only if their data blocks remain contiguous and intact, making it unreliable for inode-based recovery.

foremost

Why wrong: foremost also performs raw data carving using header/footer signatures and content-based recognition, descending from the original TCT carve tool. Like scalpel, it operates independently of ext4 metadata and has no facility to resolve inode numbers or traverse the inode tree. It is a legitimate tool for recovering files by type, but it is fundamentally unsuited for recovering a file specifically identified by its inode on an ext4 filesystem.

USN Journal

Why wrong: The USN Journal is an NTFS change journal that records the sequence of file system changes, logging entries for creations, deletions, metadata modifications, and data overwrites. It is a forensic timeline artifact that can reveal when a file was altered to hide data, but it is not a storage mechanism for the hidden content itself. ADS data would be referenced by journal entries, but the actual hidden bytes reside in an NTFS data stream, not in the journal.

MFT

Why wrong: The Master File Table is the central catalog of every file and directory on an NTFS volume, storing metadata attributes such as timestamps, security descriptors, and the locations of data attributes. While very small resident files can have their primary data stored directly inside the MFT record, this is distinct from Alternate Data Streams, which are separate $DATA attributes attached to a file record. The MFT can show the names and sizes of streams, but it is not the hiding medium; it is the index that points to the streams.

Slack space

Why wrong: Slack space refers to the unused bytes between the end of a file's actual data and the end of the final cluster allocated to that file, resulting from cluster-granularity storage. Although slack space can be used to conceal data by writing to these residual bytes, it is not a named stream and is not visible in the file system's logical metadata. Unlike ADS, which is a structured attribute with a filename, slack space is an artifact of physical disk allocation and is only discovered through raw disk imaging and carving.

volatility -f mem.dump hashdump

Why wrong: The `hashdump` plugin extracts the Security Account Manager (SAM) registry hive and cached domain credentials from memory to obtain NTLM password hashes. It provides no process information whatsoever, so it cannot be used to list running processes. This command is intended for credential harvesting or auditing after a compromise, not for process enumeration, making it clearly wrong for the stated task.

volatility -f mem.dump malfind

Why wrong: The `malfind` plugin scans each process's address space for executable memory pages that are suspicious, such as PAGE_EXECUTE_READ_WRITE regions or allocations lacking a corresponding backing file, to detect code injection. It does not list processes; instead, it analyzes memory regions within processes to flag anomalies. While useful for a deeper compromise investigation, it cannot produce a simple process list, so it does not answer the question.

volatility -f mem.dump netscan

Why wrong: The `netscan` plugin enumerates active and recently closed network connections and sockets by inspecting kernel TCP/UDP endpoint structures in memory, associating them with owning process IDs. It does not provide a comprehensive list of all running processes; it only shows network-related activity. For example, a purely offline process with no sockets would not appear, making this command inadequate for full process enumeration.

Wear leveling complicates data location

Why wrong: Wear leveling does dynamically redistribute logical blocks across NAND cells, but it only relocates data that is still considered valid; the erased blocks are part of the SSD's normal FTL mapping. Deleted file sectors become stale, and wear leveling alone does not guarantee that a stale block is erased, since the controller may wait until the block is reused. Thus wear leveling adds complexity to locating data but is not the reason deleted files disappear; TRIM's explicit block erasure is.

RAID striping interferes with imaging

Why wrong: RAID striping is a valid concern when imaging a multi-disk array, as the examiner would need to reconstruct the logical volume from the striped components. However, this scenario states only that a single SSD is acquired; no RAID configuration has been mentioned or implied. Without evidence of striping across multiple physical disks, RAID is irrelevant to the imaging process.

The SSD is encrypted and cannot be imaged

Why wrong: Encryption is a plausible concern in any forensic case, yet nothing in the scenario indicates that the SSD is encrypted. Moreover, even full-disk encryption does not make imaging impossible—tools can still create a bit-for-bit copy, and decryption is a separate analysis challenge. Therefore encryption cannot be the reason deleted files are unrecoverable here, whereas TRIM's physical erasure directly addresses the data loss.

To store the file system journal

Why wrong: A file system journal, such as NTFS $LogFile or ext3/4 journal, is stored in a regular, visible partition and is actively accessed by the file system driver during normal operation to record pending changes. The HPA is an ATA feature that reduces the reported address space, making it invisible to the OS and standard file system utilities, so it cannot serve as a journal that requires live mounted access.

To accelerate disk read/write operations

Why wrong: The Host Protected Area (HPA) is a reserved region at the end of the disk created by lowering the reported maximum LBA via the SET MAX ADDRESS command; it has no effect on rotational speed, cache, or interface throughput. If anything, hiding capacity can minimally reduce the usable surface, but the mechanism is purely a logical address-space alteration and provides no I/O acceleration or caching benefit.

To store backup copies of the MBR

Why wrong: The MBR resides in LBA 0, the very first sector, which is always within the visible addressable space of the disk, while the HPA is a region beyond the reported maximum LBA and therefore not a natural place for an MBR backup. Although a forensic examiner might store a backup image there with custom tools, the HPA's purpose is not MBR backup; vendors use it for recovery or hidden data, and MBR copies are more commonly stored as regular files or in another disk's visible area.

Two disks failed simultaneously

Why wrong: A simultaneous two-disk failure in RAID 5 is catastrophic, not a subtle corruption issue. RAID 5 provides fault tolerance for exactly one disk failure; if a second disk fails before the first is rebuilt, the array loses all data and typically goes offline or is reported as 'failed' by the controller. This would appear as a missing logical drive, not as corrupted data or a rebuild error, so it cannot explain the investigator's symptom.

The file system is not supported by the RAID controller

Why wrong: RAID controllers operate at the block abstraction layer and are completely file-system agnostic — they see arrays of logical blocks, not files or directories. The file system type (NTFS, ext4, HFS+, etc.) is handled entirely by the operating system after the block device is presented, so an 'unsupported' file system would only prevent the OS from mounting the volume, never interfere with the RAID rebuild or cause underlying disk corruption. Consequently, this option is irrelevant to the reported array corruption.

The array was configured with an incorrect stripe size

Why wrong: The stripe size (or stripe width) is a static parameter defined when the RAID array is created and stored in the controller's metadata; it determines how many bytes of consecutive data are written to each disk before switching to the next. An 'incorrect' stripe size does not arise during a routine rebuild — the controller uses the original stripe size recorded in its configuration, so there is no mechanism for it to corrupt data. Even if the stripe size were changed manually, the array would need to be recreated, a process that destroys data rather than merely corrupting it, so this cannot be the cause of a rebuild error.

Process hollowing

Why wrong: Process hollowing creates a suspended process, replaces its original executable image with malicious code, and then resumes the process. The injected payload is mapped as a private memory region with its own PE headers and is not part of the heap segments that malfind inspects. Malfind's heuristic identifies executable writable regions containing code-like patterns, but process hollowing's code resides in a section-backed mapping or a freshly allocated region rather than in heap allocations, so it would not be the technique directly diagnosed by malfind.

DLL injection

Why wrong: DLL injection typically forces a target process to load a DLL by calling LoadLibrary through a remote thread. The DLL is mapped as a MEM_IMAGE region with its own sections and proper file backing, not as a heap allocation. Volatility's malfind plugin specifically scans for private executable heap pages that often contain sprayed shellcode, so a legitimately loaded DLL would not exhibit the same heuristic signature. Instead, DLL injection is more reliably exposed by dlllist, ldrmodules, or the injects plugin.

Reflective DLL loading

Why wrong: Reflective DLL loading manually maps a DLL from memory into a process without using LoadLibrary, usually by allocating private memory via VirtualAlloc and copying image sections. Although the resulting allocation may be executable and writable—and thus could be flagged by malfind—it contains a complete PE structure rather than the repeated filler pattern characteristic of heap spraying. A reflective DLL is a stealthier image mapping that preserves the shape of a DLL, whereas heap spraying populates the heap with numerous small blocks of code. Therefore, while both are memory-resident, malfind's heap-oriented heuristics point specifically to heap spraying, not reflective DLL loading.

The drive is failing and needs replacement

Why wrong: A Device Configuration Overlay (DCO) is a standard ATA feature that can limit the reported capacity of a drive; it is not a diagnostic indicator of physical media decay. Hard drive failure is typically associated with S.M.A.R.T. thresholds, bad sectors, or mechanical issues, none of which a DCO signals. Thus, finding a DCO in FTK Imager should not prompt a conclusion that the drive needs replacement.

The drive supports hardware encryption

Why wrong: Hardware encryption, as on self-encrypting drives, is implemented through the ATA Security feature set or the TCG Opal standard, not through the DCO mechanism. The DCO is solely a logical capacity-management region created by the ATA SET MAX ADDRESS command; it neither enables nor disables any cryptographic functionality. Therefore, the existence of a DCO reveals nothing about whether the drive encrypts its data.

The drive has a GPT partition table

Why wrong: A GPT partition table is a logical structure stored on the first and last sectors of a disk, while a DCO is a firmware-level overlay that sits outside the operating system's visible address space. These are independent concepts, and a DCO can exist on a drive whether it uses GPT or legacy MBR partitioning. Consequently, the presence of a DCO gives no indication about the partition table format.

FAT32

Why wrong: FAT32 does not support journaling. (Incorrect)

APFS

Why wrong: APFS uses copy-on-write rather than traditional journaling. (Incorrect)

File carving

Why wrong: File carving is a data recovery method that scans raw disk sectors for file signatures or magic numbers to reconstruct files without relying on filesystem metadata. It is used to recover deleted or orphaned data from unallocated space, which means it exposes hidden data rather than concealing it. Therefore, file carving is an investigative technique, not a data hiding technique.

Hashing

Why wrong: Hashing is a one-way mathematical function that produces a fixed-length digest from input data, primarily used for integrity checking, digital signatures, or password verification. It does not hide the original data; the source file remains fully intact and unchanged, and the hash value itself cannot be used to reconstruct or conceal the data. Thus, hashing is a verification technique, not a data hiding technique.

File system metadata may be overwritten

Why wrong: File system metadata can be overwritten on literally any rewritable storage device, including conventional magnetic hard drives, USB flash drives, and memory cards. Because this behavior is a property of the file system and write path rather than of NAND flash technology, it is a generic forensic obstacle and not a challenge that is specific to solid-state drives.

Magnetic remanence allows data recovery

Why wrong: Magnetic remanence refers to the lingering magnetization left on ferromagnetic media after data is erased, and it is a characteristic of HDD platters, not SSDs. An SSD stores bits as trapped charge in floating-gate transistors, so there is no magnetic pattern to recover with techniques like magnetic force microscopy; this option describes an HDD-specific phenomenon.

Slack space contains remnants of deleted files

Why wrong: Slack space is the unused region between the end of a file's logical data and the end of its allocated cluster, created by filesystem block allocation. It exists on every filesystem regardless of underlying storage technology, so while it can contain remnants of previously larger files, it is not a forensic complication unique to SSDs and does not distinguish SSD forensics from HDD forensics.

To recover deleted files from the Recycle Bin

Why wrong: The fsutil usn readjournal command queries the NTFS USN journal, which is a change log of file system modifications, not a repository for deleted file contents. Recovering items from the Recycle Bin would require parsing the $Recycle.bin directory and selecting files based on their $I metadata files. While the journal may reveal that a deletion occurred, it never stores the original file data, so it cannot aid in recovering deleted files themselves.

To check the integrity of the NTFS file system

Why wrong: NTFS integrity checking is performed by the chkdsk utility, which scans the volume for errors in the file system metadata, bad sectors, and structural problems. The USN journal, on the other hand, is an append-only log of change records and does not perform any validation or repair functions. Running fsutil usn readjournal will only output the content of the change journal to stdout; it will not test the health or consistency of the NTFS volume.

To extract the Master File Table ($MFT) from the volume

Why wrong: The Master File Table ($MFT) is a critical NTFS system file containing a record for every file and directory on the volume, and extracting it forensically typically requires a tool like FTK Imager or the ntfsinfo utility from The Sleuth Kit. The fsutil usn readjournal command targets the \$Extend\$UsnJrnl file, which is a change journal used to track modifications; it is separate from the $MFT. While the journal references files via their MFT file reference number, it does not expose the MFT records themselves.

USN Journal

Why wrong: The USN Journal is an NTFS logging mechanism that records all changes to files and directories, such as creations, deletions, and modifications. It is neither designed nor used as a data-hiding container; instead, it is a crucial forensic artifact that can reveal evidence of malicious activity by showing file system changes. Even if an attacker tries to clear or disable the journal to cover their tracks, the journal itself does not provide a covert storage location, making it an incorrect answer for hiding data.

$Recycle.bin

Why wrong: $Recycle.bin is the NTFS implementation of the Recycle Bin, storing files deleted by the user along with metadata like original paths and deletion dates. It is a user-visible and traceable location, not a hidden storage area; data placed there is immediately visible through the Recycle Bin UI and can be restored. While an attacker might temporarily stage files there, it is not a covert hiding mechanism because its contents are both exposed to the user and recoverable by forensic tools, distinct from true hidden storage.

Master File Table ($MFT)

Why wrong: The Master File Table ($MFT) is the core index of an NTFS volume, storing a record for each file and directory with attributes like timestamps, data runs, and security descriptors. Although advanced, obscure techniques can embed data in unused $MFT record slots or slack space, $MFT itself is fundamentally an indexing structure, not a dedicated hiding mechanism like ADS. Its role as the file system's directory makes it a prime source of forensic evidence, but it is not the standard or expected answer for hiding data.

The file is actually a link to another file, so its timestamps reflect the source

Why wrong: A symbolic link or shortcut is itself a file system object with its own MACE metadata; its timestamps record when the link file was created, modified, and accessed, not the target's. In NTFS, a reparse point carrying a link is stored in the directory entry or $MFT record, and forensic tools can immediately detect it, so there is no scenario where a link would make a file's creation time predate the volume's initialization.

The system clock was incorrect at the time of file creation

Why wrong: An incorrect system clock would affect all files created during the same time window, creating a systematic offset across many artifacts. The anomaly here is a single file's timestamp conflicting with the volume's own creation metadata; if the clock were merely wrong, the volume creation time would also be affected and the inconsistency would not appear. Moreover, the system would have to have been set back to a date before the file system was initialized, which is an extreme and implausible condition, and one that would leave traces in the registry or event logs.

The file was created on a different system and copied to this volume

Why wrong: When a file is copied to a new volume, the target file system allocates a new $MFT record or directory entry, and the creation timestamp is normally set to the moment of the copy (unless a copy tool explicitly preserves times, which would still prevent it from preceding the volume's creation). A creation time earlier than the volume's own initialization cannot result from a copy because the file system did not yet exist to receive the copy. The only way to produce such a timestamp is by directly altering the metadata after the fact, making deliberate manipulation the far more consistent explanation.

The file can be recovered by reading the journal and replaying the deletion transaction

Why wrong: Replaying a deletion transaction from the ext3 journal would reapply the exact metadata updates that performed the deletion: it clears the inode's block pointers and updates the block bitmap to mark the blocks as free, rather than restoring them. The journal contains only metadata, never the file's data content, so replaying cannot reconstruct the file itself. Even if the journal has not yet rotated, replaying the deletion transaction simply re-executes the deletion, making this approach the opposite of a recovery method.

The file cannot be recovered because ext3 zeroes the inode on deletion

Why wrong: The claim that ext3 zeroes the inode on deletion is factually incorrect. On deletion, the filesystem sets the inode's mode field to zero and clears its data block pointers, but the rest of the inode structure, including timestamps and file size, often remains on disk. More critically, the file's data blocks are not zeroed either; they are simply marked as free for future allocation. Thus, recovery is possible because carving reads those untouched data blocks directly, and the presence of a partially intact inode or journal entries does not change the fact that carving can find file signatures.

volatility -f memory.dmp --profile=Win10x64 psscan

Why wrong: Though psscan harnesses pool tag scanning to locate EPROCESS structures in raw physical memory, it can still miss hidden processes because advanced rootkits can directly modify or forge EPROCESS headers and pool tags. Moreover, it provides only a single artifact view and never validates process existence against other kernel sources, so it lacks the cross-reference logic required to confirm concealment.

volatility -f memory.dmp --profile=Win10x64 pslist

Why wrong: pslist walks the kernel's doubly-linked list of active EPROCESS objects, which is precisely the structure that DKOM-based rootkits manipulate to unlink a process and hide it from the system. Consequently, it merely enumerates what the kernel has been made to expose and cannot detect a process removed from this list while still executing in memory.

volatility -f memory.dmp --profile=Win10x64 pstree

Why wrong: pstree reconstructs parent-child relationships from the same active process list that pslist traverses, so if a rootkit unlinks a process from that list, the process simply vanishes from the tree with no trace of its prior existence. It is valuable for analyzing process hierarchy and spotting anomalous parentage, but it is not designed to identify hidden or unlinked processes.

The file's creation timestamp in the directory entry

Why wrong: The creation timestamp (birthtime) stored in the APFS directory entry records the original creation time of the file on the volume. When a file is moved to Trash, the filesystem does not update this timestamp; the rename operation into the .Trashes directory only changes the parent directory entry, leaving the inode's creation metadata intact. Therefore, this value reflects when the file was first created, not when it was trashed, and it cannot be used as evidence of a deletion event.

The .DS_Store file in the Trash folder

Why wrong: .DS_Store files are Finder-generated metadata that store the custom view preferences of a folder window, including icon positions, sort order, and background settings. When a file is moved to Trash, the Finder may rewrite the .DS_Store files of the affected folders to update the visual layout, but these files do not contain any per-file deletion timestamps or a log of move operations. Consequently, .DS_Store data can only show that a folder was open or customized, not establish when a specific file was trashed, and it is not a reliable forensic source for deletion timelines.

The 'com.apple.metadata:kMDItemWhereFroms' extended attribute

Why wrong: The extended attribute 'com.apple.metadata:kMDItemWhereFroms' is a spotlight metadata field that records where a file came from, typically the download URL or the application that created it. It is not updated when a file is moved to Trash; it remains attached to the inode as a static provenance tag. Because it contains no information about the file's removal or relocation, it cannot indicate when or whether the file was moved to the Trash, though it may be useful in other forensic contexts such as proving a file's origin.

Mount the two disks in a Linux mdadm array with a missing disk

Why wrong: This can work only if the two remaining disk images retain intact mdadm superblocks and metadata, and even then mdadm must be invoked with the correct chunk size, layout, and parity algorithm to map the degraded array. The assembly process does not itself create the missing data; it merely presents the surviving devices to the kernel, which then performs the same bitwise XOR reconstruction internally. Thus it is a valid delivery mechanism but not the underlying recovery principle.

Use dd to concatenate the two disk images linearly

Why wrong: Concatenating the images with dd simply appends the raw byte streams end-to-end, completely ignoring the RAID 5 striping pattern and the rotating parity placement. The surviving disk images contain interleaved stripe units, so a linear concatenation yields a meaningless sequence of data and parity blocks where the missing disk's blocks are omitted entirely. This operation would corrupt any notion of logical block order and cannot reconstruct the failed disk's content.

Use a tool like R-Studio to perform a virtual RAID rebuild

Why wrong: R-Studio's virtual RAID rebuild feature can reconstruct a failed RAID 5 volume from the two remaining images by letting the user specify stripe order and parity and then calculating the missing blocks. However, it is a higher-level forensic application that performs the actual recovery by applying the same XOR calculation to the corresponding sectors. Describing this as 'the approach' is overly tool-specific; without the XOR computation the virtual rebuild cannot produce any recovered data.