CHFI Storage Forensics and File System Analysis Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The failed disk cannot be imaged because it is physically damaged

  Why it's wrong here

  Physical damage to a disk does not categorically prevent forensic imaging; specialized tools such as write-blockers, disk duplicators, or chip-off techniques can often recover data from a failed disk, provided the platters are not destroyed. In the RAID 5 scenario described, the analyst's primary concern is not the failed disk's readability, but that the array controller is likely to initiate a rebuild as soon as a replacement is detected, causing writes across the surviving disks. Thus, this option misstates the core evidence-preservation risk, making it incorrect.

• ✓

  The rebuild process may overwrite unallocated space or remnants of deleted files

  Why this is correct

  In RAID 5, when a disk is missing, the controller regenerates the lost data on the fly from parity on the remaining disks and writes the complete reconstructed dataset to a new disk. This rebuild operation writes across every block of the replacement disk and often touches unallocated space and slack on the other members as the array re-stripes or normalizes, potentially overwriting remnants of deleted files that could be critical evidence. Even if a physical copy of the failed disk is impossible, the evidence on the surviving disks is vulnerable to destruction by the rebuild write process. Therefore, the correct forensic action is to image all member disks first.

• ✗

  RAID 5 arrays cannot be imaged using traditional tools like dd

  Why it's wrong here

  RAID 5 arrays are absolutely imageable with traditional tools like dd when the storage controller or operating system exposes the logical volume as a block device (e.g., /dev/md0 or a hardware array device). The tool operates at the block level and does not care about parity or striping, since the controller or host handles the mapping. The real limitation is not the tool, but the need to interrupt automatic rebuild mechanisms—if the controller rebuilds the array during acquisition, dd may capture an inconsistent or changing state. Hence, this option is incorrect because it conflates tool capability with controller behavior.

• ✗

  The array must be imaged while degraded to preserve evidence

  Why it's wrong here

  Imaging the array while it is in a degraded state is not a preservation requirement; rather, it is simply one permissible status during forensic acquisition. The key to preserving evidence is to prevent write operations—especially the automatic rebuild that would occur when a replacement disk is installed or the controller is reconfigured. Leaving the array degraded for a long time or imaging it while degraded does not itself protect unallocated space or deleted-file remnants any better than imaging it in a healthy state (if that state is stable). The critical mistake is allowing the rebuild to occur before a forensic copy is made, not whether the array is degraded.

Go deeper

Related to this question