CHFI Evidence Acquisition and Duplication 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 dd command used a different block size

  Why it's wrong here

  The dd tool's block size (bs) determines how many bytes are read and written per I/O operation, but the byte sequence read from the source drive is completely independent of this chunk size. Hash functions like MD5 or SHA-1 operate on the stream of bytes, not on I/O boundaries, so as long as the same logical sectors are read without errors, the resulting image will have an identical hash. A different block size could affect performance or cause read errors on failing media, but it cannot by itself produce a valid image with a different hash. Therefore, a block size difference would not explain a sudden hash mismatch.

• ✓

  The write blocker malfunctioned and allowed writes to the original drive

  Why this is correct

  A write blocker is a dedicated hardware or software mechanism that intercepts and blocks all write commands from the host system to the suspect drive during acquisition. If it malfunctions, the operating system or the acquisition tool may write temporary files, filesystem metadata, or other data onto the original evidence drive. Any such unintended write changes the drive's contents, so when the examiner later computes a hash of the original drive, it will no longer match the hash of the forensic image taken earlier. This is the only option that directly explains how the source itself could be altered, making it the correct cause of the hash discrepancy.

• ✗

  The dd command compressed the output

  Why it's wrong here

  The dd utility is a bit-for-bit copy tool that writes raw disk data to the output file by default; it does not apply any compression unless it is explicitly piped through a compress utility like gzip. Even if compression were used, it would be a lossless transformation, and a properly verified image would be decompressed before hashing, producing the same digest as the original. A compressed output file would have a different hash than the raw source, but that reflects a different file format, not a modification of the source data, and it would not be attributed to the dd command itself. Thus, compression cannot explain a hash mismatch between the original drive and the forensic image.

• ✗

  The image file was corrupted during transfer

  Why it's wrong here

  A corrupt transfer usually manifests as read errors, I/O failures, or incomplete file writes that cause the acquisition tool to stop or produce a truncated image, and forensic tools typically verify block-level checksums during the copy. If the image file were corrupted in transit, the hash of the received file would be randomly different, but the comparison used in a proper forensic workflow involves hashing the source separately and hashing the image after the transfer; a bit-flip corruption would be detected as an error, not as a clean, consistent hash mismatch. Moreover, the question implies the image was successfully created and hashed, so corruption during transfer would require the corruption to occur before the image hash was computed, which is a different stage than the source-to-image transfer. Therefore, this option is not a plausible cause of the observed hash mismatch.