Computer-Generated vs. Computer-Stored Records with Claude Code

The brief

You are a junior digital forensics investigator on Case M57-Patents. M57 is a small patent research company, and it suspects that an employee took patent material out of the company. In Lab 3 you received the image of Charlie’s work USB drive and proved it unchanged. In this lab you examine what is on it.

The drive holds two kinds of records. A computer-stored record is content a person wrote and a computer saved, such as an email. A computer-generated record is data the operating system or an application wrote by itself: file timestamps, document metadata, download marks. A stored record can raise a hearsay objection unless it is a party’s own statement offered against that party; a generated record is not hearsay but must still be authenticated. The manual edition has you type every Sleuth Kit command yourself. Here Claude Code runs them, and you check what it reports.

The ground rule

Claude runs the commands. You own the findings. Never write a value into your report that Claude did not show you the command and the raw output for. A model will state a plausible timestamp or hash as readily as a true one. 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 which record a value comes from, and a model blurs exactly that. Asked when the email was written, it will read the Date: header and call it the file’s creation time. Asked for timestamps, it will often drop -z UTC and report local time without saying so, or “convert” between time zones in its head. And asked whether a record is hearsay, it will give a confident legal answer as if it were a reading off the image. Keep the three apart: a value from a command, the record it came from, and the rule you apply to it.

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; one question per step is 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, the same image you verified in Lab 3. The hash file on this portal was computed when the course acquired the image. All times on this page are UTC.

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 The Sleuth Kit and unzip, which Claude will run on your behalf (sudo apt-get install -y sleuthkit unzip, or brew install sleuthkit on macOS). Install them yourself; do not ask Claude to run sudo.

Make a folder and place the evidence by hand

Download the image and the hash file yourself, into a folder of their own, before you start Claude. The evidence is placed by you, not fetched by the tool.

bash

mkdir LAB-05-M57
cd LAB-05-M57
wget https://digitalcorpora.s3.amazonaws.com/corpora/scenarios/2009-m57-patents/usb/charlie-work-usb-2009-12-11.E01
wget https://courses.karbab.net/mscs630/charlie-work-usb-2009-12-11.E01.sha256
claude

Rather use a browser? Download the image and download the hash file into LAB-05-M57. Windows PowerShell: mkdir $env:USERPROFILE\LAB-05-M57, then cd into it; the Sleuth Kit commands on this page are for Linux, WSL and macOS.

Verify it

Prompt

Check charlie-work-usb-2009-12-11.E01 against charlie-work-usb-2009-12-11.E01.sha256 with sha256sum -c. Show me the exact command you ran and its full output. Do not open or change any file.

What Claude should do: run one sha256sum -c and print one line ending in OK.

Check its work:

bash

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

sha256

7a998c556b22f5dc9426a33dcaceadd21a14c9cfb22957edce461d58a14fb40a

If the values differ, stop. Delete the image, download it again by hand and verify again. Do not analyse an image that does not match.

Checkpoint 0

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 replies “The hash matches the expected value.” and shows no command. What do you do?

Record OK, since the tool has direct access to the file. Ask for the exact command and its output, or run sha256sum -c yourself, before you record anything. Ask Claude to print the expected hash from the .sha256 file and record that value.

1 — Create a case and ingest the image

If you use Autopsy, create the case by hand as the handout describes (Case Name M57-Charlie-Records, Case Number LAB-05-M57, time zone GMT/UTC). Claude works on the command line beside it.

The partition table

Prompt

Run mmls on charlie-work-usb-2009-12-11.E01. Show me the exact command and its full output, then tell me the start sector of the NTFS partition and which line you read it from.

What Claude should do: one mmls, the table, and a start sector that matches the Start column of the NTFS / exFAT line.

Check its work:

bash

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

The root directory

Prompt

Using that start sector as the -o offset, list the root directory of the file system with fls. Show me the exact command and its full output. Then tell me the MFT entry number of the Email folder, quoting the line you read it from.

What Claude should do: an fls -o 1 command and a listing of about 27 lines, including $MFT, Email, Nitroba work.odt and three Zone.Identifier streams.

Check its work:

bash

fls -o 1 charlie-work-usb-2009-12-11.E01

Without -o, fls looks for a file system at sector 0, finds the partition table instead, and fails. A model sometimes reads that error as “the image has no file system”. The error is a missing offset, not a finding.

Checkpoint 1

All three must be right to complete this step.

At which sector does the NTFS partition start?
What is the MFT entry number of the Email folder?
Claude runs fls without -o, gets an error, and concludes that the image holds no file system. What do you do?

Record that the drive is unformatted. Point it at the partition offset from mmls with -o 1 and re-run; the error comes from the missing offset, not from the image. Download the image again, because the hash check must have been wrong.

2 — A computer-stored record

Charlie saved copies of his emails as text files in the Email folder. The body of each email is text that Charlie typed.

Find and read the email

Prompt

List the Email folder (MFT entry 43) with fls -o 1 and find the entry number of Charlie_2009-11-16_1326_Sent.txt. Then print that file's content with icat. Show me both commands and their exact output.

What Claude should do: an fls ... 43, the line r/r 105-128-1: Charlie_2009-11-16_1326_Sent.txt, then an icat ... 105 printing the email with its Subject:, From:, Date: and To: lines and a short body.

Check its work:

bash

fls -o 1 charlie-work-usb-2009-12-11.E01 43 | grep 1326
icat -o 1 charlie-work-usb-2009-12-11.E01 105

When was the file saved on the drive?

Prompt

Show the NTFS timestamps of entry 105 in UTC with istat -o 1 -z UTC, keeping only the four $STANDARD_INFORMATION time lines. Show me the exact command and the lines it printed. Do not convert or interpret the times.

