Establishing Evidence Integrity and Chain of Custody

The brief

You are a junior digital forensics investigator on a corporate espionage case, designated Case M57-Patents. An employee of the company M57 is suspected of exfiltrating new patent filings. The IT department has imaged the suspect’s work USB drive in EnCase format and has made the image available to you, together with the SHA-256 hash it recorded at the moment of imaging.

Your first task is not to analyse the drive. It is to build the foundation everything else will rest on: acquire the image, prove it has not changed since IT made it, create a verified working copy, and record every one of those actions in a chain of custody log with a name, a time and a reason. Chapter 3 calls this the second admissibility gate, authenticity. A mistake here is not a small mistake — it is the one a defence lawyer looks for first, because it takes every later finding down with it.

How this page works

Each step ends with a checkpoint. Answer it from what your own terminal printed — every question tells you which command produces the value. A step only counts toward your progress once every one of its questions is right. Nothing is sent anywhere; your progress is stored in this browser.

The image is charlie-work-usb-2009-12-11.E01 from the M57-Patents scenario of the Digital Corpora project, a public dataset built for forensic teaching. It is a genuine EnCase image of a real 1 GB USB stick, redacted by the corpus authors. Digital Corpora publishes the image but no hash beside it, so the hash file you download from this portal stands in for the IT department’s record: it was computed when the course acquired the image, and it is the value your copy must match.

0 — Tools and evidence

The tools

Nothing to install on Linux or WSL: wget, sha256sum, cp and date are all standard. On macOS use shasum -a 256 wherever this page says sha256sum, and curl -O wherever it says wget. The custody log is a plain text file; a spreadsheet works too.

bash

wget --version | head -1
sha256sum --version | head -1

# if either is missing (Debian / Ubuntu)
sudo apt-get update && sudo apt-get install -y wget coreutils

Get the evidence

Give the case a folder of its own, then download the image from Digital Corpora and the hash file from this portal into it. Keep the filenames exactly as they are: the hash file names the image it belongs to, and sha256sum -c will look for that name.

bash

mkdir M57-Patents-Case
cd M57-Patents-Case

# the disk image, about 9 MB, from the corpus
wget https://digitalcorpora.s3.amazonaws.com/corpora/scenarios/2009-m57-patents/usb/charlie-work-usb-2009-12-11.E01

# the official hash, issued by the course
wget https://courses.karbab.net/mscs630/charlie-work-usb-2009-12-11.E01.sha256

Rather use a browser? Download the image and download the hash file, and save both into M57-Patents-Case. Some browsers rename a .sha256 download; check the name before you go on.

Confirm both files are there and note the image’s size. Size is not integrity — two different files can have the same size — but a size that is off already tells you the download is broken before you spend a hash on it.

bash

ls -l

Do not hash it yet. Verification is an action on the evidence, and every action on the evidence is logged. The log does not exist until Step 1. Doing things in the right order is the whole lesson of this lab.

Checkpoint 0

Both must be right to complete this step.

How many bytes is charlie-work-usb-2009-12-11.E01 on your disk?
The files are downloaded and sha256sum takes a second to run. Why does this page tell you not to run it yet?

Because the hash file must be opened in an editor first, so you know what value to expect. Because verification is an action on the evidence, and an action taken before the log exists is an action with no record. Because sha256sum should only ever be run on the working copy, never on the original.

1 — Create the custody log

The chain of custody log is the document that lets the court see across every handoff. Chapter 3 lists what each entry needs: a case and item number, a description, the name of the person acting, the date and time, and the reason. Make the log now, before the evidence is touched.

Create the file

bash

nano chain_of_custody_M57.txt

Paste the header below as the first two lines. Fields are separated with a pipe. A spreadsheet with the same six columns is equally good.

chain_of_custody_M57.txt

Case | Item | Description | Custodian | Time (UTC) | Action
-----|------|-------------|-----------|------------|-------

Timestamps

