Forensics · Lesson 03
Hashing & File Integrity
Learn how cryptographic hashes help identify exact file content, verify working copies, detect changes, and preserve evidence integrity without confusing content identity with user intent.
A hash is powerful because it describes the bytes of a file, not its filename. It is still only one part of a complete forensic explanation.
Lesson Snapshot
Learning objectives
Use hashes as precise file-content evidence
Explain what a cryptographic hash represents and why it is useful in forensic work.
Distinguish file identity from filename, location, ownership, and user intent.
Use SHA-256 style hashes to compare original files, working copies, and later versions.
Understand why even a tiny content change produces a different digest.
Document the algorithm, source path, observation time, and resulting digest correctly.
Use hashes as one piece of evidence rather than treating them as a complete verdict.
Core idea
Hash the content, not the name
Two files can have different names but identical bytes. They can also have the same name while containing completely different content. A secure hash gives you a content-level comparison.
Important limit
Identity is not intent
Even a perfect file match does not prove who downloaded it, who opened it, why it exists, or whether it is safe. Those questions require additional evidence.
Hash fundamentals
What makes cryptographic hashing useful
Deterministic
The same input processed by the same hashing algorithm produces the same digest.
Fixed length
A cryptographic hash produces a digest of a predictable size regardless of whether the source file is tiny or very large.
Content sensitive
Changing even one byte changes the digest, which makes hashes useful for detecting modified content.
One-way
A secure cryptographic hash is designed so the original file cannot practically be reconstructed from the digest alone.
Identity aid
A digest helps distinguish exact file content from filenames that may be duplicated, renamed, or misleading.
Not a verdict
A hash does not by itself prove who created the file, why it exists, or whether a user intentionally opened it.
Algorithms
Prefer modern hashes for integrity work
SHA-256
Preferred for trainingWidely used for integrity checks and produces a 256-bit digest. Good default for CyberPatriot-style evidence documentation.
SHA-1
Legacy awarenessHistorically common but no longer considered collision-resistant enough for modern security-sensitive use.
MD5
Legacy awarenessStill seen in older tools and datasets, but not suitable for strong collision-resistant security guarantees.
Competition takeaway
You may encounter legacy MD5 or SHA-1 values in old datasets or tools. For new integrity documentation, use a stronger modern algorithm such as SHA-256 when available.
File identity
Compare hashes with other evidence fields
Filename
Weak identity clue
Files can be renamed, copied, duplicated, or intentionally given misleading names.
Path
Context clue
Location matters, but identical content can exist in many different directories.
Size
Useful supporting clue
Different files can have the same size, so size alone does not establish exact identity.
Timestamp
Timeline clue
Useful for sequence reasoning but can change because of copying, extraction, restoration, or system behavior.
Owner
Identity context
Shows which account owns the file, not necessarily who created, downloaded, or intentionally used it.
Cryptographic hash
Strong content identity clue
Matching secure hashes strongly support that two files contain the same bytes.
Integrity workflow
Hash before change, compare after
Identify the artifact
Record the source system, exact path, filename, size, and why the file matters to the forensic question.
Choose the algorithm
Use a modern algorithm such as SHA-256 when the environment and tools support it.
Compute the digest
Hash the file without editing or executing it. Record the algorithm and digest exactly.
Preserve the result
Store the digest with the evidence note so later copies or versions can be compared.
Compare carefully
A matching digest supports identical content. A different digest proves the content differs, but not why it changed.
Corroborate
Combine the hash with path, timestamps, logs, ownership, browser records, or other evidence to answer the actual question.
Windows
PowerShell file hashing
PowerShell SHA-256
Get-FileHash "C:\Users\trainee\Downloads\sample.zip" -Algorithm SHA256
Returns the file path, algorithm, and digest for documentation.
PowerShell default
Get-FileHash "C:\Evidence\notes.txt"
PowerShell commonly defaults to SHA-256, but explicitly naming the algorithm makes documentation clearer.
Compare two files
$a = (Get-FileHash "C:\Evidence\original.bin" -Algorithm SHA256).Hash $b = (Get-FileHash "C:\Evidence\copy.bin" -Algorithm SHA256).Hash $a -eq $b
Returns True when both digests match exactly.
Linux
SHA-256 file hashing
SHA-256
sha256sum /home/trainee/Downloads/sample.zip
Prints the digest followed by the file path.
Multiple files
sha256sum file1.txt file2.txt file3.txt
Useful for building a simple integrity list for several fictional artifacts.
Verify a saved list
sha256sum -c hashes.txt
Checks whether files still match the recorded SHA-256 digests when the saved list is formatted correctly.
Interpretation
Know exactly what a hash comparison supports
Two files have the same filename but different SHA-256 hashes.
Supported
The files contain different bytes despite sharing the same name.
Not supported
Which file is malicious or which user changed it.
Two files in different folders have the same SHA-256 hash.
Supported
The file contents are extremely likely to be identical.
Not supported
Why both copies exist or who placed them there.
A working copy has the same hash as the original.
Supported
The copied file content matches the original at the time of comparison.
Not supported
Whether metadata such as timestamps or permissions also match.
A file's hash changed after editing.
Supported
The underlying file content changed.
Not supported
Exactly which bytes changed unless another comparison identifies them.
A hash appears in a known-bad training list.
Supported
The file content matches that training indicator if the list is trusted.
Not supported
How the file arrived, who used it, or what actions occurred on the host.
A digest is absent from a reference list.
Supported
No match was found in that particular list.
Not supported
That the file is safe.
Collisions
Understand why stronger algorithms matter
What is a collision?
A collision occurs when two different inputs produce the same hash digest.
Why it matters
Strong cryptographic hashes are designed to make finding collisions computationally impractical.
Why algorithm choice matters
Older algorithms such as MD5 and SHA-1 have known collision weaknesses, so SHA-256 is a stronger integrity choice.
What competition students need
You do not need to perform collision attacks. You need to recognize that modern secure algorithms provide stronger integrity confidence.
Hash vs metadata
Use the right evidence for the right question
Did the filename change?
Best evidence
Compare filename and path metadata.
Hash role
A matching hash can show the content stayed the same even if the name changed.
Did the file content change?
Best evidence
Compare secure hashes from before and after.
Hash role
Different hashes show the content is not identical.
Was the file copied?
Best evidence
Use path, timestamps, logs, and user activity.
Hash role
Matching hashes can support that the copy contains the same content.
Who created the file?
Best evidence
Use logs, application artifacts, ownership, timestamps, and user activity.
Hash role
The hash does not identify the creator.
Was the file opened?
Best evidence
Use application history, recent-file artifacts, logs, or process evidence.
Hash role
The hash cannot prove execution or opening.
Is this exactly the same evidence file as before?
Best evidence
Compare a recorded secure hash and source documentation.
Hash role
A matching digest is the strongest content-level comparison.
Documentation
Record enough information to make the digest useful
Evidence label
Source system
Exact path
Filename
File size
Hash algorithm
Hash digest
Observation time
Artifact timestamp(s)
Reason for hashing
Related forensic question
Corroborating evidence
Sample evidence record
Evidence label: F-03 Source system: CP-WIN-07 Path: C:\Users\analyst\Downloads\training-archive.zip Size: 4.6 MB Algorithm: SHA-256 Digest: 7E3A...F91C (fictional shortened training digest) Observation time: 2026-10-10 16:42 EDT Purpose: Confirm file identity before later cleanup
Hash set exercise
Read a small digest table like forensic evidence
report-a.txt
AAA111
Baseline report file.
report-a-copy.txt
AAA111
Same digest as report-a.txt.
report-a-edited.txt
BBB222
Different digest.
archive.zip
CCC333
Distinct artifact.
archive-renamed.zip
CCC333
Different name, same digest.
archive-repacked.zip
DDD444
Different digest even if extracted contents may overlap.
Question 01
Which two text files contain identical bytes?
report-a.txt and report-a-copy.txt because both use digest AAA111.
Question 02
Which file definitely differs in content from report-a.txt?
report-a-edited.txt because its digest is BBB222.
Question 03
What does archive-renamed.zip demonstrate?
A filename can change while content remains identical.
Question 04
Does archive-repacked.zip prove malicious modification?
No. Its different digest only proves that the archive bytes differ.
Question 05
What extra evidence would explain why the archive changed?
File timestamps, application history, user activity, logs, and related filesystem evidence.
Integrity baseline
Use hashes at multiple points in the evidence lifecycle
Baseline
Record trusted or original hashes before intentional changes.
Working copy
Confirm a copied artifact matches the baseline content.
Post-change
Identify whether content changed after an authorized edit or update.
Final review
Confirm important evidence files still match documented reference digests where expected.
Common mistakes
Hashing mistakes that weaken forensic evidence
Hashing the wrong file
A correct digest of the wrong path is still the wrong evidence. Verify the source location first.
Forgetting the algorithm
A digest without SHA-256, SHA-1, MD5, or another algorithm label is incomplete documentation.
Treating hash match as motive
A content match does not explain who placed the file there or why.
Assuming no reference match means safe
Reference lists are incomplete. No match means only that the list did not contain that digest.
Hashing after editing
If you modify the artifact first, the digest no longer represents the original content.
Copying a digest incorrectly
One wrong character makes comparison invalid. Copy the full value exactly.
Ignoring path context
The same content in a system directory and a Downloads folder may have different investigative meaning.
Using legacy algorithms blindly
Older digests may appear in tools, but stronger modern algorithms are preferable for integrity work.
Fictional integrity lab
Follow one file through download, rename, copy, and edit
User trainee2 logs in to the fictional workstation CP-WS-12.
Browser history records a download named helper.exe into Downloads.
helper.exe is hashed with SHA-256 and recorded as HASH-A.
A copy named updater.exe appears in another folder.
updater.exe is hashed and also produces HASH-A.
helper.exe is edited in the fictional lab and now produces HASH-B.
Task 01
What does the matching HASH-A value establish?
helper.exe at 10:08 and updater.exe at 10:12 contained identical bytes.
Task 02
Does the renamed updater.exe prove a different program?
No. The matching hash shows the file content was the same despite the different name.
Task 03
What does HASH-B establish?
The later helper.exe content differs from the earlier HASH-A version.
Task 04
Can the hashes prove who renamed the file?
No. User activity, logs, or filesystem evidence would be needed.
Task 05
Why should HASH-A have been recorded before editing?
It preserves the identity of the original content for later comparison.
Task 06
What other evidence would help explain the file's history?
Browser records, timestamps, ownership, process activity, logs, and the source and destination paths.
Lesson checklist
Before moving on
I verify the exact file path before hashing.
I use a modern algorithm such as SHA-256 where available.
I record the algorithm name with the digest.
I copy the full digest accurately.
I hash before intentionally editing or deleting the artifact.
I record the source system and observation time.
I understand that matching hashes support identical content, not identical metadata.
I understand that different hashes prove different content, not malicious intent.
I combine the hash with contextual evidence.
I do not execute unknown files simply to identify them.
I avoid publishing real credentials or sensitive secret material.
I preserve enough notes that a teammate can reproduce the comparison.
Reflection
Check your integrity reasoning
Question 1
Why is a cryptographic hash usually stronger evidence of exact content identity than a filename?
Question 2
What does a different SHA-256 digest prove?
Question 3
What does a matching SHA-256 digest fail to prove?
Question 4
Why should the algorithm name always be documented?
Question 5
How can a renamed file still be shown to contain identical content?
Question 6
Why is SHA-256 generally preferable to MD5 or SHA-1 for integrity work?
Carry this forward
Use hashes to identify exact file content, not to infer user motive. Record the algorithm, digest, path, system, and time, then combine the result with logs and metadata.