What Claude should do: an istat with -z UTC and four lines ending in (UTC).

Check its work:

bash

istat -o 1 -z UTC charlie-work-usb-2009-12-11.E01 105 | sed -n 12,15p

The fluent wrong answer here is “the file was created on 16 November 2009”. That is the Date: header the email program wrote. The NTFS Created time is a different record, written by the file system when the copy landed on the drive.

Checkpoint 2

All four must be right to complete this step.

What is the MFT entry number of Charlie_2009-11-16_1326_Sent.txt?
On what date (UTC, YYYY-MM-DD) was the email file created on the drive?
Claude says the email file “was created on 16 November 2009”. What is wrong, and what do you ask for?

Nothing; the Date: header and the file's creation time are the same thing. That is the Date: header the email program wrote; ask for istat on entry 105 with -z UTC to get when the file was created on the drive. The date is right but in local time; ask Claude to add eight hours.
The prosecution offers the email body against Charlie, to show he had started at a new company. How do the rules treat it?

It is admitted as a business record under FRE 803(6), because it was saved on a work drive. It is a computer-generated record, so the hearsay rule does not apply to it. It is not hearsay: it is a party admission under FRE 801(d)(2), but the prosecution must still show that Charlie wrote it.

3 — A computer-generated record

Nitroba work.odt (MFT entry 41) is an OpenDocument text file. Its typed table is a stored record; NTFS wrote its timestamps and OpenOffice wrote its document metadata, both generated records. Windows wrote a third kind, the Zone.Identifier streams, on three other files. Ask one question per prompt.

NTFS timestamps

Prompt

Show the NTFS timestamps of MFT entry 41 in UTC with istat -o 1 -z UTC, keeping only the four $STANDARD_INFORMATION time lines. Show me the exact command and the lines it printed.

What Claude should do: four lines ending in (UTC), with File Modified on 19 November 2009 and Created on 24 November 2009.

Check its work:

bash

istat -o 1 -z UTC charlie-work-usb-2009-12-11.E01 41 | sed -n 12,15p

Application metadata

Prompt

Extract MFT entry 41 with icat into a file called nitroba.odt, compute its SHA-256 with sha256sum, then print the meta: and dc: fields of meta.xml inside it with unzip -p and grep. Show me every command and its exact output.

Prompt

Count the author fields (initial-creator or dc:creator) in meta.xml inside nitroba.odt with grep -c. Show me the command and the number it printed.

What Claude should do: a hash line, five metadata lines (creation-date, editing-duration, editing-cycles, generator, dc:date), and a count of 0.

Check its work:

bash

icat -o 1 charlie-work-usb-2009-12-11.E01 41 > nitroba.odt
sha256sum nitroba.odt
unzip -p nitroba.odt meta.xml | grep -oE '<(meta|dc):[a-z-]+>[^<]+'
unzip -p nitroba.odt meta.xml | grep -cE 'initial-creator|dc:creator'

With no author field, a model asked “who wrote this document?” tends to answer “Charlie”, because the file is on his drive. That is an inference, not a reading. The metadata records what the program wrote, not who wrote the content.

The download mark and the timeline

Prompt

Print the alternate data stream 37-128-4 (astronaut.jpg:Zone.Identifier) with icat -o 1, removing zero bytes with tr. Show me the exact command and its output.

Prompt

Build a body file of all timestamps with fls -o 1 -r -m / into body.txt, then sort it with mactime -b body.txt -z UTC and show only the lines for Nitroba work. Show me both commands and the exact lines.

Check its work:

bash

icat -o 1 charlie-work-usb-2009-12-11.E01 37-128-4 | tr -d '\0'; echo
fls -o 1 -r -m / charlie-work-usb-2009-12-11.E01 > body.txt
mactime -b body.txt -z UTC 2>/dev/null | grep 'Nitroba work'

If any time Claude reports is 8 hours off the ones above (13:26:42 instead of 21:26:42), it ran without -z UTC or read dc:date, which is local time. Re-run with -z UTC rather than accepting a converted value.

Checkpoint 3

All five must be right to complete this step.

What is the SHA-256 of your extracted nitroba.odt?
How many times was the document saved, according to editing-cycles?
What ZoneId does the Zone.Identifier stream of astronaut.jpg carry?
Claude reports the document’s File Modified time as 13:26:42. Your own istat -z UTC shows 21:26:42. What do you do?

Record both, since they are the same moment in two zones. It ran without -z UTC or read local time, so re-run istat with -z UTC before recording any time. Trust Claude's value, since it can read the image directly.
The document has no author field and a creation-date in April 2009. What can its generated metadata establish?

That Charlie wrote the document, since it is on his drive. What the program recorded about saves and times, not who wrote the content or when the work began. Nothing, because metadata without an author field is inadmissible.

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 — the filename, the output of sha256sum -c, and the file system and partition offset from mmls.
Executive summary — two or three sentences: which image you examined, which stored record and which generated records you found, and what the generated records show about Nitroba work.odt.
Key findings — the stored record (path and MFT entry, the sentence you rely on, its NTFS Created time, and how the hearsay rules treat it); the generated records (the NTFS times of Nitroba work.odt, the SHA-256 of the extracted file, editing-cycles, editing-duration, dc:date, the author field, the Zone.Identifier files and their ZoneId, and how these would be authenticated under FRE 901(b)(9) or 902(13)).
Admissibility analysis — compare the two kinds of record, and use Nitroba work.odt to explain one limit of generated metadata.

Every value in the report must be one you reproduced with your own command, not one you only read in Claude’s reply. The legal analysis is yours; do not paste a model’s.