Storage Forensics and File System Analysis practice questions

The drive is failing and needs replacement

Why it fails: 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 it fails: 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 it fails: 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 it fails: FAT32 does not support journaling. (Incorrect)

APFS

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

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: .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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

volatility -f mem.dmp connections

Why it fails: The 'connections' plugin is a deprecated legacy Volatility command that relied on iterating the kernel's exported connection object list, which only works reliably on 32-bit Windows XP/2003. On modern Windows versions the required structures are no longer exported or are actively manipulated, so the plugin fails or returns incomplete data; Volatility now recommends netscan for all connection enumeration.

volatility -f mem.dmp pslist

Why it fails: The 'pslist' plugin enumerates processes by traversing the doubly-linked list of _EPROCESS objects in the kernel, which is a process-listing technique and has nothing to do with network connections. While process enumeration is useful for malware discovery, running pslist would not reveal TCP/UDP endpoints, listening ports, or network artifacts from the memory dump.

volatility -f mem.dmp dlllist

Why it fails: The 'dlllist' plugin walks the PEB (Process Environment Block) of each process to print loaded dynamic-link libraries and their base addresses, which is purely a module enumeration technique. It provides no visibility into the kernel's network structures or socket objects, so it cannot identify connections, listeners, or network sessions in the memory dump.

Journaling in NTFS

Why it fails: NTFS journaling via the $UsnJnl file records changes to the master file table (MFT) to support file system recovery and file indexing, but it is not a per-file data storage location. The journal logs metadata changes and can contain remnants of past activity, yet it does not provide a separate stream where hidden content can be placed. For hiding data, an attacker would use something like an Alternate Data Stream, not the journal itself.

Extended attributes in ext4

Why it fails: Extended attributes (xattrs) in ext4 are key-value metadata pairs used to store things like SELinux labels, ACLs, or arbitrary user data, but they belong to the Linux ext4 filesystem, not NTFS. Since the investigation involves an NTFS volume, ext4 xattrs cannot be the mechanism responsible for hiding data in the recovered files. Furthermore, while both xattrs and ADS can hold auxiliary data, they are fundamentally different implementations on entirely different file systems, so this option does not apply.

Volume shadow copy

Why it fails: Volume Shadow Copy (VSS) is a Windows subsystem that creates point-in-time snapshots of entire volumes for backup and system restore, preserving previous versions of files in a hidden system area. It does not attach supplementary data streams to individual files, so it is not a per-file hiding mechanism. While shadow copies may contain older copies of deleted files, they operate at the volume level rather than as a stream within a specific file's metadata, making them an incorrect answer here.

The FAT entries are encrypted

Why it fails: FAT32 has no native encryption mechanism whatsoever; the file allocation table contains only 32-bit cluster-number links, not data payloads. On file deletion, the OS does not encrypt the FAT entries or any other metadata—it simply zeroes the entries belonging to the deleted file's cluster chain. Any encryption on FAT32 would require an external tool (e.g., BitLocker To Go or VeraCrypt), and that would operate at the volume level, not on individual FAT entries.

The FAT entries are preserved intact

Why it fails: Preserving the FAT entries intact would mean the cluster chain for the deleted file remains fully allocated and linked. FAT32 deletion does exactly the opposite: the directory entry's first byte is changed to 0xE5 to mark it deleted, and each FAT entry in the file's cluster chain is written with 0x00000000 to mark those clusters as free. If the entries were preserved, the clusters would never be available for new files, defeating the purpose of deletion.

The FAT entries are moved to a journal

Why it fails: FAT32 does not possess a journal or transaction log; journaling is a feature of filesystems like NTFS, ext4, or ZFS that records pending metadata changes for crash recovery. Moving FAT entries to a journal would require a data structure that does not exist in the FAT32 specification. Instead, deletion is an in-place, non-atomic update: the directory entry is marked deleted and each FAT chain entry is zeroed directly in the FAT region, with no journaling or rollback capability.

Analyze the USN journal in NTFS

