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.

• ✗

  Use EnCase to acquire each disk separately and mount as a RAID volume

  Why it's wrong here

  EnCase can acquire each disk and assemble them into a logical RAID volume, but this approach assumes EnCase can correctly determine the disk order and stripe geometry from the existing FTK Imager images. Since the evidence was already acquired with FTK Imager, reacquiring with EnCase introduces extra artifacts and may alter the chain-of-custody workflow. More importantly, merely mounting the disk images as a RAID volume without explicitly validating the stripe size and disk sequence from RAID metadata will likely produce a filesystem that cannot be parsed; EnCase's RAID auto-detection is not guaranteed to recover the exact parameters, especially for proprietary or software RAID layouts.

• ✗

  Simply reorder the disk images alphabetically

  Why it's wrong here

  Reordering the disk images alphabetically is completely arbitrary and will not reflect the actual sequence in which the RAID controller interleaves data blocks. The correct disk order is encoded in RAID metadata structures such as the Linux md superblock, Intel IMSM metadata, or controller-specific headers, which must be parsed to determine the position of each disk in the stripe. If the images are simply sorted by filename, the reconstructed volume will have misaligned stripes, making the filesystem unreadable and potentially corrupting any recovered data.

• ✓

  Reconstruct the RAID by determining stripe size and order, then combine the images

  Why this is correct

  RAID 0 stores data in fixed-size stripes (also called chunks) that are interleaved across the member disks, so reconstructing the logical volume requires knowing two critical parameters: the stripe/chunk size (e.g., 64 KiB, 128 KiB) and the exact order of disks in the RAID set. These parameters are found in the RAID metadata (md superblock, DDF, Intel RST, etc.) present on each disk or can sometimes be inferred from filesystem geometry. Once the stripe size and disk order are determined, the forensic examiner must interleave the data from each disk image at the appropriate byte offsets—combining them in a way that preserves the original block sequence. Only after this de-interleaving can the reconstructed image be parsed by tools like FTK Imager or X-Ways to access the logical filesystem.

• ✗

  Use PhotoRec to carve files from raw images

  Why it's wrong here

  PhotoRec performs file carving by scanning raw disk images for file signatures and reassembling fragments based on internal filesystem structures. In a RAID 0 volume, however, file data is spread across multiple disks in stripe-sized chunks, so the byte stream that PhotoRec sees on any single disk is incomplete and interleaved with data from other files and drives. Without first de-interleaving the RAID, PhotoRec cannot follow the appropriate offset jumps, and it will either recover only partial fragments or produce corrupted files. File carving is a useful last resort for deleted evidence, but it cannot substitute for a proper RAID reconstruction because it ignores the logical block addressing scheme that binds the disks together.

Go deeper

Related to this question