Case Study 2 — The Hash That Wouldn't Hold Still

A procurement manager is suspected of steering contracts to a kickback shell company, and the proof lives on his NVMe-equipped laptop. Then the unthinkable on a forensic exhibit happens: the verification image hashes differently from the acquisition image — and no one touched the drive. This is the same flash physics as Case 1, seen from the witness stand, where the question is not "did I get the data back?" but "can I prove this is what was on the drive?"

Background

A mid-size construction firm's audit flagged a pattern: a procurement manager had repeatedly selected a single subcontractor whose invoices ran 15–20% above market, and that subcontractor turned out to share a registered address with an LLC the manager's spouse controlled. The firm placed a litigation hold and engaged an outside examiner. The central exhibit was the manager's company laptop — a Dell with a 512 GB NVMe SSD, modern, TRIM enabled, and (the examiner confirmed early) Deterministic-Read-Zero-After-TRIM.

The trouble started before the examiner arrived. Corporate IT had "secured" the laptop the way well-meaning IT usually does: they powered it on, browsed a few folders to "confirm there was something there," then left it sitting powered and plugged in on a locked-office desk overnight until the examiner could collect it the next morning. They had also, the examiner learned, very nearly mounted the manager's external backup SSD read/write on a technician's Windows box "to peek" before someone stopped them. No one had written a single file to the laptop on purpose. And yet, by the time the examiner took custody, the drive had spent roughly sixteen hours powered and idle — sixteen hours during which an NVMe controller does exactly what NVMe controllers do when powered and unbothered: garbage collection and static wear leveling, quietly rearranging stale and unallocated regions with no host involvement at all.

The investigation

The examiner acquired the laptop properly: drive removed, connected through a hardware write blocker, imaged with ewfacquire to an E01 container, dual-hashed at acquisition. She recorded the medium as solid-state in her notes from the first line, with its determinism flag, precisely because she knew what was coming.

   Acquisition — EVID-2026-0731-02.E01  (512,110,190,592 bytes)
   Media: NVMe SSD, RZAT, TRIM enabled (host DisableDeleteNotify = 0)
   Powered-on (by IT, est.):  2026-07-30 ~17:40
   Custody to examiner:       2026-07-31 09:05
   Acquisition complete:      2026-07-31 10:22
   Whole-image  SHA-256: a17c9d...4e02     MD5: 5fb2...c1

Eleven days later, preparing for analysis review, she re-imaged the same drive — same write blocker, same tool — as a verification pass. The whole-image hash came back different:

   Verification image (day 11):  SHA-256 c8840a...91bd   (!= a17c9d...4e02)
   Block-level diff vs. acquisition:
     allocated / file-resident regions : IDENTICAL
     unallocated + stale regions       : 0.31% of blocks changed

On a hard drive this would be an alarm: a different hash means something altered the evidence. On an SSD it is the expected, documented behavior of the medium — autonomous GC and wear leveling drifting the unallocated space while the file-resident data stood still. The block-level diff proved exactly that: every region the file system actually referenced was byte-for-byte identical across both images; only 0.31% of blocks, all in unallocated and stale areas, had moved. The examiner had anticipated this and had hashed the file-resident evidence separately at acquisition, so each key document carried its own stable hash that matched in both images.

The case itself came together from data that was present and provably accessed, not from anything TRIM might have erased. The falsified bid-comparison spreadsheets sat in the manager's Documents folder; their $FILE_NAME` MFT timestamps (which the user-facing timestomping tools do not touch) contradicted the `$STANDARD_INFORMATION timestamps he had altered to make the documents look older than the bids they supposedly predated — the timestomping was its own tell (timeline mechanics in Chapter 21). The USBSTOR registry keys recorded his personal external SSD connecting on the evenings the inflated bids were finalized (Windows USB-device-history artifacts, Chapter 16). Browser history showed uploads to a personal cloud account. And the residue of a "PC cleaner" he had run the week before resigning — its own Prefetch and AmCache entries — proved an attempt to wipe activity after the fact, the anti-forensic tool betraying itself (Chapter 30).

