Differentiating Computer-Generated vs. Computer-Stored Records

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 or a document. A computer-generated record is data the operating system or an application wrote by itself, with no person deciding its content: file timestamps, document metadata, download marks. Courts treat the two differently. A stored record can raise a hearsay objection (FRE 801(c), 802), unless it is a party’s own statement offered against that party (FRE 801(d)(2)). A generated record is not a person’s statement and so is not hearsay, but like every record it must be authenticated (FRE 901, 902). You will find one clear example of each, and one file that holds both.

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, and the same image you verified in Lab 3. Digital Corpora publishes no hash beside it; the hash file on this portal was computed when the course acquired the image. All times on this page are UTC.

0 — Tools and evidence

The tools

The command-line work uses The Sleuth Kit and unzip. Current Linux packages of The Sleuth Kit read .E01 images directly. Autopsy 4.x is the graphical front end built on the same tools; every GUI step in the handout has a matching command here, so the commands alone are enough to finish the lab.

bash

# Debian / Ubuntu / Kali
sudo apt-get update && sudo apt-get install -y sleuthkit unzip

# macOS (Homebrew)
brew install sleuthkit

# check the installation
fls -V

What to look for: a line such as The Sleuth Kit ver 4.12.1. Your version may differ.

Get the evidence

Give the lab a folder of its own and download the image and the course hash file into it, keeping both filenames as they are.

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

Rather use a browser? Download the image and download the hash file into LAB-05-M57. Some browsers rename a .sha256 download; check the name before you go on.

Check the hash

Lab 3 covers this procedure and the custody log in full. Here one check is enough, but it is not optional: this is a new download, and only a hash computed now ties it to the recorded value.

bash

# Linux / WSL
sha256sum -c charlie-work-usb-2009-12-11.E01.sha256

# macOS
shasum -a 256 -c charlie-work-usb-2009-12-11.E01.sha256

# Windows PowerShell (compare by eye with the value below)
Get-FileHash charlie-work-usb-2009-12-11.E01 -Algorithm SHA256

The expected SHA-256:

sha256

7a998c556b22f5dc9426a33dcaceadd21a14c9cfb22957edce461d58a14fb40a

If the check prints FAILED or the value differs, stop. Delete the file, download it again 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?
You already verified this image in Lab 3. Why hash it again?

Because the hash of an E01 image changes every time it is opened. Because this is a new download, and only a hash computed now ties this copy to the recorded value. There is no need; the Lab 3 result carries over to any copy with the same name.

1 — Create a case and ingest the image

Run every command from the LAB-05-M57 folder. The option -z UTC used later makes The Sleuth Kit print UTC; without it, the tools print your computer’s local time.

Create the case (Autopsy)

Start Autopsy and click New Case. Case Name M57-Charlie-Records, Case Number LAB-05-M57, your name as Examiner. In the Add Data Source wizard choose Disk Image or VM File, select the .E01, and set the time zone to GMT/UTC so Autopsy shows the same times as this page. Keep the default ingest modules, with File Type Identification and Recent Activity checked.

Read the partition table

bash

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

output

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000000000   0000000001   Unallocated
002:  000:000   0000000001   0002068479   0002068479   NTFS / exFAT (0x07)

What to look for: one NTFS partition and the sector it starts at. Every later command passes that start as -o (offset in sectors) to reach the file system.

List the root directory

bash

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

What to look for: the number before the colon on each line is the file’s MFT entry, its record in the NTFS Master File Table. Names starting with $ are NTFS system files. A name with a second colon, such as astronaut.jpg:Zone.Identifier, is an alternate data stream: a second, named block of data attached to the same file. Note the entries for the Email folder and for Nitroba work.odt; the next two steps use them.

This drive holds no registry, browser history or shortcut (.lnk) files, so Autopsy’s Data Artifacts tree stays empty or nearly empty. That is expected. This lab works from the files, their metadata and the timeline.

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?
After ingest, Autopsy’s Data Artifacts tree is nearly empty. What does that mean?

The ingest failed and the image must be added again. The drive holds no registry, browser history or shortcut files, so those modules have nothing to parse. The image is damaged, even though the hash matched.

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 the email

