What is an acquisition hash?

An acquisition hash is the cryptographic hash value computed from the forensic image file after acquisition is complete.[2] It serves as a digital fingerprint of the acquired data and is recorded in the acquisition log at the time of imaging. When you verify an image later, you re-compute this hash using the same algorithm and compare it to the recorded value; a match confirms that the image has not been altered since acquisition.[2] Some sources distinguish this from the source hash, which is computed from the data stream as it is read from the original device; ideally, these two hashes match, indicating that no data was lost or corrupted during the acquisition process.

Why might a re-computed image hash not match the hash recorded during acquisition?

A re-computed image hash should match the original recorded hash if the image file has not been altered or corrupted. However, if the newly computed hash differs from the recorded value, it signals that the image has changed since acquisition, either due to intentional modification, accidental corruption, storage failure, or file system damage. It is also possible (though less common) that a hash mismatch reflects an error in how the original hash was recorded or computed—for example, if only part of the file was hashed originally, or if the wrong algorithm was used. In any case, a mismatch requires investigation before the image can be relied upon for examination.

What is the difference between hashing the source and hashing the image?

The source hash (or acquisition stream hash) is computed from the raw data as it is read from the original device during the acquisition process.[1] The image hash is computed from the forensic image file that results from acquisition.[1] In a normal acquisition, these two hashes should be identical, indicating that all the data read from the source was successfully written to the image file without loss or corruption. If the two hashes differ, it suggests that data loss or corruption occurred during the acquisition—for example, due to read errors, bad sectors, Host Protected Areas, or Device Configuration Overlays that prevented identical data from being read.[1]

What should an acquisition log record about hashing?

The acquisition log must record the hash value(s) computed during or immediately after acquisition, the specific cryptographic algorithm used (such as SHA-256 or MD5), the date and time of hashing, and any error logs or anomalies encountered during the acquisition process.[1] It should also include sufficient information to allow another qualified examiner to understand what was acquired, how it was acquired, and whether the process succeeded—including any limitations or failures that prevented certain data from being read.[1] This documentation ensures that verification can be performed reliably later and that any problems are transparent to opposing counsel, auditors, or the court.

September 23, 2026 · Hash Verification & Integrity

How to Verify a Forensic Image Hash

To verify a forensic image hash, you re-compute the hash of the acquired image file using the same algorithm that was used during acquisition, and compare the result to the hash value recorded in the acquisition log. If the values match, the image has not been altered since acquisition; if they differ, integrity has been compromised. This verification process is essential to establishing that evidence has not been corrupted or modified between the moment of acquisition and the moment of examination.

What Verification Means

Verification, in forensic practice, is the validation of the integrity of acquired data by comparing the hash of the acquired data to the hash of the acquisition stream or source data.[1] The purpose is straightforward: to determine whether data has changed since the hash value was calculated.[3] In the context of digital evidence, this is not an optional refinement. It is foundational to maintaining the chain of custody. Hashes only provide this protection from the time the hash is made and depend on the hash being stored securely.[3] A proper chain of custody starts from collection—even before the hash is made and secured. Recommended practice calls for hashes to be made as early as possible during the collection process.[3]

The sensitivity of the mechanism is worth emphasizing at the outset. Cryptographic hashes are extraordinarily sensitive: the change of even one bit will cause the hash to be completely different.[4] This means that verification is a binary question. Either the hash values match exactly, or they do not. There is no "close enough." The integrity of the image is either confirmed or it is not.

Two Hashes: Source and Image

Forensic image acquisition produces two distinct hash values, and understanding the difference between them is central to understanding verification.

The acquisition stream hash (also called the source hash) is computed from the data as it is read from the subject device during the acquisition process.[1] This hash represents the raw data flowing from the source media at the moment of acquisition.

The image hash is computed from the forensic image file itself after acquisition is complete.[2] This is the hash value that is typically stored in the forensic image container, the acquisition log, or the case management system.

During a normal, undisturbed acquisition, these two hashes should match. If they do not, it signals that data loss or corruption occurred between the moment the source was read and the moment the image was written to storage.

Why Hashes May Not Match: A Critical Real-World Caveat

In practice, examiners sometimes encounter hash mismatches that do not indicate tampering or misconduct, but rather reflect the physical or logical state of the source media at the time of acquisition.

The process of verification might not verify all data as read from the subject media.[1] Several scenarios can produce legitimate hash mismatches:

Damaged sectors: Media with read errors, bad sectors, or physical damage may not yield identical data on successive reads. If the acquisition tool cannot read a sector on the first pass but succeeds on a second attempt—or skips it entirely—the resulting image hash will differ from the original acquisition hash.

Host Protected Areas (HPAs): Some storage devices reserve areas that are not normally accessible to standard read commands. An acquisition tool may or may not gain access to these areas depending on the tool, the device, and the method used.

