Evidence Integrity and Chain of Custody with Claude Code

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.

The manual edition of this lab has you type every command yourself. Here you keep the evidence on your own disk and ask Claude Code to run the commands: you ask, it proposes a command, you approve it, it shows you the output. The procedure is the same one. What changes is that a second party has now touched the evidence, and the custody log has to say so.

The ground rule

Claude runs the commands. You own the findings, and you own the log. Never write a value into the custody log that Claude did not show you the command for, and never let Claude write the log for you. A model will state a plausible hash as readily as a true one, and a log entry it wrote is a log entry nobody signed. Every prompt on this page ends by asking for the exact command and its output, and every step tells you how to re-run it yourself.

Where the risk is, this week

This lab is about order and record-keeping, and a model is eager to help with both in exactly the wrong way. Asked to “set up the case”, it will happily download, hash and copy in one go, before any log exists, and then offer to write a tidy log afterwards from what it remembers doing. That is a reconstructed log, and Chapter 4 says a reconstructed log does not meet the reproducibility standard. Ask for one action at a time, and write each entry yourself, at the time.

How this page works

Each step ends with a checkpoint. The factual questions are the same ones the manual edition asks, because the evidence has not changed; the reasoning questions are about your handling of the tool. 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. 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.

0 — Claude Code and evidence

Before you start

You need Claude Code installed and signed in. If it is not, work through the setup guide first. Check with claude --version; a version number means you are ready. You also need wget and sha256sum (on macOS, curl and shasum), which Claude will use on your behalf.

Make a folder and start Claude there

Claude Code works inside the folder you launch it in, so give the case a folder of its own.

bash

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

Windows PowerShell: mkdir $env:USERPROFILE\M57-Patents-Case, then cd into it. The hashing commands on this page are Linux, WSL and macOS; on plain Windows, ask Claude for the certutil -hashfile ... SHA256 equivalent and check its work the same way.

Get the evidence

Ask for the two downloads, one prompt, nothing else. Read the commands Claude proposes before you approve them: the URLs should be exactly the two below and the filenames must not change.

Prompt

Download these two files into the current folder with wget, keeping their filenames exactly as they are, and show me the commands you ran and the output of ls -l afterwards. Do not hash, copy or open them.
https://digitalcorpora.s3.amazonaws.com/corpora/scenarios/2009-m57-patents/usb/charlie-work-usb-2009-12-11.E01
https://courses.karbab.net/mscs630/charlie-work-usb-2009-12-11.E01.sha256

What Claude should do: two wget commands and one ls -l, and then stop. If it also runs sha256sum “while it is at it”, that is the risk this page warned about: an action on the evidence with no log to record it. Note that it happened; Step 2 tells you how to log it.

Check its work:

bash

ls -l

Do not ask for the hash yet. Verification is an action on the evidence, and every action on the evidence is logged. The log does not exist until Step 1.

Checkpoint 0

Both must be right to complete this step.

How many bytes is charlie-work-usb-2009-12-11.E01 on your disk?
Claude downloaded the files and, unasked, also ran sha256sum on the image. What do you do?

Note the time and the command now; when the log exists, its first entries record the download and that an unrequested hash was computed by the tool before logging began. Nothing -- a hash is read-only, so it does not count as an action on the evidence. Delete everything, start again, and do not mention it, since the second attempt will be clean.

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.

Write the log yourself

This is the one file in the lab Claude does not write. Open an editor in a second terminal and create it with the header below; the entries that follow are yours to type, at the time of each action.

chain_of_custody_M57.txt

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

Timestamps

Ask Claude for the UTC time whenever you are about to write an entry. It is a small thing to ask for, and asking each time keeps the timestamp tied to the action rather than to the moment you tidied up.

Prompt

Print the current date and time in UTC with the date command, and show me the command you ran.

Check its work: the command should be date -u and the line should end in UTC.

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
At the end, Claude offers: “I can write the chain of custody log for you from the commands I ran.” Why decline?

Because the log must be a spreadsheet, and Claude can only write text files. Because a log written afterwards from the tool's memory is a reconstruction with no custodian behind it, and the custodian who signs each entry is you. Because Claude does not have access to the timestamps of the commands it ran.

2 — Log the acquisition

The evidence is on your disk. The first entry records how it got there: from where, when, and into whose hands. Every evidence item gets an identifier reused on every later action taken on it; use M57-USB-Orig for the original image.

Get the facts for the entry

Prompt

Show me the exact size in bytes of charlie-work-usb-2009-12-11.E01 using ls -l, then print the UTC time with date -u. Show both commands and their output, and do nothing else.

What Claude should do: two commands, two lines of output. If it summarises (“the file is about 9 MB”), ask again for the exact number; the log wants the byte count, not a rounding.

Write the entry

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 run by Claude Code at my request; official hash file acquired from the course portal

Notice the extra clause. The download was performed by a tool acting on your instruction, and the log says so. If the tool also hashed the file in Step 0, add a second entry recording that, with the time you noted.