Why it fails: The USN journal is an NTFS-specific change journal, not an ext4 structure, so analyzing it on an ext4 filesystem is a category error. ext4 has no `$Extend\$UsnJrnl` or MFT update sequence arrays, and USN records do not carry ext4 inode information. This option would produce no useful deletion recovery data because the artifact simply does not exist outside Windows/NTFS volumes.

Run PhotoRec to carve unallocated space

Why it fails: PhotoRec uses raw signature carving against unallocated space and deliberately bypasses the filesystem's inode table and directory metadata. While it may recover file content, it cannot recover the original filename, timestamps, ownership, or extended attributes, and it does not leverage the still-valid inode pointers that `debugfs` can use. In this scenario, carving is inferior because it ignores the very metadata structure that enables precise deletion recovery.

Mount the filesystem and copy the file

Why it fails: Mounting the ext4 filesystem and copying the file will fail because a mounted filesystem exposes only the live directory tree; a deleted file has no directory entry and is invisible to normal path-based access. Worse, a read-write mount—or even a read-only mount that still replays the journal—can modify metadata and destroy the inode or block pointers needed for recovery. Forensic recovery should be performed on an unmounted image with metadata-aware tools like `debugfs`.

Sleuth Kit

Why it fails: Sleuth Kit is for file system analysis, not RAM acquisition.

LiME

Why it fails: LiME is for Linux memory acquisition.

dd

Why it fails: dd is a disk imaging tool, not specialized for RAM.

dir /a

Why it fails: The /a switch alters which file attributes (hidden, system, read-only, etc.) are displayed when listing directory contents, but it has no effect on enumerating alternate data streams. It merely filters files based on attribute flag bits in the directory listing, not on the internal NTFS stream metadata associated with each file. Even with /a, any ADS remain completely invisible because this command never queries the stream catalog in the MFT.

fsutil stream query

Why it fails: While fsutil stream query does list named streams, it requires an elevated administrative command prompt and is a low-level system utility that is less convenient for routine triage. It also only works on a single file or directory path at a time, unlike dir /r which can recursively enumerate streams across an entire tree with one command. The question expects the simplest, built-in method, so this administrative tool is not the correct answer.

attrib /s

Why it fails: The attrib command with /s recursively operates on files and directories based on their file attributes—read-only, archive, system, and hidden—but it neither displays nor detects alternate data streams. Attrib reads and modifies the attribute bits in each file's MFT entry, never looking at the list of data attribute records where streams are stored. Therefore it is a classic example of a file metadata tool that is completely blind to ADS.

scalpel

Why it fails: scalpel is a forensic file carving tool that recovers files by scanning raw disk data for known file signatures, such as headers and footers, rather than using filesystem metadata like inodes. It does not have the capability to target a specific inode number, because it deliberately bypasses the filesystem structure and operates on the raw byte stream. Additionally, scalpel is not part of standard Linux installations; it must be installed separately, making it less suitable for a routine analyst working on a stock Linux system. Its signature-based method can also produce false positives and fail on fragmented files, which is why it is not used for inode-directed recovery.

foremost

Why it fails: foremost is another file carving tool that recovers files based on content patterns defined in a configuration file, scanning for known headers and footers. It completely ignores inode tables and other filesystem metadata, so it cannot access a file by its inode number. While foremost is a respected forensic utility, it is not designed for metadata-specific recovery, and it requires manual installation on most Linux systems. Its reliance on file signatures makes it effective for carving unallocated space but inappropriate for the specified task of recovering a file by inode.

icat

Why it fails: icat, part of The Sleuth Kit, can indeed output the contents of a file using its inode number, and it is a powerful tool for forensic analysis of filesystem images. However, it is not a standard Linux tool; The Sleuth Kit is an extra package that must be installed separately, unlike debugfs which ships with e2fsprogs. On a typical ext4 Linux system, debugfs is the more immediately available and standard utility for inode-based recovery. Although icat would technically work, debugfs is the correct and more practical choice for this scenario, especially in a live analysis without pre-installed forensic toolkits.

The file name attribute