Every entry carries the time the action happened, in UTC so that nobody has to guess your time zone later. Take it from the clock at the moment you act, not afterwards when you tidy the log. Chapter 4’s standard for notes is reproducibility, and a log reconstructed from memory does not meet it.

bash

date -u

What to look for: a line ending in UTC. If it ends in your local zone abbreviation instead, you forgot -u.

Checkpoint 1

Both must be right to complete this step.

Which of these log entries would satisfy the chain of custody requirements from Chapter 3?

M57-Patents | USB image | hashed it | OK M57-Patents | M57-USB-Orig | charlie-work-usb-2009-12-11.E01 | verified M57-Patents | M57-USB-Orig | charlie-work-usb-2009-12-11.E01 | A. Student | Wed 17 Sep 2026 10:14:03 UTC | Verified SHA-256 against issued hash file, result OK
You finish all five steps in one sitting and then fill the timestamps in from memory. What is wrong with that?

The log no longer records when each action happened, only when you thought it happened, so another examiner cannot reproduce your sequence from it. Nothing, as long as the times are in UTC and roughly in the right order. Nothing, because the hash values prove the order of events on their own.

2 — Log the acquisition

The evidence is on your disk. The first entry in the log records how it got there: from where, when, and into whose hands.

Assign an item number

Every evidence item gets an identifier that you will reuse on every later action taken on it. Use M57-USB-Orig for the original image. The working copy you make in Step 4 will be a different item with its own number.

Make the first entry

Take the time, then write the entry. Everything in it comes from what you actually did.

bash

date -u
ls -l charlie-work-usb-2009-12-11.E01

chain_of_custody_M57.txt

M57-Patents | M57-USB-Orig | Original evidence image, Charlie's work USB drive (charlie-work-usb-2009-12-11.E01, 9265553 bytes) | [Your Name] | [date -u output] | Acquired from Digital Corpora via wget; official hash file acquired from the course portal

The description names the source drive, the filename and the size. Later, when someone asks “is the file you hashed the file you downloaded?”, that entry is the answer.

Checkpoint 2

Both must be right to complete this step.

In Step 3 you will hash this same file. What item number goes on that entry?

A new number, since hashing is a new action. M57-USB-Orig again -- the item has not changed, only what was done to it. No number; the hash value itself identifies the file.
Why does the description carry the size in bytes?

Because the size is a form of hash and proves the file is intact. Because sha256sum requires it as an argument. Because it is a cheap, independent fact about the object that any reader can check later against the file they are handed.

3 — Verify the original

Now prove that the bytes on your disk are the bytes IT imaged. The proof is a cryptographic hash: change one bit anywhere in nine megabytes and the 64-character value changes completely.

Compute the hash

bash

sha256sum charlie-work-usb-2009-12-11.E01

What to look for: 64 hexadecimal characters, two spaces, the filename. The value is what goes in the log and in your report.

Compare it with the official value

You could open the .sha256 file and compare by eye. Let the tool do it instead: -c reads the expected value and filename from the hash file, recomputes, and prints one word per file.

bash

sha256sum -c charlie-work-usb-2009-12-11.E01.sha256

# to see both values side by side
cat charlie-work-usb-2009-12-11.E01.sha256

Expected output:

output

charlie-work-usb-2009-12-11.E01: OK

If it prints FAILED, stop. The file on your disk is not the evidence, and nothing derived from it can be tied back to what IT imaged. Do not note the discrepancy and continue. Delete the file, download it again, log the re-acquisition, and verify again. A partial download is the usual cause.

Log it

chain_of_custody_M57.txt

M57-Patents | M57-USB-Orig | (same item) | [Your Name] | [date -u output] | Calculated SHA-256: [your 64-character value]. Verified against charlie-work-usb-2009-12-11.E01.sha256 with sha256sum -c, result OK

Checkpoint 3

All three must be right to complete this step.

What is the SHA-256 hash of your copy of charlie-work-usb-2009-12-11.E01?
What did sha256sum -c print after the filename?
Suppose the check had printed FAILED. What is the correct next action?

