Francesco ZinghinìParty-appointed technical expertise

Forensic imaging: why the hash is not a technical detail

Published on · Author: Francesco Zinghinì

In a technical report the hash appears as a string of sixty-odd characters nobody reads. It is in fact the only element that answers the simplest and most dangerous question in cross-examination: how can you rule out that the material was modified?

The problem the hash solves

Alter a paper document and it usually shows. A file does not: it can be modified without visible trace, and the modified copy is indistinguishable from the original to the naked eye. If an expert examines a disk for three weeks and then files their conclusions, how is it shown that the content they worked on was the content seized, and not something that changed in the meantime?

The answer cannot be the expert's word. It has to be a fact anyone can verify, including someone with an interest in contradicting it. That is exactly what the hash provides.

What it is, concretely

A hash function takes a sequence of bytes of any length — a file, an entire disk — and returns a fixed-length value, written as a string of hexadecimal characters. Three properties make it useful in evidence:

  • It is deterministic. The same input always produces the same value, on any machine and at any time. That is what makes verification repeatable by another expert.
  • It is extremely sensitive. Change one bit on a two-terabyte disk and the resulting value changes unpredictably. There is no «small» change producing a «similar» value.
  • It is not invertible. The content cannot be derived from the value. Publishing the hash of a seized disk in a record reveals nothing about what the disk contained.

On these properties the whole evidential architecture of forensic imaging rests: the value is computed at acquisition, written into the record, and from then on anyone can recompute and compare it. If it matches, the material is the material. If it does not, something happened — and that too is information.

Which function to use, and why MD5 is not enough

Hash functions are not all equivalent, and the difference has become procedurally relevant.

The property that counts is collision resistance: the difficulty of constructing two different contents producing the same value. If constructing a collision is practicable, the hash stops proving the identity of the content, because it becomes theoretically possible to substitute other material yielding the same result.

FunctionLengthStatusForensic use
MD5128 bitsCollisions practically constructible, for years Only as an additional value, never alone
SHA-1160 bitsCollisions concretely demonstrated Only as an additional value, never alone
SHA-256 and the SHA-2 family256 bits and aboveNo known practical attack Current reference
SHA-3variableNo known practical attack Alternative, different construction from SHA-2

In practice two values are computed and recorded: one from the SHA-2 family, on which the assertion rests, and a historical one such as MD5, for continuity with pre-existing tools and documentation. Finding only MD5 in a record does not automatically render an acquisition unreliable, but it is a point a technical challenge can work on, and it is better known in advance than met in the hearing.

For completeness: constructing a collision requires choosing both contents. It does not allow a file to be fabricated that collides with an already existing, unmodifiable document. It is a real attack but not an omnipotent one, and a challenge presenting it as such would be as improper as ignoring it.

The bit-for-bit copy

Computing a hash is of little use if what it is computed over is a partial copy. A forensic copy of a medium is not a copy of the files: it is the complete reproduction of the medium, sector by sector, including unallocated space — what the system considers free and where deleted but not yet overwritten content survives. That is very often where what matters is found.

Reading is done through a write blocker, hardware or software, that physically prevents the system from modifying the original. Without one, simply attaching the medium to a computer is enough for something to be written to it, and from that moment the hash of the original no longer matches what the original was.

Where the medium is damaged the rule changes: the priority becomes saving what is still readable, and the partial nature of the result must be documented sector by sector. A record that stays silent about unreadable areas is worse than one that declares them.

The chain of custody

The hash proves a content did not change between two moments. The chain of custody proves who had that content in between. They are different guarantees and both are needed.

Concretely it is a sequence of records stating, for each handover, date and time, place, persons present and their capacity, description and identifiers of the material (make, model, serial number), the state of the seals, hash values computed on delivery and recomputed on opening, and the signatures of those handing over and receiving.

Every handover is a link. If one is missing — an interval during which the whereabouts of the material are undocumented — the whole chain is open to attack, and it is not necessary to show that tampering occurred: it is enough that it cannot be excluded.

The statutory basis

Procedurally the reference is Italian law 48 of 2008, which ratified the Budapest Convention on Cybercrime and amended several provisions of the Code of Criminal Procedure on inspections, searches and seizures of computer data, introducing the principle that operations must adopt technical measures directed at preserving the original data and preventing its alteration.

It is the basis on which objections to acquisitions conducted without precautions are built. Technically, the international reference is ISO/IEC 27037, which describes the identification, collection, acquisition and preservation of digital evidence and distinguishes the role of those who collect from those who examine.

The mistakes I see most often

  • Switching the device on «for a quick look». Booting modifies dozens of system files. From that moment the hash of the original will never again be what it was.
  • Copying the files instead of the medium. Unallocated space is lost — often precisely what was needed.
  • Computing the hash after the analysis rather than before. A value computed at the end proves nothing about what was there at the start.
  • Not recomputing the hash at the end. The closing comparison is what shows that nothing changed during examination.
  • Records without serial numbers. If the medium is not uniquely identified, the chain of custody links nothing to anything.

Forensic acquisition: how I can help → · Back to insights

Do you have a matter under way?

Tell me what happened and what you need to prove. In a first reply I will tell you whether there is a technical route, what data is needed and how long it takes — before any commitment.

Request an assessment