Why it fails: The NTFS $FILE_NAME attribute stores a file's name, its parent directory reference, and naming-related timestamps, but it contains no cluster addressing. Its primary forensic role is for incident timeline construction and path reconstruction, not for locating file content. Data runs that map file content to physical clusters reside exclusively in the $DATA attribute, so this option cannot be used to recover the file's actual data.

The standard information attribute

Why it fails: The $STANDARD_INFORMATION attribute is a fixed-length structure that records the file's MACB timestamps, the file owner's SID, DOS file attributes, and flags such as read-only or hidden. Although these metadata fields are essential for forensic timeline analysis and determining file provenance, they contain no logical or physical cluster pointers. Because recovery of file content depends on the $DATA attribute's runlist, standard information alone cannot identify where the file's bytes reside.

The security descriptor

Why it fails: The $SECURITY_DESCRIPTOR attribute defines the discretionary and system ACLs for a file, specifying which users or groups can read, modify, execute, or delete it. In NTFS, these descriptors are often deduplicated and stored centrally in the $SDS file, with the MFT attribute merely referencing a security ID, but never containing allocation data. Understanding the ACL is useful for evaluating hiding or exfiltration by attackers, yet it provides no clue about the physical cluster locations holding file content, unlike the $DATA attribute's data runs.

smartctl

Why it fails: smartctl is a utility built around the SMART (Self-Monitoring, Analysis and Reporting Technology) interface; it retrieves attributes, error logs, and self-test results from a drive. Although it can parse some ATA IDENTIFY DEVICE data, it does not provide a direct command to query or modify the Host Protected Area (HPA), which is controlled by the SET MAX ADDRESS feature set. HPA status is exposed through dedicated ATA commands such as READ NATIVE MAX ADDRESS, not through SMART log pages, so smartctl cannot identify hidden sectors.

dd

Why it fails: dd is a low-level data duplication tool that copies a specified number of blocks from a source to a destination, typically operating on the block device exposed by the operating system. When an HPA is active, the OS presents a truncated device size, so dd can only read and preserve the visible addressable space; any sectors beyond the HPA are simply not enumerated at the ATA layer. It cannot issue the ATA commands needed to detect or remove an HPA, and without those commands hidden regions remain invisible to forensic imaging.

fdisk

Why it fails: fdisk is a partition-table editor that works with the logical block addressing (LBA) geometry already reported by the OS kernel. The kernel obtains the drive's capacity from the ATA IDENTIFY DEVICE response, which honors an active HPA by hiding the protected sectors; fdisk therefore sees only the reduced device size and cannot distinguish between a physically smaller disk and one with an HPA configured. Because it operates entirely on the partition-table layer rather than issuing ATA pass-through commands, any hidden area is never represented in the partition layout fdisk manipulates.

File fragmentation

Why it fails: File fragmentation, while present on SSDs, is not a unique forensic hurdle because SSDs have no mechanical head, so access times are independent of physical location. File systems routinely perform background defragmentation or use log-structured writes, mitigating the issue. Unlike TRIM or wear levelling, fragmentation does not actively destroy or obscure data at the flash level.

Bad sectors

Why it fails: Bad sectors are caused by physical media defects or wear, such as failing NAND cells in an SSD, but they are a hardware reliability issue rather than a forensic data recovery challenge. Modern SSDs employ error-correcting codes and block reallocation to handle bad sectors transparently, so they do not systematically compromise the recovery of deleted files. Unlike TRIM or wear levelling, bad sectors affect only a small percentage of stored data and can usually be imaged with partial reads, making them a minor concern compared to SSD-specific artifacts.

NTFS permissions

Why it fails: NTFS permissions govern which user or group can access a file or folder, controlling read, write, and execute rights at the file system level. They do not affect how data is stored or deleted on the physical medium, nor do they hamper the recovery of residual data from raw blocks. In SSD forensics, permissions are relevant for legal access and chain of custody, but they are not a technical hurdle to data acquisition or analysis.

volatility -f mem.raw pslist