Device Configuration Overlays (DCOs): Storage manufacturers sometimes implement firmware that masks certain physical sectors or reallocates data, making it impossible for an external tool to read the exact sequence of bytes that was read initially.[1]

These scenarios are not failures of the verification process; they are limitations inherent in the physical acquisition of damaged or specially configured media. When a hash mismatch is encountered, the examiner's responsibility is to investigate the cause, not to assume the image has been altered.

The Verification Process: Step by Step

Verification follows a straightforward protocol:

Obtain the recorded hash value: This is the hash value that was computed during or immediately after acquisition and recorded in the acquisition log, evidence manifest, or case file. Note the algorithm used (MD5, SHA-256, SHA-512, or other). The hash value must be retrieved from a secure, documented source.

Select the same algorithm: Use the same cryptographic hash algorithm that was used to create the original hash. It is not acceptable to substitute MD5 for SHA-256 or vice versa. The algorithm must match exactly.

Compute the hash of the acquired image: Use a forensic tool (or a general-purpose hashing utility) to compute the hash value of the forensic image file. Process the entire file, not a sample or excerpt.

Compare the values: Place the newly computed hash and the recorded hash side by side and compare them character for character. If they are identical, verification succeeds. If they differ in any way—even a single digit—verification fails.

Document the result: Record whether verification succeeded or failed, the algorithm used, the date and time of verification, and the identity of the person who performed it.

Why Verification Matters for Later Examination

A forensic image may be examined once, or it may be re-examined months or years after acquisition. If the data contained within the forensic image requires reexamination, verification can ensure the integrity of the data has not been compromised between examinations.[2]

This is why hashing is not merely an acquisition procedure. Best practice calls for hashing to be performed prior to and subsequent to a copy function, and also prior to storage, for later comparison and integrity verification.[6] Each time an image is accessed, copied, stored, or transmitted, the risk of inadvertent corruption or deliberate alteration is present. A hash value recorded at the time of acquisition serves as a permanent baseline against which the state of the image can be verified at any later point.

Documentation and Logging Requirements

Verification is only as reliable as the documentation that supports it. SWGDE standards require that examiners review acquired data to verify the acquisition of the intended items, review output logs or error logs for indications of failures in the acquisition process, and document (and resolve if possible) those failures as appropriate.[1]

The acquisition log must record:

Both the acquisition stream hash and the image hash (if they differ)
The cryptographic algorithm(s) used
The date and time of hashing
Any error logs or anomalies encountered during acquisition
The identity of the person who performed the acquisition
Information sufficient for another qualified examiner to understand what was acquired, how it was acquired, and whether the process succeeded

These records are not incidental documentation. They are evidence in their own right, and they must be preserved and made available to opposing counsel, auditors, or courts as circumstances require.

Practical Verification: A Worked Example

Consider an illustrative scenario (not a real case):

On [Date], a forensic examiner acquires a storage device using forensic acquisition software. The tool records two hash values in the acquisition log:

Source (acquisition stream) hash: a1b2c3d4e5f6... [SHA-256]
Image file hash: a1b2c3d4e5f6... [SHA-256]

The hashes match. The image is stored and the log is signed and sealed.

Six months later, another examiner needs to verify the image before beginning analysis. That examiner:

Locates the acquisition log and notes the image hash: a1b2c3d4e5f6... [SHA-256]
Computes the SHA-256 hash of the stored image file
Obtains the result: a1b2c3d4e5f6... [SHA-256]
Compares: match confirmed
Documents the verification in the case file with the date, algorithm, examiner identity, and result

The image is verified to be unchanged since acquisition. Examination may proceed.

By contrast, if the newly computed hash had differed from the recorded value, verification would have failed. The examiner would have been required to investigate the cause before proceeding, and likely to notify supervisors and the case attorney.

Common Verification Errors to Avoid

Examiners should be alert to several common pitfalls:

Algorithm mismatch: Computing a SHA-256 hash and comparing it to a recorded MD5 hash will always appear to fail, even if the image is unaltered. The algorithms must match.

File versus container: Verifying the hash of a forensic image container file (such as an .E01 file) will yield a different hash than verifying the logical content inside the container. Ensure you are hashing the correct object.

Partial hashes: Some tools offer options to hash only a portion of a file. Always hash the entire file unless there is a documented reason and procedure for doing otherwise.

Case sensitivity: Hash values are typically displayed in hexadecimal notation. Some systems display the letters as uppercase (A–F), others as lowercase (a–f). The case of the letters is insignificant; both representations refer to the same value. Verify that the comparison accounts for this, or normalize the case of both values before comparing.

Verification and the Broader Chain of Custody

Hash verification establishes one link in the chain of custody. It demonstrates that the image has not been altered since the time the hash was recorded. But it does not, on its own, establish the chain of custody backward to the original device or forward to the present moment.

