Field guide

Forensic Container Approach

Analyst Field Guide 09 · lesson v23 · book v22

Create a defensible logical container of selected artifacts, transfer it intact, and verify what was preserved. Record original state, define the collection scope, package the files and metadata, retain an independent digest, then verify the received archive and extracted working copy.

Begin with the timestamp and transfer foundation below. Follow the Linux tests in script order, then the Windows controlled procedure. Finally, apply the findings in the C01–C16 container exercise. The web sequence and command IDs match the approved 44-slide lesson.

Use disposable lab VMs and synthetic files. The historical screenshots are reference observations, not proof that your new run passed. Original Linux/Windows runs and the local container rehearsal remain distinct records. Real SSH/Windows endpoint and return-route testing, classroom filesystem checks and populated ACL/xattr cases remain to be qualified.

1. Container workflow · 2. Linux validation · 3. Windows validation · 4. Create and verify your container

Common causes of file timestamp changes

Deck slide 2 · Original step Foundation 1

Command syntax

Content writes: editor saves, application writes, redirection, logs
Reads: hashing and copying can affect access time
Metadata operations: chmod, ACLs, touch, rename
Linux fields: mtime, atime, ctime and supported birth time

Why this syntax: Before transferring evidence, predict which operation can change which field. Then test that prediction on the actual OS and filesystem.

OS and time effect: mtime records content modification but can also be set. atime depends on access policy. ctime records inode status change. Birth time records object creation when supported.

Gotcha or ProTip: Same-filesystem mv normally retains the inode, but ctime can change. Linux ctime is not creation time; ordinary timestamp-setting APIs do not restore it.

Connection to the container lesson: The container workflow defines the claim.

Recorded result or expected outcome: Ubuntu 02–10 and Windows 02–09 show why content identity, timestamps and object identity require separate checks.

Analyst takeaway: Know what the tool changes before you interpret the resulting timeline.

Forensic Container Approach

Deck slide 3 · Original step Foundation 2

Command syntax

Layer 1: source bytes and recorded metadata
Layer 2: archive members and stored metadata
Layer 3: received archive and extracted objects
Scope: logical file container, not a filesystem image

Why this syntax: The v5 Kali-to-Windows scenario needs a portable package that keeps selected source records interpretable across operating systems.

OS and time effect: An unchanged archive can carry source bytes and metadata records through Windows. Extraction creates destination objects with filesystem-dependent metadata.

Gotcha or ProTip: scp -p requests source modification/access times and mode bits on the transferred archive. It does not clone source inode identity, ctime, birth time, ACLs or journal history.

Connection to the container lesson: The container workflow defines the claim.

Recorded result or expected outcome: We validate local file/container behavior below. Actual SSH endpoints and email transport were not validated by the supplied screenshot run.

Analyst takeaway: Verify container bytes separately from destination timestamps.

Forensic Transfer Guide

Deck slide 4 · Original step Foundation 3

Command syntax

1 Record source state before content reads
  stat evidence.log; sha256sum evidence.log
2 Package selected members and metadata records
  tar --format=pax --acls --xattrs ...
3 Hash the completed archive; retain trusted receipt
  sha256sum evidence.tar.gz; scp -p ...
4 Verify archive BEFORE extraction, then compare
  sha256sum -c; tar -xzf ...; stat evidence.log

Why this syntax: This is the four-stage workflow from v5 slide 4. The later C01–C16 tutorial supplies complete runnable syntax and a defined synthetic workspace.

OS and time effect: GNU tar --atime-preserve=system aims to avoid changing source access time while archiving. It is not a promise to restore the extracted file’s original atime.

Gotcha or ProTip: Use SHA-256 for this lab. MD5 is not required. Compare the archive to an independently held digest before extraction; a checksum delivered beside it is not independently trusted.

Connection to the container lesson: The container workflow defines the claim.

Recorded result or expected outcome: Expected: archive/content hashes match the chosen baseline. Measure metadata individually. New inode, ctime or birth time can be expected; record rather than conceal differences.

Analyst takeaway: Verify each transition and make a preservation claim only for the properties actually checked.

1. Container workflow · 2. Linux validation · 3. Windows validation · 4. Create and verify your container

Student downloads

The packet captures support the packet-parsing companion; the timestamp experiments use synthetic files. The Windows harness and the controlled 00–10 procedure are separate sources with different step numbers.

Companion lessons and book references

Companion lab

SL-01 — Create and verify a forensic artifact container: tasks, evidence submission and completion criteria.