Checkpoint 2

Both must be right to complete this step.

In Step 3 you will have Claude 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 acquisition entry say the download was run by Claude Code at your request?

Because the log records who actually touched the evidence and on whose authority; a tool acting for you is still a party the record has to name. Because the download would otherwise be inadmissible. It should not; naming the tool weakens the log, so leave it out.

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.

Ask for the hash, and for the check

Prompt

Compute the SHA-256 hash of charlie-work-usb-2009-12-11.E01 with sha256sum and show me the command and the full output exactly as printed. Do not modify any file.

Prompt

Now run sha256sum -c charlie-work-usb-2009-12-11.E01.sha256 and show me the command and its output exactly. Then show me the contents of the .sha256 file with cat.

What Claude should do: three commands, three outputs, no interpretation needed. The -c line should read charlie-work-usb-2009-12-11.E01: OK.

Check its work: this is the one value that certifies every other value in the lab, so it is the last one to take on trust. Run it yourself, in your own terminal, and compare character for character.

bash

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

Expected output:

output

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

If it prints FAILED, stop. Do not ask Claude to explain the difference away, and do not let it “fix” the hash file. The file on your disk is not the evidence. Delete it, download it again, log the re-acquisition, and verify again.

A model asked “does the hash match?” will sometimes answer yes from the shape of the two strings rather than from a comparison. That is why the prompt asks for sha256sum -c, which does the comparison in the tool, and why you run it once more yourself.

Log it

chain_of_custody_M57.txt

M57-Patents | M57-USB-Orig | (same item) | [Your Name] | [date -u output] | SHA-256 computed by Claude Code at my request and re-computed by me: [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?
Claude reports “the hash matches the official value” but the output it shows is a 64-character string with no -c line. What do you record?

Record it as verified -- Claude read both values and they are the same file. Nothing yet: ask for the sha256sum -c command and its output, run it yourself, and record what you watched appear on your own screen. Ask Claude the same question again and record the answer if it repeats the same conclusion.

4 — Create the working copy

Analysis is never done on the original. The original stays as it was verified, and everything from here on happens to a copy.

Ask for the copy, and only the copy

Prompt

Copy charlie-work-usb-2009-12-11.E01 to a new file named charlie-work-usb-2009-12-11-WORK.E01 with cp, then show me ls -l. Show me the commands you ran. Do not hash anything and do not touch the original.

What Claude should do: one cp, one ls -l. Read the cp before approving it: the source and destination must be the right way round, and the destination name must be exactly charlie-work-usb-2009-12-11-WORK.E01. A model that “helpfully” renames or moves the original has just altered the evidence.

Check its work:

bash

ls -l

What to look for: two .E01 files of exactly the same size, the hash file, and your log. The original is still there under its original name.

Log it as a new item

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, run by Claude Code at my request

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?
Claude proposes mv charlie-work-usb-2009-12-11.E01 charlie-work-usb-2009-12-11-WORK.E01. What do you do?

Approve it; the bytes are the same either way, so the hash will still match. Approve it, then ask Claude to copy the working copy back under the original name. Decline it and ask for cp: mv would rename the original, and the item called M57-USB-Orig in your log would no longer exist under that name.

5 — Verify the working copy

A copy is only a forensically sound duplicate once you have shown it is one. Hash both files and compare.

Ask for both hashes in one command

Prompt

Run sha256sum on both charlie-work-usb-2009-12-11.E01 and charlie-work-usb-2009-12-11-WORK.E01 in a single command and show me the exact output. Do not tell me whether they match; I will compare them myself.

What Claude should do: one command, two lines. The last sentence of the prompt is deliberate: you want the two strings on screen, not a verdict about them.

Check its work:

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.

See what a single byte does

Optional. Ask Claude to make a throwaway copy, append one byte, hash it and delete it. Read the commands: they must touch only the scratch file.

Prompt

Copy charlie-work-usb-2009-12-11-WORK.E01 to scratch.E01, append a single byte to scratch.E01 only, show me its sha256sum, then delete scratch.E01. Show every command. Do not touch the other files.

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.

Log the final verification

chain_of_custody_M57.txt

M57-Patents | M57-USB-Work | (same item) | [Your Name] | [date -u output] | SHA-256 computed by Claude Code at my request and re-computed by me: [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 is different from the manual edition’s log, and why does it matter?

Several entries record that a command was run by Claude Code at your request and re-checked by you; the record names every party that touched the evidence, which is what a court asks. Nothing; a tool is not a custodian, so its involvement is not recorded. The timestamps are missing, because Claude ran the commands and only it knows when.

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, including the ones a tool ran on your behalf.
Key findings — the original’s integrity; 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. Add one paragraph on the tool: what you let it do, what you re-ran yourself, and why.

Attach the custody log. Every value in the report must be one you reproduced with your own command, not one you read in Claude’s summary.