Verification is most powerful when embedded in a documented process: the device is acquired, the hash is recorded immediately, the image is stored in a secured location with access logs, and the hash is verified each time the image is accessed or copied. This creates a series of verification checkpoints. A single matching hash establishes integrity at one moment in time; a series of matching hashes across multiple examinations and transfers creates a stronger evidentiary foundation.[5]

Testing Tools and Verification Standards

Any tool used to compute or verify a hash must itself be reliable. SWGDE standards require that hashing tools be tested by comparing the hash value of original selected data to the hash value of acquired data.[7] Many forensic platforms include built-in hash verification functions; examiners should consider whether the platform itself has been validated according to published standards.[7]

For critical verifications, many examiners use independent hashing utilities (such as command-line tools available on most operating systems) to compute hashes separately, then compare the results. This approach reduces the risk that a single tool failure will go undetected.

Conclusion

Hash verification is a straightforward but essential procedure: compute the hash of the image using the original algorithm, compare it to the recorded hash, and document the result. When verification succeeds, you have confirmation that the image is in the same state as the moment it was acquired. When it fails, you have immediate notice that something has changed, whether due to corruption, storage failure, or other causes. In either case, the verification process creates a verifiable record of the image's integrity at a defined moment, which is the foundation upon which the reliability of downstream examination rests.

Common questions

What is an acquisition hash?: An acquisition hash is the cryptographic hash value computed from the forensic image file after acquisition is complete.[2] It serves as a digital fingerprint of the acquired data and is recorded in the acquisition log at the time of imaging. When you verify an image later, you re-compute this hash using the same algorithm and compare it to the recorded value; a match confirms that the image has not been altered since acquisition.[2] Some sources distinguish this from the source hash, which is computed from the data stream as it is read from the original device; ideally, these two hashes match, indicating that no data was lost or corrupted during the acquisition process.
Why might a re-computed image hash not match the hash recorded during acquisition?: A re-computed image hash should match the original recorded hash if the image file has not been altered or corrupted. However, if the newly computed hash differs from the recorded value, it signals that the image has changed since acquisition, either due to intentional modification, accidental corruption, storage failure, or file system damage. It is also possible (though less common) that a hash mismatch reflects an error in how the original hash was recorded or computed—for example, if only part of the file was hashed originally, or if the wrong algorithm was used. In any case, a mismatch requires investigation before the image can be relied upon for examination.
What is the difference between hashing the source and hashing the image?: The source hash (or acquisition stream hash) is computed from the raw data as it is read from the original device during the acquisition process.[1] The image hash is computed from the forensic image file that results from acquisition.[1] In a normal acquisition, these two hashes should be identical, indicating that all the data read from the source was successfully written to the image file without loss or corruption. If the two hashes differ, it suggests that data loss or corruption occurred during the acquisition—for example, due to read errors, bad sectors, Host Protected Areas, or Device Configuration Overlays that prevented identical data from being read.[1]
What should an acquisition log record about hashing?: The acquisition log must record the hash value(s) computed during or immediately after acquisition, the specific cryptographic algorithm used (such as SHA-256 or MD5), the date and time of hashing, and any error logs or anomalies encountered during the acquisition process.[1] It should also include sufficient information to allow another qualified examiner to understand what was acquired, how it was acquired, and whether the process succeeded—including any limitations or failures that prevented certain data from being read.[1] This documentation ensures that verification can be performed reliably later and that any problems are transparent to opposing counsel, auditors, or the court.

Sources

[1] Best Practices for Computer Forensic Acquisitions — Scientific Working Group on Digital Evidence (SWGDE)
[2] Best Practices for Digital Evidence Collection — Scientific Working Group on Digital Evidence (SWGDE)
[3] SWGDE Position on the Use of MD5 and SHA1 Hash Algorithms in Digital and Multimedia Forensics — Scientific Working Group on Digital Evidence (SWGDE)
[4] Digital Evidence Preservation — National Institute of Standards and Technology (NIST)
[5] Guidelines for Forensic Image Analysis — Scientific Working Group on Digital Evidence (SWGDE)
[6] Best Practices for Maintaining the Integrity of Imagery — Scientific Working Group on Digital Evidence (SWGDE)
[7] Minimum Requirements for Testing Tools Used in Digital and Multimedia Forensics — Scientific Working Group on Digital Evidence (SWGDE)
[8] Federal Rule of Evidence 901 — Authenticating or Identifying Evidence — Legal Information Institute, Cornell Law School
[9] NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response — National Institute of Standards and Technology
[10] FIPS 180-4 — Secure Hash Standard (SHS) — National Institute of Standards and Technology
[11] FIPS 202 — SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions — National Institute of Standards and Technology
[12] Computer Forensics Tool Testing Program (CFTT) — National Institute of Standards and Technology

CustodyTrack creates tamper-evident chain-of-custody records that any third party can verify. See how it works →

For this audience: Chain of Custody for Corporate Legal, IT & eDiscovery

← All guides