Why Digital Forensics Runs on Hashes (SHA-512 in Plain English)

Imagine handing a hard drive to a court, an auditor or your company's legal team and saying, "This is exactly what was on the device when we collected it." The next question will be: "How do you know?"

In digital forensics, that question matters as much as anything you find on the device. Digital evidence is easy to change, sometimes just by opening a file or switching a device on. If you can't show that the evidence you analyzed is identical to the evidence you collected, your findings can be challenged, or thrown out entirely.

The tool investigators use to answer that question is the cryptographic hash. When I built Forensic Raptor, an Android forensics tool, for my final-year engineering project at Staffordshire University, verifying evidence with SHA-512 hashes was one of the first features I designed. This article explains why.

What a hash function does

A hash function takes any input, whether a single word, a photo or a 29 GB disk image, and produces a fixed-length string of characters called a hash, digest or checksum.

A good cryptographic hash function has a few important properties:

1. Same input, same output, every time. Hash the same file today and next year, and you'll get the same result.
2. Tiny change, totally different output. Change one character in a document, or one bit in a disk image, and the hash changes completely. There's no "close enough."
3. One-way. You can't work backwards from a hash to recreate the original data.
4. Collision-resistant. It should be practically impossible to find two different inputs that produce the same hash.

Think of it as a fingerprint for data. Two files with the same fingerprint are, for practical purposes, identical. If the fingerprint changes, the file changed.

What SHA-512 is

SHA-512 is a member of the SHA-2 family of hash functions, published by the U.S. National Institute of Standards and Technology (NIST). It produces a 512-bit hash, usually written as 128 hexadecimal characters.

You may also see MD5 and SHA-1 in older forensic tools and reports. Both are now considered weak, because researchers have demonstrated practical ways to create collisions: different inputs with the same hash. That doesn't mean every MD5 hash is useless, but it does mean they shouldn't be relied on alone to prove integrity. Modern practice uses SHA-256 or SHA-512, and many tools record more than one hash for extra assurance.

I chose SHA-512 for Forensic Raptor because it offers a very large output size, strong collision resistance and wide support across operating systems and programming languages, including Python's standard library.

How hashes protect evidence

In a forensic investigation, hashing happens at key points.

At acquisition. When the investigator creates an image, a bit-for-bit copy of the device's storage, they calculate its hash immediately. That hash is recorded in the case notes along with the date, time, investigator and method used.

Before analysis. Investigators work on a copy of the image, never the original. Before starting, they hash the working copy and confirm it matches the original hash.

After analysis. Hashing the image again at the end shows that the analysis process didn't alter the evidence.

When evidence changes hands. Every time evidence is transferred, to another examiner, a lab or legal counsel, the recipient can hash it and compare. A match confirms nothing changed in transit.

Each of these steps becomes part of the chain of custody: the documented history of who handled the evidence, when and what they did with it. Hashes are what make that chain verifiable rather than just a matter of trust.

How I used SHA-512 in Forensic Raptor

Forensic Raptor is a Python command-line tool that connects to an Android device over ADB (Android Debug Bridge). It extracts a full image of the device's non-volatile memory and then analyzes that image for data from e-commerce applications, using custom regular expression patterns to find things like order and payment-related records.

Evidence integrity was built into the workflow:

1. Acquire the image from the device.
2. Hash the image with SHA-512 straight away and record the value in the case file.
3. Verify the hash before every analysis run, so the tool confirms it's working on unaltered evidence.
4. Report the hash in the case-based report, alongside the findings and device details such as properties, contact list and battery health.

In testing on Kali Linux, the tool analyzed a 29 GB device image in about 45 minutes. Hashing an image that size takes time, because the function has to read every byte. That's the point: the hash represents the entire image, so any change anywhere in it would be detected.

Building it taught me a practical lesson. Integrity checks aren't a feature you add at the end. They need to be part of the process from the moment evidence is collected, or there's a gap that can't be closed later.

Hashes beyond forensics

The same idea appears throughout security and IT, often in places people don't notice.

• Software downloads. Many vendors publish hashes for their installers. Comparing the hash of what you downloaded against the published value confirms the file wasn't corrupted or tampered with.
• Malware identification. Security tools and threat intelligence feeds share hashes of known malicious files. If a file on your system matches a known bad hash, you've found a problem without needing to analyze it from scratch.
• File integrity monitoring. Security tools hash critical system files and alert when those hashes change unexpectedly.
• Password storage. Well-designed systems don't store passwords; they store hashes of them, using algorithms specifically designed for passwords, which are deliberately slow and use a unique random value called a salt. General-purpose hashes like SHA-512 on their own aren't the right choice for this job, which is a useful reminder that each hash function has a purpose.
• Backups and transfers. Comparing hashes before and after copying large files confirms nothing was lost or corrupted.

A short walkthrough: handing evidence to a colleague

Here's how hashing works in a simple, realistic hand-off.

An investigator images a laptop's drive and records its SHA-512 hash in the case notes. The image is copied to an encrypted external drive and passed to a second analyst. Before opening it, the second analyst hashes the copy. The two values match character for character, so the analyst records "hash verified" with the date and time, and starts work on a further working copy.

Now imagine the values didn't match. That doesn't automatically mean tampering. The copy may have been interrupted or the external drive may be faulty. But it does mean the copy can't be trusted. The analyst stops, documents the mismatch and goes back to the original image for a fresh copy. Nothing is analyzed until the hashes agree.

That discipline, never working on evidence you haven't verified, is what makes findings defensible later.

Common mistakes with hashes

• Hashing too late. If the first hash is taken after someone has already browsed the files, the hash proves only that nothing changed after that point.
• Recording the hash somewhere it can be edited unnoticed. Hashes belong in signed case notes or a controlled case management system, not a loose text file next to the evidence.
• Relying on a single weak algorithm. MD5 alone is no longer enough. Use SHA-256 or SHA-512, and record the algorithm used.
• Forgetting the original. Analysis should always happen on a verified copy. The original stays sealed and untouched.
• Comparing by eye. Checking the first and last few characters isn't verification. Let the tool compare the full values.

Try it yourself

You can calculate a SHA-512 hash on any computer in seconds.

• Windows (PowerShell): Get-FileHash .\file.iso -Algorithm SHA512
• macOS: shasum -a 512 file.iso
• Linux: sha512sum file.iso

Try hashing a text file, then change a single letter and hash it again. Seeing the result change completely is the best way to understand why investigators trust hashes.

The takeaway

Hashing is one of the simplest ideas in security and one of the most important. It turns "trust me, I didn't change anything" into something anyone can check for themselves. In forensics, that difference decides whether evidence holds up.

If you work in IT, you probably already use hashes without thinking about it. Next time you see one, remember that it's doing a quiet but essential job: proving that what you have is exactly what you think it is.

Have you ever used a hash to verify a download or a file transfer? Did it ever catch a problem?