Stop, delete the file, download it again, log the re-acquisition and verify again -- a copy that does not match is not the evidence. Continue with the analysis and record the mismatch as a caveat in the report. Edit the .sha256 file to hold the value you computed, since your download is the copy you actually have.

4 — Create the working copy

Analysis is never done on the original. Tools open files, mount images and sometimes write to them; a mounted image can change under you without anyone intending it. The original stays as it was verified, and everything from here on happens to a copy.

Copy the image

bash

cp charlie-work-usb-2009-12-11.E01 charlie-work-usb-2009-12-11-WORK.E01
ls -l

What to look for: two .E01 files of exactly the same size, plus the hash file and your log.

Log it as a new item

The working copy is a distinct piece of evidence, derived from the original. It gets its own item number, and the entry says which item it came from.

chain_of_custody_M57.txt

M57-Patents | M57-USB-Work | Working copy of the USB image (charlie-work-usb-2009-12-11-WORK.E01) | [Your Name] | [date -u output] | Created working copy from original evidence item M57-USB-Orig with cp

Checkpoint 4

Both must be right to complete this step.

Not counting your log, how many evidence-related files are in the case folder now?
Why does the working copy get a new item number instead of another entry under M57-USB-Orig?

Because cp changes the original, so the old number no longer applies. Because it is a separate object that will have its own history from now on, and the entry records which item it was derived from. Because item numbers must increase with every log entry.

5 — Verify the working copy

A copy is only a forensically sound duplicate once you have shown it is one. Hash the copy and compare it with the original’s hash from Step 3.

Hash both, side by side

bash

sha256sum charlie-work-usb-2009-12-11.E01 charlie-work-usb-2009-12-11-WORK.E01

What to look for: two lines with the same 64 characters. That match is the finding. If the values differ, the copy failed; delete it, copy again, and log both events.

See what a single byte does

Optional, and worth thirty seconds. Make a throwaway copy, append one byte, and hash it. Do this on a fourth file, never on the original or the working copy, and do not log it as evidence.

bash

cp charlie-work-usb-2009-12-11-WORK.E01 scratch.E01
printf 'x' >> scratch.E01
sha256sum scratch.E01
rm scratch.E01

What to look for: a value with nothing in common with the original’s. One byte in nine million, and every character of the fingerprint moved. That is the property the whole procedure rests on.

Log the final verification

chain_of_custody_M57.txt

M57-Patents | M57-USB-Work | (same item) | [Your Name] | [date -u output] | Calculated SHA-256: [the working copy's value]. Verified identical to original evidence item M57-USB-Orig. Ready for analysis

Checkpoint 5

All three must be right to complete this step.

What is the SHA-256 hash of charlie-work-usb-2009-12-11-WORK.E01?
The two hashes match. What, precisely, has that established?

That the USB drive was not tampered with before IT imaged it. That the files inside the image are authentic and were written by the suspect. That the working copy is byte-for-byte identical to the verified original, and nothing more.
Reading your finished log, what should a second examiner be able to do with it and the two files?

Repeat every action in the same order, get the same hash values, and confirm the copy is sound without asking you anything. Skip the verification, since your log already states that the hashes matched. Determine what the suspect did with the patent files.

Write the report

The checkpoints establish the facts. The graded deliverable is the preliminary report you write from them, using the template in the PDF handout. It has four parts:

Evidence details — filename, size in bytes, the SHA-256 of the original, and the source and UTC time of acquisition, all copied from your log.
Executive summary — two or three sentences for a manager who will read nothing else: what was acquired, how its integrity was established, that a verified working copy exists, and that a custody log covers every action.
Key findings — the original’s integrity (did the hash match the issued value, and what that establishes); the creation of the working copy and why the original is now left alone; the working copy’s integrity and what a mismatch would have meant.
Importance of procedural integrity — which admissibility gate from Chapter 3 a mismatched hash would fail, which one an undocumented action would fail, and how a defence lawyer would use either gap in cross-examination.

Attach the custody log. Every value in the report is one you produced yourself and can point to in it.