Chapter 38: The Capstone Investigation — A Complete Case from Assignment to Courtroom

Where you are: Part VI, Chapter 38 of 40. Every chapter before this taught you one skill or one evidence type in isolation: how to image a drive (Chapter 14), recover a deleted file (Chapter 6), carve unallocated space (Chapter 7), read a registry hive (Chapter 16), build a timeline (Chapter 21), detect the suspect who tried to hide (Chapter 30), write the report (Chapter 26), and defend it on the stand (Chapter 27). This chapter is where the pieces become a profession. You will run one complete case — the Meridian Health Analytics matter you have been building since Chapter 5 — from the phone call that opens it to the cross-examination that closes it, assembling the entire Forensic Case File into a single defensible deliverable. The courtroom anchor case returns one last time, clinically, to show that the very same lifecycle governs the gravest matters a person can be assigned.

Learning paths: This is the convergence chapter, and all four tracks meet here. 🔍 Forensic Examiner owns it end to end — this is the workflow you will repeat for the rest of your career. 🛡️ Incident Response runs a compressed, faster version of the same lifecycle under pressure, and the triage and live-capture phases are where your track diverges; watch the Recovery vs. Forensics callouts. 📜 Legal/eDiscovery should study the scope, correlation, reporting, and testimony phases most closely — this is where technical work becomes legal product. 💾 Data Recovery technicians will recognize the acquisition and recovery phases as home ground, and this chapter shows precisely where a recovery job, handled with one extra ounce of discipline, becomes a case that holds up.

The whole method, one case

You have spent thirty-seven chapters learning techniques. This chapter teaches you the thing no single technique can teach: integration — the judgment that decides which technique to apply, in what order, how to make independent findings corroborate one another, and how to fold forty hours of disparate analysis into one document a stranger will trust under oath. A capstone is not a review. It is the demonstration that you can do the actual job, which has never been "recover a deleted file" but always "take a question from a client or a court, answer it truthfully from the evidence, and prove the answer."

The most common failure of new examiners is not technical incompetence. It is disorganization under the weight of a real case. A genuine matter throws everything at you at once: a half-dozen evidence sources, contradictory timestamps, an encryption posture you do not yet understand, a suspect who covered tracks, a deadline, an attorney who wants a yes-or-no answer the evidence will not cleanly give, and a nagging worry that you have missed something. The skill that separates the professional from the talented hobbyist is a repeatable lifecycle — a sequence you trust so completely that when the case is chaotic you fall back on the process and let it carry you. That lifecycle is the subject of this chapter, and the Meridian Health Analytics case is the vehicle.

