What does the hash you record when imaging a suspect disk actually prove?
answer
- a copy claim, not a provenance claim
- integrity runs forward from capture
- equal digests mean no drift since
- says nothing about who wrote it
- authenticity comes from other artefacts
basics
~20 sIt proves the image is a bit-for-bit copy of what the drive returned at capture, and has not drifted since. It says nothing about who wrote the data, when, or what happened before you arrived.
solid answer
~50 sThe digest is computed over the bit stream read from the source device at capture, so it anchors one narrow claim: the bits I am showing you are the bits that came off that drive at that moment, unchanged since. Integrity runs *forward* from the timestamp of the first hash and cannot reach backwards. On a server where someone installed a cryptominer, the hash does not show the miner binary predates my arrival, does not identify who planted it, and does not certify the disk is otherwise untouched — the intruder's own changes are part of what I copied. Those claims come from elsewhere: filesystem timestamps, the Windows event records for the service and scheduled task that launched it, process telemetry, and corroboration between them. Confusing "the copy is faithful" with "the content is genuine" is the classic inversion.
go deeper
Be ready to state in one sentence what an evidence image's hash proves: the copy matches what the drive returned at capture. Do not stretch that into any claim about who put the data there.
Explain the mechanics: the digest covers the whole bit stream including unallocated space, and equality only demonstrates the absence of drift since the first digest was recorded.
Show how you build the claims a hash cannot make — filesystem timestamps, service-creation events, execution telemetry — and how you argue from several artefacts converging rather than one.
Own the standard your team works to: which digests get recorded, which artefacts carry their own file-level hash, and how the lab answers a challenger who suggests the responder planted what was found.
## What is actually being hashed A cryptographic hash function takes an input of any length and returns a fixed-length digest; changing a single bit of input changes the digest unrecognisably, and you cannot practically construct a different input that produces a chosen digest. During acquisition the digest is computed over the **bit stream read from the source device** — every sector the drive returned, not just the files. That includes unallocated space, slack, and any deleted-but-not-overwritten remnants of the intruder's staging directory. If the acquisition covered a physical drive rather than one volume, it also covers partition structures and anything hiding between partitions. The number is written down at the moment of capture. Later, anyone can recompute it and compare. ## The claim a matching digest supports Exactly one: *the data being examined now is bit-identical to the data read from that device at the recorded time.* This is an **integrity** claim, and it has a direction — it runs forward from the instant the first digest was computed. Everything before that instant is outside its reach. That single claim is worth a great deal. It means an examiner months later, or the other side's expert, can be handed the same image and satisfy themselves that nobody has quietly edited the copy in the interim. It moves the argument off the bits and onto interpretation, which is where the argument belongs. ## The claims it does not support, and this is what interviews probe - **Provenance.** The hash says nothing about *who* wrote the cryptominer to the file server, or from where. - **Time.** It is not a timestamp for the content. It timestamps only your act of copying. - **Retroactive integrity.** If someone modified the disk an hour before you attached it, the modification is faithfully preserved in your image and the hash verifies perfectly. A verifying hash is entirely compatible with a thoroughly tampered-with disk. - **Cleanliness.** "The hash matched" does not mean "the system was unaltered". The intruder's edits are precisely what you came to copy. - **Completeness.** Sectors the drive refused to return are not in the copy as they existed; a well-behaved acquisition process substitutes a defined fill pattern and logs the failed ranges. The digest covers what was read, including those substitutions. - **Admissibility or sound handling.** A number proves nothing about how the drive was treated before and after. ## Where the other claims come from If the finding is "a cryptominer ran on this file server for six weeks", the hash is the least of the evidence. The load-bearing artefacts are the binary's creation and modification timestamps, the registry and event-log records showing a service or scheduled task being created, execution telemetry from the endpoint agent, and network records showing sustained outbound sessions to a mining pool — remembering that a flow record proves bytes moved and never what they contained. Each of those is individually forgeable; the argument is built on several independent artefacts converging on the same story. The hash's job is only to guarantee that all of them are being read from an unmodified copy. ## Practical habits that make the hash more useful - **Hash the artefacts, not only the image.** Recording the digest of the miner binary itself lets a third party verify that one object, compare it against threat-intelligence records of the same sample, and cite it without touching the whole image. - **Record the digest at the moment of capture, not later.** A digest computed after the drive has been on an analyst's bench for a day is a baseline for a period nobody cares about. - **Say which algorithm.** Many labs record both a legacy and a modern digest. Published collision work on older algorithms concerns *crafting two files that collide*, not altering a stored copy so it matches a digest recorded earlier — but recording a modern digest removes the argument from the table entirely, which is cheaper than winning it. ## The sentence to have ready "The hash proves the copy is faithful to what the device gave me at capture. It does not prove the content is genuine, and I have never claimed it does — that comes from these other artefacts." Candidates who cannot separate those two ideas will over-claim under pressure, and over-claiming is how an otherwise sound finding gets thrown out.
- If the hash cannot show when the cryptominer binary reached the server, what can?Filesystem creation and modification timestamps on the binary, the event records for the service or scheduled task that launched it, endpoint telemetry showing it executing, and network records of sustained sessions to a mining pool. Each is individually forgeable, so the argument rests on several independent artefacts agreeing on the same window rather than on one.
- Does a matching hash prove the disk was not tampered with before acquisition?No, and this is the most common inversion. If someone altered the disk an hour before you attached it, your image faithfully preserves the altered state and verifies perfectly. The hash certifies your copy, not the history of the original.
- What does hashing individual files inside the image add over hashing the whole image?It lets you cite one artefact by its own digest. A third party can verify that specific binary without handling the entire image, you can match it against known-sample records, and if part of the image later becomes unverifiable the artefact-level digest can still stand on its own.
It is the tamper seal applied to a box at the loading dock. An intact seal proves nothing was swapped in transit; it says nothing about what was put in the box before the seal went on.
saying these in an interview costs you the question
- Says the hash proves the file was never tampered with
- Claims a matching digest authenticates who created the data
- Treats the hash as a timestamp for the content
- Confuses a faithful copy with genuine content
- Assumes a verifying image means the host was clean