Case Study 1 — The Conflict Worth Stopping For

An examiner in a corporate IP-theft matter was one keystroke from signing a report when a second tool disagreed with the first about a single timestamp. The disagreement looked like a nuisance. It was the most valuable thing that happened in the whole examination — because the tool that was "wrong" was the one she had been about to trust. This is dual-tool verification doing exactly the job the chapter promises: catching the bug before the bug catches you on the stand.

Background

A mid-sized manufacturer, Northwind Components, suspected that a departing process engineer had copied a proprietary tooling dataset to a personal USB drive on his last night before resigning — the archetype this book calls anchor case #2, the employee who covered their tracks. The matter was civil, the laptop was company-owned with signed consent on file, and litigation was likely, so this was forensics, not casual recovery: the drive had been imaged behind a write-blocker to departure-ws.E01, the acquisition hash was logged, and all analysis ran on a verified working copy.

The examiner's lab ran the deliberate "both" posture the chapter recommends — a commercial platform for primary processing and the open-source stack kept sharp as the independent second tool. For Windows artifacts she used the Eric Zimmerman suite and, for registry work specifically, two independently written tools: Registry Explorer (which replays .LOG1/.LOG2 transaction logs) and RegRipper (Harlan Carvey's plugin-driven parser). The triage collection had been captured with KAPE, which grabs each hive together with its transaction logs.

The load-bearing question was narrow and contestable: was a specific removable device connected, and when? A USB connection at the right hour, correlated with a shortcut pointing at the removable drive, would establish the opportunity to copy the dataset. Everything else in the report would hang from that one fact.

The investigation

The device itself was not in dispute. Both tools read SYSTEM\CurrentControlSet\Enum\USBSTOR and reported the same hardware — a Kingston DataTraveler, serial 0019E06B... — with the same volume label history. The time was the problem.

   USB FIRST-CONNECTION TIME  -- the load-bearing fact
   ---------------------------------------------------------------------
   Registry Explorer  (replays .LOG1/.LOG2)
       Kingston DataTraveler  serial 0019E06B...
       FirstConnect  2025-03-18 19:24:51 UTC
   RegRipper  usbstor.pl  (raw hive only)
       Kingston DataTraveler  serial 0019E06B...
       FirstConnect  (no value)                         <-- CONFLICT
   ---------------------------------------------------------------------

One tool placed the first connection at 7:24 p.m. on the engineer's last night. The other reported no first-connection timestamp for that device at all. Two competent, widely used registry tools, pointed at the same hive, did not agree.

The tempting move — the move that loses cases — was to pick the answer she liked. Registry Explorer's 19:24:51 fit the theory beautifully; it would have been easy to write it down and move on. Instead she applied the chapter's non-negotiable rule: a conflict is not a nuisance; it is information. She stopped and ran it to ground.

The first hypothesis was the obvious one from the chapter's "feed the tool everything it needs" mistake: a dirty hive. The device had been connected on the very last night, so the registry write recording its first-connection property ({83da6326-...}\0064) was recent — recent enough that it might still live in the SYSTEM.LOG1 transaction log rather than in the base hive itself. Registry Explorer replays those logs before showing values; RegRipper, by design, reads the raw hive and does not. If the base hive was dirty, Registry Explorer would show the true, log-merged value and RegRipper would show the stale, pre-merge state — which, for a brand-new device, is nothing.

She tested it the way a lab validates anything: against ground truth she could inspect.

   RESOLVING THE CONFLICT
   ---------------------------------------------------------------------
   1. Confirm the hive is dirty:
        Registry Explorer ▸ hive header  ▸  Primary sequence != Secondary
        -> dirty; pending changes in SYSTEM.LOG1/.LOG2
   2. Confirm the .LOG files were actually in the KAPE collection:  yes
   3. Replay logs into a merged copy, then re-run BOTH tools:
        Registry Explorer (merged)  FirstConnect 2025-03-18 19:24:51 UTC
        RegRipper       (merged)    FirstConnect 2025-03-18 19:24:51 UTC  <-- AGREE
   4. Corroborate from an independent artifact class:
        LECmd  LNK  ->  E:\tooling_dataset_v7.7z   target accessed 19:31 UTC
        EvtxECmd  Event 6416 (PnP device added)     2025-03-18 19:24:50 UTC
   ---------------------------------------------------------------------

