CHFI Computer Forensics Fundamentals and Process 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.

• ✓

  Compute the SHA-256 hash of the image and compare it to the original drive's hash

  Why this is correct

  Computing the SHA-256 hash of the acquired image and comparing it against the hash computed from the original drive is the gold standard for forensic integrity verification. SHA-256 is a NIST-approved cryptographic hash function that produces a unique 256-bit digest; because it is collision-resistant and preimage-resistant, even a single flipped bit in the image will cause a completely different digest. This comparison verifies that the acquisition process created a bit-for-bit identical copy, providing a defensible basis for subsequent analysis and court testimony.

• ✓

  Compute the MD5 hash of the image and compare it to the original drive's MD5 hash

  Why this is correct

  Computing and comparing MD5 hashes is a valid integrity check and has been the traditional forensic standard for decades, but MD5 is no longer considered collision-resistant. Since 2004, researchers have demonstrated that crafted inputs can produce identical MD5 digests, so an adversary could theoretically alter the image while preserving its hash. In practice, however, MD5 remains widely used for fast verification because real-world forensic acquisitions do not involve deliberate hash collision attacks; nonetheless, pairing MD5 with a stronger algorithm like SHA-256 is recommended for robust assurance.

• ✗

  Verify the cyclical redundancy check (CRC-32) of the image file

  Why it's wrong here

  Verifying the CRC-32 checksum is unsuitable for forensic integrity verification because CRC-32 is an error-detecting code, not a cryptographic hash function. It produces only a 32-bit value using polynomial division, making collisions simple to construct and providing no resistance to adversarial tampering—an attacker can easily modify data and recalculate the CRC to match. Even for accidental bit errors, CRC-32 has significantly higher collision probability than a 256-bit hash, and it lacks the one-way and avalanche properties required to prove evidentiary integrity.

• ✓

  Use the 'verify' function within FTK Imager which automatically computes and compares hashes

  Why this is correct

  FTK Imager's 'Verify' function is a built-in, automated integrity check that recomputes one or more cryptographic hashes of the acquired image and compares them against the hash values stored in the image metadata during the original acquisition. This is a correct method because it performs the same type of secure hash comparison as a manual hashing process, but eliminates transcription errors and ensures consistency with the acquisition workflow. It typically verifies MD5 and SHA-1/SHA-256, giving the examiner immediate confirmation that the image has not been altered since capture.

• ✗

  Check the file size of the image matches the original drive's capacity

  Why it's wrong here

  Checking that the image file size matches the original drive's capacity is insufficient for forensic integrity because file size alone does not reflect the actual content of the data. Two completely different datasets can have identical lengths, and image formats such as E01 or sparse raw images may compress or omit empty sectors, so the file size often doesn't even equal the drive's nominal capacity. No bit-level conclusion can be drawn from size; only a cryptographic hash comparison can detect whether the image content faithfully matches the source drive or has been modified.

Go deeper

Related to this question