Why it fails: pslist walks the doubly linked list of EPROCESS structures in kernel memory and prints each process's PID, PPID, name, and timing, but it deliberately omits command-line arguments and thread details. For this question, where the goal is to see parent-child process relationships (as in a malware infection chain), pslist's flat PID/PPID output obscures hierarchy and lacks the indentation that reveals which process spawned which. While pslist can show PPID numerically, it does not render the tree structure that pstree does, making it insufficient for quickly identifying process ancestry.

volatility -f mem.raw netscan

Why it fails: netscan is Volatility's plugin for scanning network artifacts (TCP/UDP endpoints, listening sockets, and connections) by inspecting kernel network structures such as _TCP_ENDPOINT and _UDP_ENDPOINT. It is entirely unrelated to process enumeration: it reports network flows like remote IPs and ports, not the running processes themselves. In a forensic examination of a RAM image, netscan might complement a process listing by showing which process is communicating, but it cannot answer a question about process hierarchy or command lines, so it is the wrong tool here.

volatility -f mem.raw cmdline

Why it fails: cmdline is a Volatility plugin that recovers the command line arguments for a single process, not an enumeration of all processes. It requires you to already know the process PID or name (e.g., `volatility -f mem.raw cmdline -p 1234`) or it attempts to dump command lines for every process if invoked without a PID, but its output is a flat list of command-line strings—not a structured process tree with child relationships. Furthermore, cmdline relies on the _EPROCESS.Peb.ProcessParameters structure, and in many cases command-line data is paged out or unavailable, whereas pstree extracts the full process tree from the active process list and parent pointers.

Volume Superblock

Why it fails: The APFS volume superblock (APSB) anchors each volume's object space and stores volume-wide configuration such as the volume UUID, block size, successful mount state, and the object identifier of the volume's root B-tree node. It is read to locate large-scale structures, not to enumerate files; no per-inode data such as ownership or nanosecond timestamps for individual objects resides there. Thus, while its fields may aid forensic validation, it cannot provide the per-file metadata sought in a typical review.

Journal

Why it fails: The APFS journal (the last transaction buffer) is a circular transaction log that captures the before/after state of metadata-block updates in order to guarantee crash consistency. It reflects only recent mutable operations, and its entries are transient and frequently overwritten, so it is not a persistent store of every inode's standard metadata. Forensic conclusions about timestamps and permissions should come from the live inode B-tree, not from reconstructed journal deltas.

Extent Reference Tree

Why it fails: The extent reference tree maps file logical block ranges to on-disk physical block addresses using entries that include starting block number, block count, and owner inode. It exists to support copy-on-write snapshots and physical block allocation, not to describe the file's ownership or timestamps. Therefore it reveals where data resides and possibly fragmentation or snapshot ancestry, but it never supplies per-file metadata.

Using the volume boot record

Why it fails: The volume boot record (VBR) is the first sector of a bootable volume, containing bootstrap code plus the BIOS Parameter Block that defines sectors per cluster, FAT/NTFS metadata locations, and other low-level parameters. Its size is fixed (typically 512 or 4096 bytes) and highly structured; any modification to embed data would destroy the file system's ability to mount or fail integrity checks by disk editors and analysis tools. Also, any bytes placed there would be visible in a simple sector read, making it a completely non-stealthy and invalid hiding location.

Using the MFT resident data area

Why it fails: The MFT resident data attribute stores small file contents directly inside the Master File Table record, but that is an optimization for files that fit within the record's fixed 1 KB (or contiguously up to the record size). Every MFT record is easily parseable via the NTFS file system driver or forensic libraries like libfsntfs; resident data is simply an attribute (DATA) with a resident flag, not a hidden zone. An investigator can list all MFT attributes, including resident ones, so anything placed there is no more hidden than an ordinary file, and the MFT record's presence itself is a disclosure.

Using the USN journal

Why it fails: The USN journal records every change made to files and directories on an NTFS volume, storing metadata like file IDs, change reason flags, and timestamps, but it does not retain file contents. Attempting to hide data by writing into the journal would be nonsensical because the journal itself is generated by the OS and continuously overwritten; also, those writes would appear as journal entries that actually document the tampering. Thus, it is an evidence source for detecting hidden activity, not a place to conceal user data — a forensic examiner uses it to reconstruct what happened, but cannot extract data from it.