The conflict resolved cleanly and accurately. The hive was dirty; the logs were present; once they were replayed, both registry tools — written by different authors, in different languages, with no shared lineage — reported the identical first-connection time, 19:24:51 UTC. And two entirely separate artifact classes agreed within seconds: a Windows PnP event-log entry at 19:24:50 and a LNK shortcut showing the dataset archive opened from drive E: at 19:31. The 7:24 p.m. connection was now robust, reproducible, and anchored four independent ways.

Had she trusted RegRipper's raw-hive reading, she would have reported no first-connection time and possibly concluded the device was never mounted — exonerating the wrong way. Had she trusted Registry Explorer without resolving the conflict, she would have been right by luck, with a finding she could not explain when a defense expert ran RegRipper and got "no value." Either way, the unresolved conflict was a landmine in a signed report. Stopping defused it.

The analysis

  1. A conflict is information, not a nuisance. The disagreement was the single most useful event in the examination. It pointed straight at a real property of the evidence — a dirty hive — that the examiner needed to understand to report any registry timestamp defensibly. Dual-tool verification earns its keep precisely on the cases where the tools disagree.

  2. Knowing how your tools work is what lets you resolve the conflict. The disagreement was explicable only because she knew that Registry Explorer replays transaction logs and RegRipper does not. An examiner who treats both as black boxes sees an unresolvable contradiction; an examiner who understands the artifact sees a diagnosis. The tool does not testify; you do — and you can only testify to what you understand.

  3. "Feed the tool everything it needs" is half of correctness. The base hive alone told a stale story; the truth lived in the .LOG1/.LOG2 files. Because the collection captured the hive with its logs, the truth was recoverable. A triage that grabbed SYSTEM and skipped its logs would have made the stale answer the only answer — confidently wrong.

  4. Corroborating across artifact classes turns a resolved conflict into an unshakable fact. The first-connection time did not rest on the registry alone. A PnP event-log entry and a LNK shortcut, parsed by different tools, placed the same device on the same drive in the same minute. When four independent sources converge, "the software told me" is no longer anywhere in the chain of reasoning.

  5. The win was built before the report, not during the cross-examination. The methodology memo recorded both registry tools and their versions, noted the dirty-hive resolution and the log replay, and logged the cross-corroborating artifacts. That memo pre-answered the questions Chapter 27 — Expert Testimony trains you to expect, and it spoke directly to the Daubert factors Chapter 25 owns: tested method, known behavior, documented, reproducible.

Discussion questions

  1. The examiner was "right by luck" if she trusted Registry Explorer's value without investigating. Explain why being right by luck is still a professional failure here — what specifically would have collapsed when a defense expert ran RegRipper and got "no value"?

  2. Reconstruct the diagnosis from the tools' design. Why does the fact that Registry Explorer replays transaction logs and RegRipper does not predict exactly this conflict on a device first connected on the last night before imaging? Which tool's answer is correct, and why?

  3. The KAPE collection captured each hive with its .LOG1/.LOG2 files. Walk through how this case would have ended if the triage had grabbed SYSTEM alone. Which finding disappears, and why is "garbage in" so dangerous when it produces a confident, tidy, wrong answer?

  4. The lab deliberately paired a commercial primary platform with open-source second tools, doubling some training cost. Using this case, argue whether that redundancy paid for itself — and identify the moment a single-tool registry workflow would have shipped a wrong conclusion.

  5. ⭐ Contrast this examination with the chapter's War Story, in which an examiner reported "no evidence of data exfiltration" after trusting a single commercial suite whose version had a LNK-parsing bug. Both cases turn on one tool being silently wrong about a load-bearing artifact. Identify the one practice that separates this success from that failure, and argue why "dual-tool verification is not bureaucratic ritual" using the specific evidence of these two outcomes. Then state, in your own words, the rule both cases prove about load-bearing findings.