Why This Matters. Media, file systems, encryption, and tools will keep changing for your entire career — the NVMe SSD on your bench today will look quaint in ten years (theme: technology changes, principles don't). What will not change is the lifecycle you are about to run: receive the question and scope it, acquire and verify, triage, analyze systematically, build the timeline, hunt for concealment, correlate across independent sources, report accurately, and stand behind it. Learn this sequence as a sequence, and you can investigate storage technologies that have not been invented yet. Learn only a tool's menus and you are obsolete the day the tool changes.

How to use this chapter

This is a guided, do-it-yourself capstone. The prose walks the full investigation on the MHA case as a worked example, so you can read it straight through as a model of how a complete matter flows. But the real value is in doing it: the Progressive project section at the end is the assignment, and it directs you to assemble the actual case-file folder you have been building since Chapter 5 into a finished, reviewable deliverable. Throughout, checkpoints mark the moments where you should stop and verify you have a concrete artifact in hand before moving on — because in a real case, a phase you "basically did" but never wrote down did not happen. A self-assessment rubric at the end lets you grade your own case file the way a technical reviewer (or an opposing expert) would.

A word on the case account names, because precision matters even here. The reader's running matter concerns a departed data engineer, the custodian, whose user profile on the laptop is jokafor. You — the examiner — are never named; you are "you," consistent with this book's voice. Where this chapter references the recurring teaching example of anchor case #2 (the employee whose CCleaner convicted itself, account jrivera), that is a different, parallel case used across Chapters 16, 21, and 30 to teach anti-forensics detection. Keep the two straight: jokafor is your case; jrivera is the textbook's worked anchor whose lessons you now apply to your own matter.

The case at a glance

Recall the assignment from Chapter 5. You have been retained by counsel for Meridian Health Analytics (MHA), a healthcare-analytics company. A senior data engineer, J. Okafor, resigned and joined a direct competitor; the resignation took effect 2026-06-13. Before departing, Okafor allegedly copied a proprietary patient-analytics dataset and supporting source code to removable media and/or a personal cloud account. The device under examination is the company-owned laptop Okafor used; MHA's authority rests on corporate ownership, a signed acceptable-use policy on file, and a login banner consenting to monitoring. Law enforcement is not involved — this is a civil matter. MHA's IT team acquired the image on 2026-06-15 and delivered it to you as mha-laptop.E01 with a sidecar mha-laptop.E01.sha256. You assigned it exhibit number MHA-2026-001.

   THE CASE FILE AT A GLANCE — MHA-2026-001
   ┌───────────────────────────────────────────────────────────────────────┐
   │ Matter:    Meridian Health Analytics v. [former employee] (civil)        │
   │ Question:  Was MHA proprietary data exfiltrated from this laptop before   │
   │            the custodian's departure? If so: what, by what means, when?   │
   │ Authority: Company-owned device; signed AUP; monitoring login banner.     │
   │            Civil matter; no law-enforcement involvement; no warrant.      │
   │ Custodian: J. Okafor (user profile `jokafor`), resigned 2026-06-13.       │
   │ Evidence:  Exhibit MHA-2026-001 = mha-laptop.E01 (compressed E01 image)   │
   │            Container SHA-256 b7e0c3f6…a1d4 (verified on receipt)          │
   │ Scope IN:  file access, removable-media use, cloud/webmail upload,        │
   │            timeline reconstruction on the provided image.                 │
   │ Scope OUT: Okafor's personal devices/accounts not on this image; any      │
   │            examination beyond MHA's lawful authority.                     │
   │ Deliverable: a complete, court-admissible case file.                      │
   └───────────────────────────────────────────────────────────────────────┘

Everything below assembles that deliverable. We proceed in twelve phases, and the phases are the lifecycle — keep the map in front of you.

The investigative lifecycle: a map you can hang on the wall

Before the first phase, internalize the whole arc. A digital investigation is not a grab-bag of techniques applied in whatever order curiosity suggests; it is a directed pipeline in which each phase produces an output the next phase consumes, and two disciplines — chain of custody and contemporaneous documentation — run underneath every phase without interruption.

   THE INVESTIGATIVE LIFECYCLE  (one case, twelve phases)

   1  ASSIGNMENT & SCOPE        ──► investigation plan, authority+scope, ethics
        (Ch.5, 25, 28)               memo, contraband contingency
   2  ACQUIRE & VERIFY          ──► verified image + working copy + open chain
        (Ch.14)                      of custody  (container hash vs bitstream hash)
   3  TRIAGE / LIVE / CRYPTO    ──► volatile capture if live; encryption
        (Ch.15, 22, 29)              assessment; acquisition strategy
   4  FILE SYSTEM & DELETED     ──► partition map, FS profile, recovered deleted
        (Ch.4, 6, 7)                 files (MFT remnants) + carved unallocated
   5  OS ARTIFACTS              ──► registry/USB history, prefetch, LNK,
        (Ch.16, 17)                  $Recycle.Bin, event logs, shellbags
   6  BROWSER / EMAIL / COMMS   ──► internet history, uploads, webmail,
        (Ch.18, 19)                  cloud-sync footprints, attachments
   7  PHOTO / DOC METADATA      ──► EXIF, Office authorship, hash-set matches
        (Ch.20)
   8  SUPER-TIMELINE            ──► one UTC-normalized, corroborated timeline
        (Ch.21)                      = the spine of the report
   9  ANTI-FORENSICS PASS       ──► wiping/timestomping/log-clear/hiding
        (Ch.30)                      indicators + NEGATIVE findings
  10  CORRELATE                 ──► convergent narrative; findings tied to
        (synthesis; Ch.26)           exhibits; alternatives tested
  11  REPORT                    ──► court-admissible report (the deliverable)
        (Ch.26)
  12  TESTIFY                   ──► testimony prep + survive cross-examination
        (Ch.27)
   ───────────────────────────────────────────────────────────────────────────
   UNDER EVERY PHASE:  ▸ chain of custody (unbroken)   ▸ document everything

Notice three things about the map. First, the phases are ordered for a reason — you cannot analyze a file system before you have a verified image, and you cannot write conclusions before you have correlated independent findings. Second, the analysis phases (4–9) are not strictly sequential in practice; you will loop among them as the timeline raises questions that send you back to the registry, and the registry raises questions that send you back to carving. The order on the map is the order of first pass; real cases iterate. Third, phases 10–12 — correlate, report, testify — are where most of the value and most of the danger live, and they are the phases hobbyists skip. The capstone exists largely to force you through them.

Recovery vs. Forensics. The lifecycle is shared by both disciplines, but the emphasis differs sharply, and naming the difference keeps you honest about which job you are doing. A 💾 data-recovery engagement runs phases 2–4 hard and largely stops there: acquire (to protect an irreplaceable original), then recover as much as possible, fast, and report how much came back and in what condition. It usually skips the legal machinery — no chain of custody, no anti-forensics pass, no court-ready report — because the client wants their photos back, not a conviction. A 🔍 forensic engagement runs all twelve, because the deliverable is not restored data but proven facts that survive an adversary. The wise practitioner runs every recovery job with enough of phase 1's discipline (who authorized this? what is the scope? document the hashes) that if the recovery turns into a case — the reformatted drive turns out to hold evidence of a crime, the ransomware job becomes an insurance dispute — the paperwork already holds up. You cannot retrofit a chain of custody. You can only have kept one.

Phase 1 — Receive the assignment and lock scope

The case begins not at the keyboard but on paper, and the discipline you impose here is the discipline an opposing expert will test last. You already did the core of this in Chapter 5's milestone: you received the assignment, verified the delivered container, and wrote a one-page Investigation Plan with explicit in-scope and out-of-scope statements and a list of testable questions. The capstone's job is to make sure that plan is complete and that two more documents sit beside it before any analysis proceeds: the Authority & Scope Memo from Chapter 25 and the Authority & Ethics Memo from Chapter 28.

The Investigation Plan states the objective in one or two sentences — determine whether MHA proprietary data was exfiltrated from the subject laptop prior to the custodian's departure, and if so, by what means, what data, and when — and then lists the questions that operationalize it as testable hypotheses. Crucially, it lists the disconfirming checks too: not only "was removable media attached and when?" but "what evidence would show that exfiltration did not occur?" An investigation plan that can only confirm the client's theory is not a plan; it is an advocacy brief, and it will not survive Chapter 28's objectivity requirement or Chapter 27's bias attack.

   INVESTIGATION PLAN — MHA-2026-001 (excerpt)
   Objective: determine whether MHA proprietary data was exfiltrated from the
   subject laptop before the custodian's 2026-06-13 departure; if so, by what
   means, what data, and when.

   Testable questions (each with a disconfirming check):
     Q1  Was external storage attached in the departure window? When/which/who?
         (disconfirm: no USBSTOR entries in window; no MountPoints2 under jokafor)
     Q2  Were the dataset/source-code files accessed or copied in that window?
         (disconfirm: no LNK/JumpList/RecentDocs hits; no $UsnJrnl copy records)
     Q3  Is there evidence of upload to personal cloud or webmail?
         (disconfirm: no TYPED cloud logins; no SRUM bytes; no sync footprints)
     Q4  Were timestamps altered or anti-forensic tools run?
         (disconfirm: $SI==$FN across files; no cleaner artifacts; no 1102 clears)
     Q5  Could anything OTHER than deliberate action explain the findings?
         (test: malware, remote access, automated sync, shared session)

   Authority: company-owned device; signed AUP; monitoring banner. Civil.
   In scope:  file access, removable-media, cloud/webmail upload, timeline.
   Out of scope: custodian's personal devices/accounts not on this image.

The Authority & Scope Memo records the legal basis in a form you can hand to counsel and, later, cite in the report's administrative section: the device is company property, the custodian signed the AUP, the login banner provided consent to monitoring, and the matter is civil with no law-enforcement involvement. It also fixes search methodology to scope — you will target file access, removable-media artifacts, cloud/webmail upload, and the timeline, and you will not rummage through the custodian's personal correspondence beyond what those questions require. Scope discipline is not bureaucratic throat-clearing; it is the difference between findings a court admits and findings a court suppresses.

The Authority & Ethics Memo is the layer Chapter 28 insists should have been present from the start. It documents your conflicts check (no financial stake in the outcome, no prior relationship with the parties, no prior handling of the evidence), your sensitive-data handling plan (this is a healthcare company — you will encounter patient data, which demands minimization and confidentiality controls), and — the item people skip because it feels paranoid in a civil IP case — your contraband contingency, written in advance.

Ethics Note. Write the contraband procedure before you need it, even in a civil matter, because you do not get to choose what you find. If, in the course of examining this laptop for stolen source code, you encounter apparent child-sexual-abuse material, the civil engagement does not govern your response — the law does. You stop, do not copy, preserve in place, isolate, document only path/hash/time/method (never content), and escalate to the appropriate authority, because possession and reproduction of such material are themselves crimes under 18 U.S.C. §2252/§2252A regardless of your role, and reporting duties attach. Having that procedure written down before the moment arrives is what lets you execute it calmly instead of improvising at the worst possible time. The full treatment — mandatory reporting, NCMEC/the CyberTipline, and examiner well-being — is owned by Chapter 28; the capstone's job is to confirm the procedure is in your file now.

Legal Note. The civil/criminal distinction shapes everything downstream. Because MHA's authority is corporate and consent-based rather than a warrant, your scope is defined by the engagement and the company's lawful reach — and it does not extend to Okafor's personal cloud accounts or personal devices, which live behind separate authority (Chapter 31 covers the legal process required to reach provider-held data). If the civil matter later refers a criminal aspect to law enforcement, the chain of custody and hashing you maintain from phase 2 onward are exactly what let the evidence cross that boundary intact. The frameworks are tabulated in Appendix E.

Checkpoint 1. Before phase 2, your case-file folder should contain three documents: the Investigation Plan (with disconfirming checks), the Authority & Scope Memo, and the Authority & Ethics Memo (with the contraband contingency). If any is missing, you are not ready to analyze.

Phase 2 — Acquire, verify, and open the chain

The whole case rests on this phase: an examination is only as trustworthy as the image beneath it. In the MHA matter the image was acquired by MHA's IT team and delivered to you, so your job is to verify rather than acquire — but you treat the verification with the same rigor you would a fresh acquisition, because you will testify to it.

First, confirm the file you received equals the file MHA sent. The sidecar mha-laptop.E01.sha256 carries the container hash — the SHA-256 of the .E01 file as a file, which proves transit integrity:

# Transit integrity: does the received container match the sidecar value?
sha256sum -c mha-laptop.E01.sha256
#   mha-laptop.E01: OK
#   container SHA-256 = b7e0c3f6a9d2b5e8a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4

Then load the image into your analysis tool and let it re-verify the acquisition (bitstream) hash stored inside the E01 — a different number doing a different job. The container hash proves the file arrived unaltered; the bitstream hash proves the imaged data equals what was read from the source disk at acquisition. Confusing the two is a classic rookie error and a cross-examination gift, so record both, clearly labeled:

   IMAGE VERIFICATION — Exhibit MHA-2026-001 (mha-laptop.E01)
   ─────────────────────────────────────────────────────────────────────
   Container (file in transit):
     SHA-256  b7e0c3f6a9d2b5e8a3f5c9d2b8e14f6079c2d5a8b1e4f7c0d3a6b9e2c5f8a1d4
     verified against sidecar on receipt 2026-06-22 ...................... OK

   Acquisition / bitstream (data inside the E01, re-verified on load):
     MD5      a3f5c91e8b2d47a06c1f9e3b5d8a2c40
     SHA-256  9f2b6c8e0a4d7f1c3b5e8a02d6c9f4e7b1a3c5d8f0e2b4a6c8d0f2e4b6a8c0d2e
     stored acquisition hash == recomputed hash ......................... VERIFIED
     source bytes: 512,110,190,592  (1,000,215,216 sectors × 512)
   ─────────────────────────────────────────────────────────────────────

Now make a working copy, confirm its hash equals the acquisition value, and resolve — in writing — to analyze only the copy from here on. The original image goes to read-only storage; the original sealed evidence (if you ever take physical custody) stays sealed. This is theme #2 of the entire book made operational: the original is sacred. And you open the chain-of-custody log for MHA-2026-001 with the first entries — received from whom, when, the verified hashes, the working copy created — using the template in Appendix F.

# Make and verify the working copy; analyze only the copy.
cp mha-laptop.E01 working/mha-laptop-WORK.E01
hashdeep -c md5,sha256 working/mha-laptop-WORK.E01   # must equal acquisition hash
# Re-verify before EVERY analysis session, not just once.

Chain of Custody. The chain is a single unbroken story, and the same hash value must appear identically everywhere it is cited — in the inventory, the methodology, the relevant findings, and the custody log. If a defense expert finds one place where the hash in a finding does not match the hash in the inventory, even a transposed character, you have handed them a day of cross-examination on whether you examined the evidence at all. Generate your exhibit hash list mechanically (you will see how in phase 10) so it cannot drift from the files it describes. Consistency across the case file is not pedantry; it is the property that makes the whole document cohere under attack.

Checkpoint 2. You now have: a verified working copy whose hash matches the acquisition value, both hashes recorded and labeled (container vs. bitstream), and an open chain-of-custody log. Re-verification before each session is part of the habit, not an afterthought.

Phase 3 — Triage, the live-or-dead decision, and the encryption question

In the MHA matter you received a dead-box image, so the triage decisions were made before you arrived. But a capstone must teach the judgment, because most real cases arrive with the machine still running, and the choices you make in the first ten minutes can decide whether the evidence is recoverable at all. Chapter 15's progressive step posed exactly this escalation: the subject machine reported found powered on and logged in, with an unknown encryption posture and a suspected active network connection. What do you do?

The answer flows from the order of volatility: capture the most fleeting evidence first. A running, logged-in, possibly-encrypted machine is a closing window. If full-disk encryption is in play, the decryption key is in RAM right now and will be gone the instant power is lost — pull the plug and you may convert an open case into an unreadable one (Chapter 29 makes this life-or-death for the evidence). So the triage sequence on a live box is: photograph the screen and document state; capture RAM with a validated tool to an external target (Chapter 22); collect the most volatile live artifacts (network connections, running processes, logged-on sessions) per Chapter 15; and only then make the dead-box decision (sound shutdown vs. hard power-off vs. live image), recording your reasoning.

For the MHA image, the corresponding capstone task is the encryption assessment from Chapter 29. You run an entropy scan and check for volume signatures: -FVE-FS- would mark BitLocker, LUKS\xBA\xBE would mark LUKS, the APFS encryption flag would mark FileVault, and the conspicuous absence of any signature in a high-entropy region would flag a possible VeraCrypt container. Suppose the MHA laptop's system volume is BitLocker-protected. You do not panic; you enumerate lawful key sources for this authority. Because the device is corporate, the recovery key is almost certainly escrowed in MHA's Active Directory / Entra — the quiet, common win that opens a corporate laptop in an hour. You retrieve the 48-digit recovery key from escrow (provenance documented), unlock a working copy, mount it read-only, and record both the pre- and post-decryption hashes so the provenance is unbroken.

   ENCRYPTION ASSESSMENT — MHA-2026-001
   Volume:  \\.\Volume{...}  system partition
   Signature at offset 0:  2D 46 56 45 2D 46 53 2D  ("-FVE-FS-")  => BitLocker
   Protectors:  TPM+PIN ; Recovery Password (48-digit) ; Numerical (AD escrow)
   Lawful key source used:  AD recovery password (escrow), retrieved 2026-06-22,
                            authorized by MHA per engagement; provenance logged.
   Action:  unlocked WORKING COPY; mounted read-only; hashes recorded pre/post.
   Finding: decryptable via corporate escrow; analysis proceeds.

If no lawful key existed — strong passphrase, no escrow, no resident key, no memory capture — the professional finding would be the clinical "acquired, verified, and inaccessible; recoverable only via [escrow/PIN/court order]," and that is a complete result, not a failure. Knowing which sentence to write is the skill.

Recovery vs. Forensics. The live-capture moment is where the 🛡️ incident-response and 🔍 forensic mindsets briefly pull apart and then snap back together. IR optimizes for speed and containment: capture volatile state fast, often with lighter documentation, because a breach is ongoing and minutes matter. Forensics optimizes for admissibility: every command run on the live box is itself an alteration, so you document exactly what you ran, when, and with what tool, and you accept that a RAM image is a slightly smeared snapshot rather than a frozen instant — you manage the smear by documenting it, not by pretending it isn't there. The reconciliation is that a disciplined IR responder produces capture that also holds up forensically, which is why the best responders document as they go even under pressure. The case that starts as an incident and becomes a lawsuit — and many do — rewards the responder who treated the first ten minutes as evidence collection.

Phase 4 — File system and deleted-file analysis

With a verified, mounted, read-only working copy in hand, the analysis proper begins, and it begins where the data lives: the file system. First, characterize the media before examining a single user file — the discipline from Chapter 4. Read the partition map and the file-system profile so you know the terrain:

mmls working/mha-laptop-WORK.dd      # partition table: MBR/GPT, offsets, sizes
fsstat -o 2048 working/mha-laptop-WORK.dd   # NTFS profile: cluster size, $MFT loc
#   File System Type: NTFS
#   Cluster Size: 4096          (8 sectors × 512 = one 4 KiB cluster)
#   Total Cluster Range: 0 - 124,975,615
#   $MFT  Entry size: 1024 bytes

Now recover deleted files. Recall the foundational truth from Chapter 2: deletion removes the pointer, not the data — deleted ≠ destroyed. On NTFS, a deleted file's $MFT entry often survives with its attributes intact until the entry is reused, so the first, cleanest recovery is to enumerate deleted MFT records and extract their contents by inode (Chapter 6):

# Enumerate deleted entries (the leading * marks deleted; -d = deleted only)
fls -o 2048 -r -d working/mha-laptop-WORK.dd
#   * 41902-128-3   patients_q3_2026.csv
#   * 41955-128-3   ingest_pipeline.py
#   * 42013-128-4   model_training.tar.gz

# Extract one by inode to a hashed working file (read-only on the image)
icat -o 2048 working/mha-laptop-WORK.dd 41902 > recovered/patients_q3_2026.csv
sha256sum recovered/patients_q3_2026.csv

Where the MFT entry has already been overwritten — the data still on disk but the pointer gone — you fall back to file carving (Chapter 7): scan unallocated space for known headers and footers and reconstruct files by signature alone. A carved CSV has no file name and no metadata, but its contents may still match the proprietary dataset. The annotated carve below shows a recovered JPEG embedded in a document export, identified purely by its magic bytes — the same signatures catalogued in Appendix A:

   CARVED FROM UNALLOCATED — offset 8,589,934,592 (cluster 2,097,152 × 4096)
   00000000  FF D8 FF E1 00 18 45 78  69 66 00 00 49 49 2A 00  |......Exif..II*.|
             ^^^^^^^^^^^                                         JPEG/EXIF header
   ...                                                          (image data)
   0003F2FE  ... FF D9                                          |......|
                  ^^^^^                                          JPEG EOI (footer)
   Method: PhotoRec 7.2 signature carve. No file name/MFT entry (carved).
   SHA-256 of carved object recorded for the exhibit hash list.

The MHA case yields both kinds of recovery: active copies of the dataset and source-code files still present in the file system, and deleted copies recovered from MFT remnants in unallocated space — the latter indicating the files had been deleted before imaging, which is itself a finding worth its limitation (deletion is consistent with cleanup but does not by itself prove intent).

Recovery vs. Forensics. The exact same carving and MFT-remnant techniques you just applied to find stolen source code are what reunite a grieving family with ten years of accidentally-reformatted wedding photos — the anchor case that opened this book (Chapter 1). The bytes do not know whether they are evidence or memories. What differs is the consequence: in recovery you maximize the count of files restored and report the success rate; in forensics you record each recovered file's offset, method, and hash so its provenance is provable in court. One skill, two purposes — the dual lens that runs through every chapter of this book.

Phase 5 — Operating-system artifacts

The file system tells you what files exist and existed; the operating system tells you what was done with them. On Windows, this is the richest evidence layer in most cases, and the MHA investigation lives here. You extract the registry hives (SYSTEM, SOFTWARE, SAM, each user's NTUSER.DAT and UsrClass.dat, and Amcache.hve) with their transaction logs, the .evtx event logs, and the Prefetch directory, hashing each into the chain-of-custody worksheet, then parse with validated tools (Chapter 16). The single most valuable thread for an IP-theft case is the USB device history, reconstructed by chaining three registry locations into device-plus-user-plus-time attribution:

   USB DEVICE HISTORY  (chained for attribution)  — MHA-2026-001
   ─────────────────────────────────────────────────────────────────────
   SYSTEM\CurrentControlSet\Enum\USBSTOR\
       Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00\4C530001120830117433&0
       FriendlyName: SanDisk Ultra USB Device   (the DEVICE)
   SYSTEM\MountedDevices\
       \DosDevices\E:  -> volume GUID + disk signature  (the DRIVE LETTER)
   NTUSER.DAT (jokafor)\...\Explorer\MountPoints2\{volume-GUID}
       last-write 2026-06-11 20:47:13 UTC          (WHICH USER + WHEN)
   ─────────────────────────────────────────────────────────────────────
   => SanDisk Ultra (serial 4C530001120830117433) first connected under the
      jokafor profile on 2026-06-11 20:47:13 UTC (volume serial 1A2B-3C4D).

That same MountPoints2 last-write timestamp, stored as a Windows FILETIME, looks like this in the raw hive — a detail worth being able to read, because a cross-examiner may ask whether the tool decoded it correctly:

   FILETIME (100-ns ticks since 1601-01-01 UTC), stored LITTLE-ENDIAN on disk:
     80 5E F4 7A E3 F9 DC 01   = 0x01DCF9E37AF45E80 = 134,256,844,330,000,000
   Convert to Unix: subtract 116,444,736,000,000,000, divide by 10,000,000
     => 2026-06-11 20:47:13 UTC

Around that anchor, the other Windows artifacts corroborate file access and program execution. LNK files and Jump Lists show the dataset and source-code files were opened from volume serial 1A2B-3C4D — the very removable device — proving access even though the device itself is long gone. RecentDocs, UserAssist, and shellbags in UsrClass.dat place the activity under jokafor. Prefetch and Amcache.hve separate execution from mere presence (a distinction you must preserve in the report: Prefetch proves a program ran, with run counts and the last eight run times; Amcache proves a binary was present, with a SHA-1 and a path). The .evtx Security log places logon sessions (event 4624, with logon type) at the relevant times. Each artifact is parsed with a primary tool (the Eric Zimmerman suite — RECmd, PECmd, LECmd, AmcacheParser, EvtxECmd) and at least one load-bearing finding cross-checked with a second (RegRipper or Autopsy), because corroboration across tools is part of reliability.

# Illustrative: confirm a single recovered artifact's hash before citing it.
Get-FileHash -Algorithm SHA256 'X:\cases\MHA-2026-001\artifacts\NTUSER-jokafor.DAT' |
    Select-Object Algorithm, Hash

Limitation. Every artifact in this phase ties activity to a user account, device, or session — never to a pair of hands. The registry can prove that the jokafor profile mounted a SanDisk Ultra at 20:47:13 UTC and opened the dataset from it; it cannot prove which human being's fingers were on the keys. Another person could have used an unlocked session; credentials could have been shared. You write "activity occurred within the jokafor profile" (fact) and reserve any statement about the operator for a clearly labeled, honestly qualified inference. This account-vs-person line, first drawn in Chapter 5 and owned by the report in Chapter 26, is the seam a cross-examiner presses hardest; draw it yourself before they draw it for you.

Phase 6 — Browser, email, and communications

Files moved to a USB stick are one exfiltration channel; the cloud is the other, and it lives in the browser and the communications stores. The MHA investigation plan named "upload to personal cloud or webmail" as a testable question, and this phase answers it. You preserve every browser profile on the image — for Chromium, the History/Cookies/Login Data/Web Data databases with their -wal/-shm companions and the root Local State; for Firefox, places.sqlite and friends; for Safari, History.db and the binary cookie store — hashing each, then querying read-only so the SQLite engine never checkpoints your evidence (Chapter 18). The recognizable SQLite format 3\0 magic confirms the store type before you open it.

The decisive distinction in browser history is the transition type: a TYPED navigation means the user deliberately entered the address, while a subframe or redirect is incidental. For the MHA case you find TYPED navigations to a personal cloud-storage login on 2026-06-12, followed by upload activity. Crucially, you corroborate the volume of data moved with SRUM (the System Resource Usage Monitor, SRUDB.dat), which records per-application network bytes — here showing roughly 490 MB of outbound data from the browser process in the upload window, a figure consistent with the dataset's size. You enumerate cloud-sync footprints (Dropbox info.json, Google DriveFS metadata_sqlite_db, OneDrive .odl) to test for a second exfiltration path, and you recover deleted history from the WAL and the SQLite freelist, because cleared rows persist there — deleted is not destroyed, even in a database.

   BROWSER / INTERNET — exfiltration channel (MHA-2026-001)
   Chromium History (jokafor profile):
     2026-06-12 19:18 UTC  TYPED   https://[personal-cloud]/login     (deliberate)
     2026-06-12 19:21 UTC  LINK    https://[personal-cloud]/upload    (in-session)
   SRUM (SRUDB.dat), app=chrome.exe:
     2026-06-12 19:18–19:44 UTC   BytesSent ≈ 490 MB  (outbound)
   Recovered from History -wal (cleared rows):  3 additional cloud URLs
   Cloud-sync footprints: none for corporate accounts; personal Drive present.

The communications layer (Chapter 19) adds context: webmail fragments in the browser cache, any PST/OST or mbox stores, and message headers that timestamp the resignation correspondence and any attachments. In the MHA matter the email layer supplies motive-adjacent context — the timing of the competitor offer relative to the exfiltration window — which you report as dated facts, never as a claim about the custodian's state of mind.

Limitation. Browser and SRUM evidence proves that a profile requested URLs and that a process sent bytes; it does not, by itself, prove what was inside those bytes or who was watching the screen. SRUM's per-app counters are an aggregate, not a packet capture, so "≈490 MB sent by chrome.exe in the window" supports an inference of a large upload consistent with the dataset, but it is not proof that the dataset specifically was uploaded — that inference strengthens only when the timeline ties it to the file access and the data sizes align. State each finding for exactly what it shows and let the strength come from convergence, not from any single artifact carrying more weight than it can bear.

Phase 7 — Photo, document, and media metadata

Files carry interior records of their own history, and this phase reads them (Chapter 20). For the MHA source code and dataset, the most useful interior metadata is in the Office documents and exports: Last Saved By, Author, Company, creation and modification timestamps, and revision counts embedded in the document's internal structure. A spreadsheet whose Author field names an MHA template and whose Last Saved By names the custodian, last-saved in the exfiltration window, ties the file to its origin and its handler independent of the file system's external timestamps. Photographs, where present, carry EXIF: camera make/model, DateTimeOriginal, and sometimes GPS — read with a tool like exiftool, on hashed working copies, every extraction logged.

This phase is also where the book's most consequential anchor touches the capstone, and it does so through a purely technical mechanism that deserves emphasis precisely because it keeps the work clinical. In matters involving illegal imagery, examiners identify known files by hash-set matching (the Project VIC and NCMEC libraries) and PhotoDNA perceptual hashing — comparing a file's hash against a curated set so the file can be flagged without anyone viewing it. The identical mechanism serves the MHA case: you can confirm that a recovered file is a specific MHA proprietary dataset by matching its hash to a reference hash MHA provides, without opening and inspecting megabytes of patient data you have a duty to minimize. Same technique, different stakes — and in the gravest cases, the hash-set method is what lets an examiner do necessary work while limiting exposure to traumatic material.

Ethics Note. Identifying files by hash rather than by visual inspection is not only efficient; in the courtroom anchor case it is an ethical instrument with two beneficiaries (theme #6, the human cost is real). It protects the dignity of victims, because their images are never narrated into a court document — the finding reads "a file whose SHA-256 matches a known entry was recovered," never a description of content. And it protects the examiner from unnecessary exposure to material that causes real secondary trauma. In the MHA case the same restraint serves a humbler purpose: it lets you prove a dataset's identity without trawling a stranger's medical records. The clinical, non-graphic discipline this book maintains around the anchor case is not squeamishness; it is professionalism, and Chapter 28 owns its full treatment, including examiner well-being.

Phase 8 — Build the super-timeline

Now you fuse every dated source into one chronological argument — the step where a pile of fragments becomes a narrative (Chapter 21). Begin with the Rosetta-stone problem: convert every source's clock to one standard. Read the evidence system's TimeZoneInformation from the SYSTEM hive, normalize everything to UTC, and measure clock skew against an external reference (a mail-server Received header, a server-side auth log) so you can state the time standard in one defensible sentence. Then build the timeline two ways: a file-system spine with fls -m -r piped to mactime -z UTC, and a comprehensive super-timeline with log2timeline.py into a .plaso store, sorted with psort.py. Pull both the $STANDARD_INFORMATION` and `$FILE_NAME MACB sets with MFTECmd so timestamp divergences are visible — you will need them in phase 9.

The payoff is a single, source-annotated master timeline that lays the case's events on one axis. For the MHA matter the cluster around the departure window reads as a coherent sequence — connection, access, copy, upload, cleanup — each line tied to the artifact that produced it:

   MASTER TIMELINE (excerpt, UTC) — MHA-2026-001    [source in brackets]
   2026-06-08 14:02  competitor-offer email received        [OST/headers, Ch.19]
   2026-06-11 20:47:13  SanDisk Ultra first connected,jokafor[USBSTOR/MP2, Ch.16]
   2026-06-11 21:02–21:39  dataset + source files opened
                           from volume serial 1A2B-3C4D      [LNK/JumpList, Ch.16]
   2026-06-11 21:05–21:41  files copied to E:\               [$UsnJrnl:$J, Ch.21]
   2026-06-12 19:18  TYPED login to personal cloud           [Chromium Hist, Ch.18]
   2026-06-12 19:18–19:44  ≈490 MB outbound (chrome.exe)     [SRUM, Ch.18]
   2026-06-12 22:05  CCleaner executed (run #1 of 1)         [Prefetch, Ch.30]
   2026-06-13         resignation effective                  [HR record, context]
   ───────────────────────────────────────────────────────────────────────────
   Time standard: all times UTC; skew verified ±2 s vs. mail server; no 4616
   system-clock-change events in window.

Every load-bearing line is confirmed by a second independent source — the USB connection by both the registry and the $UsnJrnl change journal, the upload by both browser history and SRUM — because a timeline is only as strong as the corroboration beneath each entry. And beside any line whose limits you must state (SRUM is aggregate not content; LNK proves access not authorship), you note the caveat now, so future-you writes it honestly in the report.

Tool Tip. Build the timeline twice on purpose. The fls/mactime bodyfile spine is surgical and fast and shows you the file-system MACB story cleanly; the log2timeline/plaso super-timeline is comprehensive, pulling event logs, registry, browser, LNK, prefetch, and dozens of other parsers into one stream. Triage the big timeline in Timeline Explorer with the anchor → window → expand method: pivot from your strongest known event (here, the USB connection), filter to the surrounding window, and read the cluster outward. Hash both intermediate files (the bodyfile and the .plaso) into your custody worksheet so the timeline itself is reproducible. The full epoch and MACB reference is in Appendix G and the command syntax in Appendix H.

Phase 9 — Detect anti-forensics

A thorough examination includes a dedicated pass for concealment, and it is in this phase that the case either reveals a suspect who covered tracks or earns the negative findings that prove your thoroughness. The meta-principle is the book's third theme: every action leaves a trace, and the absence of a trace is itself a trace. Anti-forensic tools leave artifacts; deleted logs leave gaps; timestomping leaves metadata inconsistencies. You hunt across four fronts (Chapter 30).

Wiping. An entropy scan flags contiguous zeroed or random regions, and you inventory wiping-tool artifacts directly: Prefetch, Amcache, and registry keys (HKCU\Software\Piriform\CCleaner, Eraser, BleachBit, the SDelete EULA key). In the MHA case, you find that a cleaner ran once in the cleanup window — and like anchor case #2's CCleaner, it convicts itself. The tool's own Prefetch entry (CCLEANER64.EXE-XXXXXXXX.pf) records that it executed at 2026-06-12 22:05 UTC; the registry key proves it was installed and configured; and the dated holes it left — recently-wiped MRUs whose last-write times sit in the window, gaps in browser history that the WAL still partially fills — are themselves evidence that something was cleaned, and when.

Timestomping. You compare $STANDARD_INFORMATION` against the kernel-maintained `$FILE_NAME. The user-settable $SI` can be backdated by a tool; the `$FN is far harder to forge. For one source-code archive you find exactly the tell:

   TIMESTOMP DETECTION  (MFTECmd export) — model_training.tar.gz
   ─────────────────────────────────────────────────────────────────────
   $STANDARD_INFORMATION  Born: 2024-01-05 09:00:00.0000000   <- forged (zeroed
                                                                  sub-seconds)
   $FILE_NAME             Born: 2026-06-11 21:05:47.3318442   <- kernel truth
   $UsnJrnl:$J            FILE_CREATE 2026-06-11 21:05:47      <- corroborates
   ─────────────────────────────────────────────────────────────────────
   => $SI Born predates $FN Born by ~2.4 years and shows zeroed sub-seconds:
      classic timestamp manipulation. True creation 2026-06-11, per $FN + USN.

Log tampering. You run EvtxECmd and search for event IDs 1102 (Security log cleared) and 104 (System/other log cleared), sort by EventRecordID to spot gaps from surgical deletion, and compare each log's earliest timestamp against the System log's boot history. In the MHA case, suppose no 1102 clear appears — a negative finding you report, because its absence means the log record of logons and activity is intact and uncontested.

Hidden data. You enumerate NTFS alternate data streams (dir /r, fls), examine slack space, check for HPA/DCO, and run a signature-vs-extension mismatch scan to catch a file masquerading as another type. High-entropy blobs that suggest an encrypted container get flagged with the application artifacts that would explain them.

The discipline that makes this phase defensible is reasoning from absence carefully. For every conspicuous absence, you write both the anti-forensic hypothesis and the innocent alternative, and you state which the corroborating evidence supports. A sparse Prefetch could mean a cleaner ran — or that the machine was rarely used. You do not assert the sinister reading without corroboration, and you mark leads you cannot yet confirm as leads, not findings.

War Story. A civil examiner once built an entire misappropriation theory on a single $STANDARD_INFORMATION` "access" time, testifying that a confidential file had been opened the night before the employee resigned. At deposition the opposing expert demonstrated that the cited timestamp had been updated by an automated backup agent, not a human open — a confusion of MACB semantics that a five-minute `$SI-vs-$FN comparison and a glance at the USN journal would have caught. The core theory survived on other evidence, but the examiner's credibility did not, and every other finding in the report was treated with suspicion for the rest of the case. The lesson is the phase-9 lesson exactly: trust the kernel's clock over the user's, corroborate every load-bearing time against an independent source, and never let one artifact carry a conclusion alone.

Phase 10 — Correlate: from artifacts to a coherent narrative

This is the phase with no chapter of its own, because it is the synthesis of all of them — and it is where competent examiners become good ones. You now hold dozens of findings from six evidence layers. Correlation is the discipline of asking, for each conclusion you want to draw, which independent sources converge on it, and what alternative explanations does the convergence rule out? A single artifact is a data point; a conclusion is a pattern that independent artifacts, produced by different mechanisms, all support.

For the MHA case the convergence is the heart of the matter. The claim "the proprietary dataset was copied to removable media on the evening of 2026-06-11" rests not on one artifact but on a braid: the registry USB history (device connected under jokafor at 20:47:13), the LNK/Jump List access from volume serial 1A2B-3C4D, the $UsnJrnl file-create records on E:, and the timeline that places them in sequence — four mechanisms, one story. The claim "data was uploaded to personal cloud on 2026-06-12" braids the TYPED browser navigation, the SRUM byte counters, and the recovered deleted history rows. The braid is strong precisely because the strands are independent: it is not plausible that four different subsystems coincidentally fabricated a consistent, corroborated sequence.

Equally important is what correlation rules out — the disconfirming checks from your investigation plan. You searched for malware and remote-access tooling that could explain the file activity without a human at the console, and found none; that negative finding strengthens the inference of deliberate action while demonstrating impartiality. You tested whether an automated synchronization process could account for the cloud bytes, and the TYPED login (a deliberate human act) argues against it. You confirmed no system-clock-change events corrupted the timeline. Each disconfirming check you ran and reported makes the conclusion harder to attack and discharges your duty to seek exculpatory as well as inculpatory evidence.

The practical mechanism for keeping correlation honest is the structured finding object you met in Chapter 26 — observation, supporting artifacts, interpretation, limitation. Filling every field forces fact and inference onto separate rungs and exposes any conclusion that lacks corroboration. A small, illustrative helper makes the convergence visible by requiring at least two independent sources before a claim is allowed to graduate from "lead" to "supported finding":

from dataclasses import dataclass, field

@dataclass
class CorrelatedFinding:
    """A claim is 'supported' only when independent sources converge on it.
    Illustrative — never executed here; the discipline is the point."""
    claim: str
    sources: list = field(default_factory=list)   # (artifact, chapter, time)
    rules_out: list = field(default_factory=list)  # alternatives tested/negated
    limitation: str = ""

    @property
    def supported(self) -> bool:
        # require >= 2 INDEPENDENT mechanisms before calling it supported
        mechanisms = {s[0] for s in self.sources}
        return len(mechanisms) >= 2

copy_to_usb = CorrelatedFinding(
    claim="MHA dataset/source copied to removable device on 2026-06-11 evening",
    sources=[
        ("registry/USBSTOR+MountPoints2", "Ch.16", "2026-06-11 20:47:13Z"),
        ("LNK/JumpList volume 1A2B-3C4D",  "Ch.16", "2026-06-11 21:02–21:39Z"),
        ("$UsnJrnl:$J FILE_CREATE on E:",  "Ch.21", "2026-06-11 21:05–21:41Z"),
        ("master timeline sequence",       "Ch.21", "2026-06-11"),
    ],
    rules_out=["no malware/RAT identified (Ch.30 negative finding)",
               "no system-clock-change (event 4616 absent)"],
    limitation=("establishes copy from the jokafor profile to a device with "
                "volume serial 1A2B-3C4D; does NOT identify the physical "
                "operator, and the device itself was not provided for exam."),
)
assert copy_to_usb.supported   # 4 independent mechanisms converge

The narrative you assemble from these correlated findings is stated proportionately — the cardinal discipline of Chapter 26. The evidence supports "consistent with copying of the proprietary dataset to a removable device on 2026-06-11 and upload to a personal cloud account on 2026-06-12." It does not support "Okafor stole the data" — that imports intent you cannot observe in bytes and a legal verdict that belongs to the court, not the examiner. Where the evidence is mixed, you say so. Correlation produces a story; proportionality keeps the story inside the fence the evidence builds.

Recovery vs. Forensics. Correlation is also the phase where a 💾 recovery job quietly reveals whether it has become a 🔍 forensic case. A recovery engineer who set out merely to restore a reformatted drive may, in correlating what came back, notice a pattern that implies wrongdoing — deleted financial records, a wiped period right before an audit, an exfiltration footprint. The moment that pattern appears, the engagement has changed character: the engineer must stop, preserve, document, and advise the client that what began as recovery now needs the chain-of-custody and reporting rigor of a forensic matter. Recognizing that pivot — and having kept enough discipline that you can pivot — is the professional judgment this book has been building toward.

Phase 11 — Write the court-admissible report

The analysis is invisible until you write it down; the report is the only part of your work anyone else will see, and it is the thing you will be cross-examined on years later when memory is gone and only the writing remains (Chapter 26). Phase 11 assembles every prior phase's output into the report's standard anatomy, and the beauty of running the lifecycle in order is that each section is already populated by a phase you completed.

   REPORT ASSEMBLY MAP — which phase fills which section
   ┌──────────────────────────────────┬────────────────────────────────────┐
   │ REPORT SECTION                    │ FILLED BY                          │
   ├──────────────────────────────────┼────────────────────────────────────┤
   │ Administrative / authority+scope  │ Phase 1 (plan, scope, ethics memos) │
   │ Executive summary (written LAST)  │ Phase 10 (correlated narrative)     │
   │ Evidence inventory (hashes)       │ Phase 2 (acquisition + container)   │
   │ Tools & methodology (versions)    │ Phases 2–9 (every tool, pinned)     │
   │ Findings (tied to exhibits)       │ Phases 4–9 (the four-part findings) │
   │ Conclusions (proportionate)       │ Phase 10 (what the braid supports)  │
   │ Limitations & assumptions         │ Phases 5,6,9,10 (the caveats noted) │
   │ Appendices / exhibits             │ Phase 2–9 hashes, CoC, timeline,CV  │
   └──────────────────────────────────┴────────────────────────────────────┘

You write the report for three readers at once — the attorney who needs meaning, the lay reader (judge or jury) who needs clarity, and the opposing expert who needs reproducibility — and you serve all three by layering: plain-language conclusions at the front, dense offsets and hashes at the back. The executive summary, written last when you actually know what the report concludes, states in ninety seconds what MHA's general counsel can act on, including any bad news. The findings, each built as observation → artifacts → interpretation → limitation, tie every claim to a reproducible coordinate. The conclusions stay proportionate. The limitations section pre-empts, in writing and on your own initiative, the two questions the defense will press hardest — who was at the keyboard? and could something other than deliberate action explain this? And because this is civil litigation that may produce a testifying expert, you note which FRCP 26(a)(2)(B) elements the expert-report version would add: all opinions and their bases, the facts considered, your qualifications, prior testimony in the last four years, and your compensation.

Then you build the appendices the skeptical reader lives in — and you build the exhibit hash list mechanically, so the appendix that proves your exhibits cannot drift from the files your findings cite:

# Generate Appendix C from the exhibits themselves; it cannot disagree
# with the findings that reference these hashes.
hashdeep -c md5,sha256 -r /cases/MHA-2026-001/exhibits/ \
    > appendix-c-exhibit-hashes.txt

# Capture exact tool versions into the methodology version block.
fls -V ; photorec --version 2>/dev/null ; exiftool -ver ; python3 --version

Finally, no report leaves on one person's judgment. You submit it to technical review (a second examiner checks that findings are reproducible, hashes agree everywhere, conclusions are supported, and negative findings are present) and editorial review (clarity for a lay reader, defined terms, neutral language, complete sections). Run the language-review habit over your own draft first — hunt every "obviously," "clearly," "must have," and "the user did X," and rewrite each into a statement the evidence supports.

Checkpoint 3. Your case file now contains a complete report — a clearly labeled draft and a final — with an executive summary that stands alone, findings tied to exhibits, proportionate conclusions, an honest limitations section, a mechanically generated exhibit hash list, the chain-of-custody record, a glossary, and a CV placeholder. Templates for every section are in Appendix F.

Phase 12 — Prepare for and survive cross-examination

A report is only as strong as your ability to stand behind every word of it under oath, and the final phase turns the document into trial-ready work (Chapter 27). You assemble a testimony preparation package of four artifacts and fold it into the case file: a qualifications proffer (the CV and the narrative your attorney uses to qualify you under Daubert and FRE 702, claiming nothing you cannot document); a red-team of your own report (for each finding, the strongest cross-examination attack you can invent and your honest, calibrated answer); three plain-language explanations of technical findings with accurate analogies and their limits; and a morning-of-trial integrity log re-verifying the working image against the acquisition hash so you can testify to current integrity.

The red-team is the centerpiece, and it is organized around the seven classic cross-examination attacks. The drill below shows each attack pressed against the MHA report and the disciplined answer — answers that win not by out-arguing the lawyer but by being unimpeachable, because the report already drew the lines:

   CROSS-EXAMINATION DRILL — MHA-2026-001 (seven classic attacks)
   ─────────────────────────────────────────────────────────────────────
   1. CHAIN-OF-CUSTODY GAP
      Q: "Can you prove this image is the same data that was on the laptop?"
      A: "Yes. The acquisition hash recorded at imaging matches the hash I
          recomputed on load and again this morning; all three are in the
          report at Appendix C and the custody log."
   2. TOOL RELIABILITY
      Q: "How do you know your carving tool didn't fabricate that file?"
      A: "PhotoRec 7.2, validated against the NIST CFReDS reference image on
          [date] with the expected result; the carve is reproducible from the
          offset and signature stated in Finding F-0X."
   3. ALTERNATIVE EXPLANATION (Trojan/SODDI)
      Q: "Couldn't malware have copied those files without your client knowing?"
      A: "I searched for malware and remote-access tooling and found none; that
          negative finding is reported at F-0Y. I cannot exclude every
          possibility, but the evidence identified none."
   4. EXAMINER BIAS
      Q: "MHA is paying you. Didn't you set out to find them guilty?"
      A: "My engagement is hourly, not contingent. My plan listed disconfirming
          checks, and I reported the negative findings as fully as the positive."
   5. OVERSTATEMENT
      Q: "So you're telling this jury the defendant stole the data?"
      A: "No. The evidence is consistent with copying to a device on 2026-06-11
          and upload on 2026-06-12. Who acted, and with what intent, is not
          something the forensic evidence alone establishes."
   6. SCOPE
      Q: "Did you examine my client's personal phone and home computer?"
      A: "No. Those were outside the authority and scope of this engagement,
          as stated in the report's scope section."
   7. TIMESTAMP WEDGE
      Q: "Timestamps can be faked. How can you trust any of your dates?"
      A: "Correct that $STANDARD_INFORMATION can be altered — which is why I
          corroborate every load-bearing time against the kernel-maintained
          $FILE_NAME and the USN journal, as shown in F-0Z. One archive WAS
          backdated; I detected and reported it."
   ─────────────────────────────────────────────────────────────────────

Notice that every disciplined answer points back to something already in the report — the negative finding, the validated tool version, the proportionate conclusion, the scope statement, the timestomp detection. This is the whole reason you wrote the report the way you did in phase 11. The case on the stand is mostly won beforehand, in the discipline of the document. And the cardinal rule governs every answer: state source attribution, disclaim user attribution, and let "the evidence is insufficient to determine that" be a sentence you can say, calmly, without flinching.

Legal Note. The judge is the gatekeeper who admits your testimony only if you are qualified and your method is reliable — under FRE 702 (sharpened in 2023 to demand reliable application and to curb overstatement), the Daubert factors and trilogy, or, in some states, the Frye general-acceptance test. Your deterministic, validated, reproducible methods are what satisfy that gate: hashing is repeatable, carving from a stated offset is repeatable, the timeline is reproducible from the image. The armor you wear in the box is the method you built across this entire book; the discipline that protected the evidence is the same discipline that protects your credibility. The full framework lives in Chapter 25 and Appendix E.

The gravest variant: the same lifecycle under the hardest conditions

The MHA matter is a civil case about money. The point of this short section — kept strictly clinical, as this book is throughout — is that the identical twelve-phase lifecycle governs the gravest assignment a digital examiner can receive: the courtroom anchor case, a child-exploitation prosecution introduced in Chapter 5 and carried through the report and testimony chapters. What changes is not the method but the stakes, the law, and the cost to the examiner.

The method is the same. You scope to the warrant rather than to a corporate engagement; you acquire and verify with hashes and chain of custody exactly as in phase 2; you recover deleted files and carve unallocated space as in phase 4; you read OS artifacts, browser history, and metadata as in phases 5–7; you build the timeline that places access dates as in phase 8; you detect any anti-forensic activity as in phase 9; you correlate, report, and testify as in phases 10–12. The skills transfer wholesale — proof, once more, that technology changes, principles don't.

What differs is governed by Chapter 28. The law is heavier: possession and reproduction of the material are themselves crimes under 18 U.S.C. §2252/§2252A, which is precisely why the hash-set and PhotoDNA identification of phase 7 is not merely convenient but essential — it lets the examiner establish that a recovered file matches a known entry without viewing content, and the report describes only procedure, metadata, and provenance, never content. The contraband contingency you wrote in phase 1 is not hypothetical here; it is the operating procedure. The duty to seek and report exculpatory evidence is at its most consequential, because the same disciplined examination that can support a charge is what protects an innocent person from a wrongful one — you pursue the alternative explanations (automatic download, cached page, malware, synced account) with the same rigor as the inculpatory ones. And the human cost is real and includes you: secondary traumatic stress is a normal response to abnormal input, managed deliberately through technical exposure reduction (hash-matching over viewing), organizational rotation, and personal boundaries — not endured in silence.

Ethics Note. That the gravest case runs the same lifecycle is not a diminishment of its weight; it is a reassurance that the discipline you have practiced on a civil IP matter is exactly the discipline that will carry you through the hardest assignment of your career, on the worst day, with the most at stake for the most vulnerable people. Behind every case file is a real person — a victim, a suspect, a client who lost something irreplaceable. The method serves them. Keep the work clinical, keep the findings honest, keep your exposure managed, and ask for help when the input becomes too much. The technical skills exist to serve human needs; the well-being chapter (Chapter 28) exists because you are one of the humans the work affects.

Common mistakes

• Skipping phases under deadline pressure. The temptation is to leap from acquisition straight to the "interesting" artifacts and skip scope, the anti-forensics pass, correlation, or review. Every skipped phase is a hole an opponent will find. The lifecycle is a sequence; run all of it.
• Analyzing the original, or losing track of which copy is which. Work only on a verified working copy, re-verified each session; the original image is read-only and the original media (if any) stays sealed. The original is sacred — and an examiner who cannot say which copy produced a finding has already lost the chain.
• Letting evidence "live only in your head." A finding you noticed but never wrote down, hashed, and filed did not happen. Every phase produces a saved, hashed artifact in the case-file folder, or it is not done.
• Hash drift across the case file. The acquisition hash in the inventory, the methodology, the findings, and the custody log must be byte-identical. Generate the exhibit hash list mechanically so a typo cannot create a contradiction the defense will exploit.
• Single-source conclusions. A conclusion resting on one artifact is a conclusion waiting to be impeached. Require independent corroboration before a lead becomes a finding, and trust the kernel's clock ($FN`, USN) over the user-settable one (`$SI).
• Confusing the account with the person. The evidence ties activity to the jokafor profile, a device, a session — never to a pair of hands. Write what the artifacts show and let the limitations section state plainly that the operator is not identified by the forensic evidence alone.
• Omitting negative findings. "I searched for malware and found none" is a finding, not a non-event — it strengthens the conclusion of deliberate action and demonstrates impartiality. Silently omitting your disconfirming checks makes the examination look incomplete and surrenders your claim to objectivity.
• Overreaching in the conclusion. "Consistent with copying on 2026-06-11" is defensible; "Okafor stole the data" imports intent and renders a verdict that is not yours. The pressure to deliver a definitive answer is the most dangerous failure in the field; "the evidence is insufficient to determine X" is a complete, professional finding.
• Treating scope as optional. Examining the custodian's personal devices or accounts outside MHA's authority can suppress evidence and create liability. Scope discipline starts on paper in phase 1 and governs every subsequent search.
• Releasing a report no one reviewed. A report no second examiner has checked is an untested product. Build technical and editorial review into your process; a colleague who finds the weak inference saves you from opposing counsel finding it at trial.
• Ignoring the cost to yourself. On heavy cases, examiners who pretend the material does not affect them burn out or break. Use hash-matching over viewing, manage exposure, and treat well-being as part of professional practice, not weakness.

Limitations: knowing when to stop

A capstone investigation, run perfectly, still cannot manufacture certainty the evidence does not contain — and the most professional case file is candid about its own edges (theme #5, know your limitations).

The deepest limit is the gap between what and who. Digital evidence routinely establishes what happened on a system and when — a device was attached, a file was copied, bytes were uploaded — while leaving the human operator and the human intent underdetermined. The MHA case can show, with strong convergent evidence, that the dataset was copied from the jokafor profile to a removable device and that data was uploaded to a personal cloud account; it cannot, from bytes alone, prove which person sat at the keyboard or what they meant to do. The disciplined report says exactly where its reach ends, and "consistent with X but does not exclude Y" is precision, not hedging.

There are limits of access and scope, too. Evidence on the custodian's personal phone or home computer is off this image and behind separate authority; the personal cloud account's server-side contents require legal process directed at the provider (Chapter 31). Strong encryption with no lawful key, a securely wiped region, a physically failed sector — any of these can leave a genuine blank that no technique fills, and the honest finding "acquired, verified, and inaccessible" is the complete result. And there is a limit on the case file's role: it supplies accurate facts, transparent method, supported conclusions, and honest limits — it does not supply the verdict, the argument, or the advocacy, which belong to the court and the attorneys. The most professional sentence in the field remains "the evidence is insufficient to reach a conclusion on this question," and writing it without flinching, when it is true, is not a gap in your skill. It is the skill — the one this whole book has been teaching.

Progressive project: assemble the complete Forensic Case File

This is the milestone every prior chapter has been building toward: assemble the complete, court-admissible Forensic Case File for the MHA matter, end to end. You are not creating new analysis here so much as integrating everything you produced chapter by chapter into one organized, reviewable, defensible deliverable — and grading it as a technical reviewer would.

Step 1 — Assemble the case-file folder. Gather every artifact you produced across the book into a single structured folder. Use this layout (or your lab's equivalent), and confirm each item is present, hashed, and logged:

   MHA-2026-001/                          THE COMPLETE CASE FILE
   ├─ 00-admin/
   │    investigation-plan.md             (Ch.5)  objective + testable Qs
   │    authority-and-scope-memo.md        (Ch.25) legal basis, in/out scope
   │    authority-and-ethics-memo.md       (Ch.28) conflicts, contraband proc.
   │    chain-of-custody.md                (Ch.5/14) unbroken log
   ├─ 01-evidence/
   │    image-verification.txt            (Ch.14) container + bitstream hashes
   │    encryption-assessment.txt          (Ch.29) signatures, key provenance
   ├─ 02-analysis/
   │    filesystem-profile.txt            (Ch.4)  mmls/fsstat
   │    recovered-deleted/  carved/        (Ch.6/7) files + offsets + hashes
   │    windows-artifacts/                 (Ch.16) registry/USB/prefetch/LNK CSV
   │    macos-linux-artifacts/             (Ch.17) if applicable
   │    browser-internet/                  (Ch.18) history/SRUM/sync footprints
   │    email-chat/                        (Ch.19) stores, headers, attachments
   │    media-document-metadata/           (Ch.20) EXIF/Office, hash-set matches
   │    memory/  network/  mobile/  cloud/ (Ch.22/23/24/31) if in this case
   │    anti-forensics-indicators.md       (Ch.30) tells + NEGATIVE findings
   ├─ 03-timeline/
   │    bodyfile  super-timeline.plaso     (Ch.21) hashed intermediates
   │    master-timeline.md                 (Ch.21) UTC, sourced, corroborated
   ├─ 04-report/
   │    report-DRAFT.md   report-FINAL.md  (Ch.26) full anatomy
   │    appendix-c-exhibit-hashes.txt       (Ch.26) generated mechanically
   │    review-memo.md                      (Ch.26) ≥3 things review changed
   ├─ 05-testimony/
   │    qualifications-proffer.md           (Ch.27) CV + qualification narrative
   │    red-team-cross-exam.md              (Ch.27) seven attacks + answers
   │    plain-language-explanations.md      (Ch.27) 3 jury-ready explanations
   │    morning-of-trial-integrity-log.txt  (Ch.27) re-verified hash
   └─ exhibits/                            every file a finding cites

Step 2 — Verify integration, not just presence. A pile of files is not a case file. Confirm the connections hold: every conclusion in the report traces to findings; every finding cites an exhibit with a hash; every hash matches the exhibit hash list; every timeline entry names its source artifact; every load-bearing finding is corroborated by at least two independent sources; and every negative/disconfirming check from your investigation plan is reported. Walk the chain backward from one conclusion to the raw bytes and confirm there are no broken links.

Step 3 — Run the morning-of-trial re-verification. Re-verify the working image against the acquisition hash one last time, record the result, the date, and the exact tool versions, and file it in 05-testimony/. You should be able to testify, truthfully, that the evidence is unaltered as of today.

Step 4 — Self-assess with the rubric. Grade your own case file as an opposing expert would. Score each row 0 (absent), 1 (present but weak), or 2 (defensible); a professional case file scores 2 on every row:

   CAPSTONE SELF-ASSESSMENT RUBRIC                         0 = absent
                                                           1 = weak / present
   CRITERION                                               2 = defensible
   ─────────────────────────────────────────────────────────────────────
   [ ] Authority & scope documented before analysis began
   [ ] Chain of custody unbroken; same hash everywhere it appears
   [ ] Container vs. acquisition (bitstream) hash distinguished & verified
   [ ] Worked only on a verified copy; original protected & re-verified
   [ ] Encryption/triage posture assessed and recorded
   [ ] Deleted files recovered (MFT) + carved (unallocated), with offsets
   [ ] OS-artifact attribution chained (device + user + time)
   [ ] Browser/cloud upload evidence corroborated (TYPED + SRUM + recovered)
   [ ] Timeline UTC-normalized, skew stated, every line sourced
   [ ] Anti-forensics pass run; timestomp detected via $SI/$FN + USN
   [ ] NEGATIVE / disconfirming findings reported (malware, RAT, clock, clears)
   [ ] Conclusions proportionate (no "stole"; no account=person; no verdict)
   [ ] Limitations section honest (who-vs-what; off-image; intent)
   [ ] Report serves three readers via layering; reviewed (technical+editorial)
   [ ] Testimony package complete; cross-exam answers point back to the report
   ─────────────────────────────────────────────────────────────────────
   30/30 = trial-ready.  Any 0 or 1 is a phase to redo before you "rest."

Step 5 — Defend it (the mock trial). If you are working with a class or a study partner, run the mock-trial exercise: one of you plays opposing counsel and cross-examines the other on the finished case file, using the seven attacks and the rubric's weak rows as ammunition. If you are working alone, set the file aside for a day and cross-examine it yourself, in writing, as the opposing expert trying to dismantle it. Every question you cannot answer cleanly is a finding to strengthen, a limitation to state, or a corroboration to add.

Deliverables for this capstone milestone: (1) the complete, integrated case-file folder above; (2) the self-assessment rubric, scored, with a one-line plan to fix any row below 2; (3) the morning-of-trial integrity log; (4) a short reflection naming the single weakest point in your case and how you would shore it up. This is the portfolio piece you show an employer, the proof that you can run a matter end to end — and the demonstration, to yourself, that thirty-eight chapters became a skill.

Summary

The capstone investigation is where technique becomes profession. Across twelve phases you ran one complete case — the Meridian Health Analytics matter — from the assignment that opened it to the cross-examination that closed it, and in doing so you proved that the value of this book was never any single method but the integration of all of them into a repeatable lifecycle: receive the question and scope it on paper (with authority, ethics, and a contraband contingency written in advance); acquire and verify, distinguishing the container hash from the acquisition hash and working only on a re-verified copy while the original stays sacred; triage the live-or-dead and encryption questions before they close; analyze the file system and recover deleted files by MFT remnant and by carving; read the operating-system artifacts that chain a device to a user to a time; follow the data into the browser, the cloud, and the inbox; read the interior metadata of documents and media, using hash-set identification to confirm a file without exposing its content; fuse every dated source into one UTC-normalized, corroborated super-timeline; run a dedicated anti-forensics pass that catches the suspect who covered tracks and, just as importantly, records the negative findings that prove your thoroughness; correlate independent sources into a narrative no single artifact could carry, stated proportionately and tested against alternatives; write the court-admissible report that serves the attorney, the lay reader, and the opposing expert at once through layering; and prepare the testimony that lets you stand behind every word under oath, answering the seven classic attacks by pointing back to a report that already drew the lines. The same lifecycle, you saw, governs the gravest case a person can be assigned — the courtroom anchor — where only the stakes, the law, and the human cost to the examiner change, never the method. And running it perfectly still cannot manufacture certainty the evidence does not hold: digital evidence establishes what and when far more often than who and why, and the most professional finding in the field remains "the evidence is insufficient to reach a conclusion" — said without flinching when it is true. The complete, integrated, self-assessed case file you assembled is the deliverable, the portfolio piece, and the proof that you can do the actual job.

You can now: - Run a complete digital investigation through a repeatable twelve-phase lifecycle — assignment and scope, acquisition and verification, triage, file-system and deleted-file analysis, OS artifacts, browser/email, metadata, timeline, anti-forensics, correlation, reporting, and testimony — adapting the sequence to the case while keeping chain of custody and documentation unbroken underneath. - Sequence and integrate techniques from across the book so that independent evidence sources corroborate one another, and require convergence before a lead becomes a supported finding. - Correlate findings into a coherent, proportionate narrative that states what the evidence supports, tests alternative explanations, reports negative findings, and refuses to confuse a user account with a human operator or your role with the court's. - Assemble a complete, court-admissible Forensic Case File — administrative memos, verified evidence, analysis outputs, a sourced timeline, the report, and the testimony package — in which every conclusion traces through findings to hashed exhibits. - Prepare for and survive cross-examination by red-teaming your own report against the seven classic attacks and answering each by pointing to the discipline already in the document. - Apply the identical lifecycle to the gravest matters clinically and within legal and ethical bounds, and self-assess your work with a reviewer's rubric — knowing when the evidence is sufficient to conclude and when the honest answer is that it is not.

What's next. Chapter 39 — Certifications and Professional Development — turns from doing the work to proving you can: the certifications that signal competence to employers and courts (EnCE, GCFE, GCFA, GNFA, CCE, CFCE, CHFI), how to choose a path for your track, and how to keep your skills current in a field where the technology never stops changing — the credentials that put the case file you just assembled on a résumé.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.