Some deleted material in unallocated space was simply gone. The examiner did not speculate about it. Her report carried a finding in plain language: the device is an RZAT SSD on which deleted data, once trimmed, is unrecoverable; the absence of recovered deleted files therefore neither proves nor disproves that such files once existed, and the conclusions rest solely on the file-resident evidence described above.

At deposition, opposing counsel went straight for the hash. "Your own two images of this drive do not match. By your own science, the evidence changed in your custody. Why should the court trust any of it?" The examiner had been waiting for the question for eleven days. Solid-state drives, she explained, perform garbage collection and wear leveling autonomously whenever powered — a property of the technology documented since Bell and Boddington's 2010 paper, Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery? — which can alter unallocated space with no host involvement. That is why the whole-image hashes differ. It is not tampering, and her block-level diff proved the change was confined to unallocated regions: every file she relied on hashed identically in both images. She had acquired through a write blocker (no host writes possible), minimized powered time, hashed the file-resident evidence separately, and disclosed all of it in the report before anyone asked.

The motion to exclude failed. It failed because the examiner had explained the medium's behavior before the cross-examiner could frame it as concealment — and because she had built the case on what the evidence could prove, not on what TRIM had taken away.

The analysis

  1. A sloppy seizure is a flash problem, not just a procedure problem. Sixteen hours of powered-idle time let the controller drift the unallocated space before the examiner ever touched the drive. On an HDD that overnight wait would have been harmless; on an SSD it manufactured the very hash discrepancy the defense later seized on. Powered time is now a custody fact — record it, and minimize it.

  2. Per-file hashing is the answer to whole-image drift. Because GC alters unallocated regions but not file-resident data, hashing the actual evidentiary files separately gives you a stable, provable integrity argument that survives even when the full-drive hash does not. Doing this at acquisition, not in hindsight, is what made the testimony bulletproof.

  3. Explain the mismatch before the cross-examiner does. The same fact — a hash mismatch on an SSD — makes an examiner credible if she raises and explains it, and incompetent (or worse) if she is surprised by it on the stand or appears to have hidden it. The disclosure belonged in the report from the moment the medium was identified as solid-state.

  4. Build on what is present and provable; never speculate about what TRIM erased. The case rested on file-resident documents, MFT $FILE_NAME timestamps, USB and registry artifacts, and browser history — all things that were there. The honest "deleted data is unrecoverable, and its absence proves nothing" finding cost nothing and removed an attack surface, because over-claiming about TRIM-erased data is how an examiner loses a case the honest evidence would have won.

  5. Contrast with Case 1 reveals the dividing line. Same physics, opposite questions. Case 1 asked "can I get the bytes back?" and the answer was diagnosis and yield. This case asked "can I prove these bytes are unaltered?" — and on an SSD that is the harder question, answered not by a tool but by discipline: minimal powered time, write-blocking, separate file-resident hashes, and a report that names the medium's behavior out loud.

Discussion questions

  1. IT left the laptop powered and idle overnight before the examiner arrived. Explain, to a non-technical attorney, why that was harmful on this drive when the same overnight wait would have changed nothing on a hard drive — and what specifically changed in those sixteen hours.

  2. The whole-image hashes differed but the file-resident data was identical. Walk through why that pattern is the signature of a properly handled SSD rather than tampering, and name the single piece of analysis (produced at acquisition) that let the examiner prove it.

  3. The examiner's report stated that deleted data was unrecoverable and that its absence "proves nothing." Why include that at all? What attack does it remove, and how does it connect to the principle that you say only what the evidence proves?

  4. ⭐ Suppose the decisive evidence had been a document the manager deleted shortly before seizure, and TRIM had erased it — so the only trace was a fragment in a stale region that the day-11 verification image no longer contained, having been garbage-collected away. How would you handle the fact that your first image captured the fragment but your second did not? Address whether the first image is still reliable evidence, what your notes and testimony must establish about chain of custody and powered time, and how you would answer a defense claim that "the examiner's own re-image proves the data was unstable and therefore untrustworthy."

  5. Both case studies in this chapter involved an SSD that, in another configuration, would have been the hopeless RZAT case. Identify two points where the correct action diverged because Case 1 was a recovery job and this was a forensic one — and one principle (state it precisely) that was identical in both.