The verification hash of a failing server disk does not match the acquisition hash — how do you diagnose it before conceding anything?

## Step one: which comparison actually failed Three different checks get casually called "the verification", and they fail for entirely different reasons: 1. **Image file versus the digest recorded at acquisition.** Tests your evidence store, your transfer, and your handling. If this fails, the drive is irrelevant — something happened to your copy. 2. **A fresh read of the source device versus the acquisition digest.** Tests whether the physical drive still returns the same bit stream. This is the one that fails on dying media, and its failure says nothing about your handling. 3. **A working copy versus the master image.** Tests one duplication event. Say which one you ran before you say anything else. An examiner who reports "the hashes did not match" without naming the comparison has already muddled the finding. ## Step two: read the acquisition log, not just the digests A competent acquisition process records the ranges it could not read, how many sectors were affected, and what it substituted for them. On a decade-old server disk that log is the diagnosis. If the first pass logged three unreadable ranges and the verification pass logged four, the two passes did not read the same data — not because anyone edited anything, but because the drive answered differently. Read errors on failing media are not deterministic: the drive retries internally, sometimes succeeds, sometimes reallocates, and the sectors that fail migrate between passes. Whatever fill pattern the tool substitutes for an unreadable sector then differs between the two bit streams, and a whole-device digest, which is exquisitely sensitive to a single bit, cannot match. ## Step three: localise the difference Assertion is worthless here; you need the differing regions on the table. Compare the two passes in blocks — per-segment digests, or digests over defined sector ranges — so you can point to exactly which regions differ. Then make two demonstrations: - **Every differing region falls inside a range the acquisition log recorded as unreadable.** That is a coherent, mechanical explanation with a contemporaneous record behind it. - **The regions carrying the finding are not among them.** Hash the miner binary itself, the registry hive containing the service registration, the event-log file — and show each one identical in both passes and outside every error range. This is why artefact-level digests matter and not only a whole-image number. ## Step four: rule out the two other benign causes - **The source was still running.** If the disk was read from a live system, its contents changed underneath you — the page file, the journal, log files, timestamps. A source re-read will never match, and never could have; that is a property of capturing from a running machine, not evidence of interference. Establish which it was. - **The copy, not the source, drifted.** If comparison (1) failed, look at the evidence store: media faults, an interrupted transfer, a copy taken while the file was still being written. Recompute from the original write, check the store's own error records. ## Step five: what would actually indicate interference The honest examiner keeps this on the list. Differences that sit **outside** every logged error range, in structured regions, altering content that matters to the case — a shortened event log, a changed binary — are not explained by a dying drive and need a different explanation. So do differences in an image whose source is intact and whose store reports no faults. Say plainly what you checked and what would have changed your conclusion. ## Step six: scope the claim, do not defend the whole The wrong instincts are to declare the image invalid, or to insist nothing is wrong because "only bad sectors" differ. The defensible position is narrower and stronger: this image is not bit-verifiable end to end against a drive that is physically failing, and here is the sector-level account of why; these specific artefacts are verifiable, hash identically across both passes, and the finding rests on them; these other observations touched regions I cannot re-read reliably, and I withdraw them. Withdrawing the unsupportable part is what makes the rest credible. Do not re-acquire repeatedly hoping for two matching passes. Each pass stresses a failing drive further and risks losing what you still have; if a second acquisition is warranted at all, it is to capture more of the readable surface, not to manufacture agreement. ## The presentation point A mismatch you documented at capture, explained mechanically, and volunteered before you were asked is a technical fact about old hardware. The same mismatch discovered by someone else in your material is a credibility event. Put the error log in the finding.