Week 3: File Hashes and Troubleshooting Evidence

A hash can tell you that two byte sequences are the same or different.

That is powerful.

It is also much narrower than people often make it sound.

A changed hash does not tell you why a file changed, who changed it, whether the change was malicious, or whether the original file was trustworthy. It gives you one piece of evidence: the bytes are not the same as the comparison value.

Week 3 teaches you how to use that evidence correctly.

The evidence chain

TRUSTED REFERENCE
      ↓
FILE / ARTIFACT
      ↓
SHA-256 DIGEST
      ↓
COMPARE
      ↓
CORRELATE WITH OTHER EVIDENCE
      ↓
HYPOTHESIS
      ↓
CONTROLLED RETEST

The word trusted matters. A hash is only useful for integrity comparison if the reference digest is tied to something you actually trust: a known baseline you created before the change, a signed/reputable publisher record, or another controlled reference.

This week

Lesson 1 — A Hash Is a Fingerprint, Not a Verdict

Learn what a cryptographic hash function does, what properties make SHA-256 useful for integrity checks, and what a matching or mismatching digest can actually support as a claim.

Lesson 2 — Troubleshooting Is Hypothesis Testing

Use a synthetic service failure to combine hash evidence with file metadata, configuration, and logs. The hash tells you what changed; the surrounding evidence helps you test whether that change explains the failure.

Lesson 3 — Build an Integrity Baseline and Retest

Create a small integrity record for a harmless text/configuration file, change one line, compare the new digest, restore the intended content, and document what the retest proves.

Reflection — What Did the Hash Actually Prove?

Compress the week into a defensible integrity claim and identify the evidence you would still need before assigning cause or intent.

Week 3 artifact

Build an Integrity and Troubleshooting Record containing:

• artifact identity and purpose;
• trusted-reference source;
• baseline SHA-256 digest;
• observed SHA-256 digest;
• match/mismatch result;
• relevant metadata or log evidence;
• hypothesis;
• controlled correction/retest;
• final bounded claim; and
• limitation.

Unit 1 closes here

Weeks 1–3 establish the operating discipline for the rest of CS1337:

Week 1: Am I authorized, and what evidence can I use?
Week 2: Which identity/process/service/resource relationship am I observing?
Week 3: Did the artifact change, does that change explain the behavior, and how do I prove the correction?

Tools will get more interesting later.

The reasoning standard does not change.