How to Calculate and Verify File Hashes
Practical guide to hashing files for evidence integrity. Command-line tools, forensic software, and verification procedures.
Why hashing matters
A hash is a cryptographic fingerprint of a file. Change one byte anywhere in the file and the hash changes completely. This property proves evidence integrity. You hash a seized drive, work on a copy, hash it again before trial. Matching hashes prove nothing changed. Different hashes mean something was altered.
Courts accept hash verification as proof of integrity. Defense attorneys cannot claim you planted evidence if you can show the hash matches what you calculated at seizure. But you must document the process correctly. Sloppy hashing procedures invite challenges.
Which algorithm to use
SHA-256: Current standard. Use this for all new cases. 64-character hexadecimal output. Cryptographically secure. Courts recognize it. Command-line tools support it universally.
SHA-512: Stronger than SHA-256 but slower. Use for extremely sensitive cases or evidence you expect to store for decades. 128-character output. Overkill for most work.
MD5: Fast but broken. Collisions are possible (two different files producing same hash). Do not use MD5 as sole hash. If you must use it (old case files, compatibility with legacy systems), always include SHA-256 as well.
SHA-1: Also broken. Theoretical attacks demonstrated in 2017. Avoid for new cases. If you encounter SHA-1 hashes in old evidence, recalculate using SHA-256 and document both.
Command-line hashing: Windows
Windows includes certutil, a built-in hashing tool. Open Command Prompt or PowerShell. Navigate to directory containing the file. Run: certutil -hashfile filename.ext SHA256
Output shows the hash value (64 characters for SHA-256). Copy this into your case notes using Forensic Notes with automatic timestamp. Example: "Evidence file suspect_laptop_image.E01 SHA-256 hash: a3f5b1c2..." Document date, time, who calculated it, what tool was used.
For MD5 (if needed): certutil -hashfile filename.ext MD5. Always calculate both MD5 and SHA-256 if compatibility requires MD5.
Batch processing multiple files: Create text file listing all files, use PowerShell script to loop through and calculate hashes, output to CSV. Saves time when imaging dozens of evidence items.
Command-line hashing: Mac and Linux
Mac and Linux include shasum or sha256sum commands. Open terminal. Navigate to file directory. Run: shasum -a 256 filename.ext or sha256sum filename.ext
Output format: hash value, then filename. Copy hash into documentation. Verify you copied correctly (hashes are long, easy to mistype one character which invalidates everything).
For MD5: md5 filename.ext on Mac or md5sum filename.ext on Linux.
Hashing entire directory tree: find . -type f -exec shasum -a 256 {} \; > hashes.txt - creates file listing every file's hash. Useful for verifying entire evidence directory remained unchanged.
Forensic tool hashing
FTK Imager: Automatically calculates hashes during imaging. Shows both MD5 and SHA-1 (unfortunately not SHA-256 in older versions). Verify Image feature compares current hash to original. Green checkmark means match. Red X means file changed.
EnCase: Hash Analysis feature calculates hashes for all files in case. Export hash list to CSV. Compare against NSRL database to filter known good files or custom hash sets to identify specific files of interest.
Autopsy: Calculate hashes during ingest (File Ingest Modules > Hash Lookup). Supports MD5, SHA-1, SHA-256. Results stored in case database. Search by hash to find files even if renamed or moved.
X-Ways Forensics: Compute Hash context menu option. Multiple algorithms simultaneously. Hash database matching against NSRL, ProjectVIC, custom sets. Fast hashing using multiple CPU cores.
Verification procedure
Calculate hash immediately after evidence seizure or imaging. Record hash value in case notes with timestamp, tool used, algorithm, who calculated it. Store original evidence securely. Work only on verified copy.
Before analysis, verify copy hash matches original. If hashes differ, do not use that copy. Re-image from original. Document why first copy failed verification (corruption during transfer, bad storage media, human error).
Before court, recalculate hash of evidence. Compare to original hash from seizure. Matching hashes prove integrity throughout chain of custody. Use Forensic Notes to document each verification step with automatic timestamps creating audit trail.
If hashes do not match, investigate immediately. Check if you are hashing correct file. Verify file was not opened or modified. Review access logs. If evidence was genuinely altered, document when, how, by whom, and why. Notify prosecutor. They decide whether to proceed or withdraw evidence.
Common mistakes
Hashing file system instead of physical drive. If you hash Windows partition (C:\) instead of physical drive image, you miss unallocated space, deleted files, hidden partitions. Hash the complete physical image, not logical partitions.
Copying hash value incorrectly. One wrong character invalidates verification. Copy-paste instead of typing. If you must type (reading hash from printed report), have second person verify character by character.
Hashing file after modification. You open forensic image in EnCase to preview contents. EnCase creates case database files and temp files. If you hash entire case directory now, hash includes these new files. Hash the original evidence file only, not the working directory.
Using online hash calculators for evidence. Never upload evidence files to websites. Hash calculations happen locally using command-line tools or forensic software. Online calculators cannot be trusted and violate evidence security.
Not documenting hash calculation process. You have the hash value but no record of when you calculated it, what tool you used, or what file you hashed. Courts want process documentation, not just results.
Hash collision and attacks
MD5 collisions are practical (different files producing same MD5 hash). Researchers demonstrated this in 2004. SHA-1 collisions demonstrated in 2017. This is why courts and forensic standards moved to SHA-256.
SHA-256 collisions are theoretically possible but computationally infeasible with current technology. Would require billions of years on current computers. For forensic purposes, SHA-256 collision is not realistic threat.
If defense argues hash collision possibility, explain the math. SHA-256 has 2^256 possible outputs (more atoms than exist in observable universe). Finding collision by chance is impossible. Deliberately creating collision is beyond current computational capability.
Documenting hash values
Record complete information: File name, file path, file size (bytes), hash algorithm (SHA-256, MD5, etc.), hash value (all characters, verified), date and time calculated (with timezone), tool used (certutil, shasum, FTK Imager version X.X), person who calculated it (name and title), purpose (initial seizure, pre-analysis verification, pre-trial verification).
Use Forensic Notes to create structured hash documentation entries. Automatic timestamps prove when hash was calculated. Audit trail shows hash values cannot be edited after entry without detection. Export reports showing complete hash verification history for court.
For free hash calculation and verification, use our Forensic Hash Calculator tool. Runs entirely in your browser (no uploads), calculates multiple algorithms simultaneously, generates verification reports you can save to case files.
Related resources
Related pages:Hash Values Explained | Digital Evidence Guide | Documenting Digital Evidence
Related articles:Forensic Report Writing | Extracting Email Headers
Free tool:Forensic Hash Calculator
Automatic Hash Documentation
Forensic Notes lets you document hash values with automatic timestamps and audit trails. Create verification records that prove integrity throughout the investigation.