In Autopsy, open Email and select Charlie_2009-11-16_1326_Sent.txt. On the command line, list the folder by its MFT entry and filter for the file:

bash

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

Read it

In Autopsy, open the Text tab. On the command line, print the file’s content with icat and the entry number fls just gave you:

bash

icat -o 1 charlie-work-usb-2009-12-11.E01 105

What to look for: the body is a statement by a person: Charlie says he started at a new company that day. That is the computer-stored record. The header lines are different: the Date: line, for example, was written by the email program, not typed by Charlie.

When was the file saved on the drive?

In Autopsy, open the File Metadata tab. On the command line, print the four $STANDARD_INFORMATION times of the entry in UTC:

bash

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

What to look for: compare the Created date with the Date: header of the email. If they differ, the file is a later copy: its content records what Charlie wrote, its timestamps record when the copy was made.

Optional second example: entry 137, Email/other/Great Lunch.txt, is another email Charlie sent. Print it with icat -o 1 charlie-work-usb-2009-12-11.E01 137 and compare.

Checkpoint 2

All three 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?
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 text, a table of prior-art patent references, was typed by a person. Programs also wrote records about it with no user input: NTFS wrote its timestamps and OpenOffice wrote its document metadata. Windows wrote a third kind, the Zone.Identifier streams, on three other files.

NTFS timestamps

bash

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

What to look for: the four MACB times: Modified, Accessed, Changed (MFT entry modified) and Born (created). NTFS wrote them; no person typed them. Compare File Modified with Created. When Windows copies a file, the copy gets a new creation time but keeps the old modification time.

Application metadata

An .odt file is a ZIP archive. Extract the file, hash your extracted copy, and print the metadata fields OpenOffice wrote into meta.xml:

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-]+>[^<]+'

What to look for: editing-cycles (how many times it was saved), editing-duration, generator and dc:date. dc:date is the last save in the computer’s local time; compare it with the NTFS modified time in UTC. The email in Step 2 carries a -0800 offset. Two separate generated records that agree on the save time support each other.

bash

unzip -p nitroba.odt meta.xml | grep -cE 'initial-creator|dc:creator'

What to look for: the count of author fields. With no author and a creation-date months before the rest of the evidence (likely an older file or template), the metadata shows what the program recorded, not who wrote the document or when the work began.

A download mark written by Windows

In Autopsy, select astronaut.jpg:Zone.Identifier and open the Text tab. On the command line, print the stream; it is UTF-16, so tr drops the zero bytes:

bash

icat -o 1 charlie-work-usb-2009-12-11.E01 37-128-4 | tr -d '\0'; echo

What to look for: a [ZoneTransfer] section and a ZoneId. Windows writes this stream when a file arrives from the internet. Entries 35-128-4 (invsecr2.exe) and 38-128-4 (microscope.jpg) hold the same text.

Place the document on a timeline

In Autopsy, Tools → Timeline, list view, filter on Nitroba. On the command line, build a body file of every timestamp and sort it:

bash

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'

What to look for: the letters m, a, c, b show which time each line comes from. The last line comes from the $FILE_NAME attribute, a second set of times NTFS keeps with the file name.

One file, both kinds

Nitroba work.odt is a hybrid. Its typed table is a computer-stored record; its NTFS times and its meta.xml fields are computer-generated records. A court applies the matching rule to each part.

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?
How do the rules treat the NTFS times of Nitroba work.odt?

They are hearsay, admitted only under the business records exception. No person made them, so they are not hearsay, but the party offering them must authenticate them, for example by showing the system produces an accurate result. They are admitted automatically, because a computer cannot be cross-examined.
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. Copy each value exactly from your own output. 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 when offered against Charlie and when offered by someone else for its truth); the generated records (the NTFS times of Nitroba work.odt, the SHA-256 of the extracted file, editing-cycles, editing-duration, dc:date, whether an author field exists, which files carry a Zone.Identifier and its ZoneId, and why these are not hearsay and how they would be authenticated under FRE 901(b)(9) or 902(13)).
Admissibility analysis — compare the two kinds of record: what makes the email hearsay or not and what links it to Charlie; what an examiner must show about the system that wrote the generated records; and one limit of generated metadata, shown on Nitroba work.odt.

Every value in the report is one you produced yourself with a command you can name.