Når hashværdien ikke stemmer: årsager og håndtering

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

En hashværdi, der ikke stemmer, betyder kun én ting med sikkerhed: De to datamængder, der er hashet, er ikke bitidentiske. Det betyder ikke automatisk, at nogen har ændret beviset. Langt de fleste afvigelser skyldes, at man sammenligner to forskellige ting, at kilden har ændret sig undervejs, eller at læsningen har fejlet. Opgaven er at finde årsagen, før der drages konklusioner, og at dokumentere afvigelsen åbent.

Grundbegrebet er forklaret i Hashværdier forklaret, og forskellen på algoritmerne i Hashalgoritmer i forensic. Her handler det om fejlsøgning. Ved mobiludtræk og cloud-eksporter er en ny hashværdi normal; det er forklaret i Hash ved mobiludtræk og cloud.

To slags hashværdier, der let forveksles

Ved en diskkopi beregnes typisk to værdier:

Kildehash (acquisition hash): beregnet af sikringsværktøjet, mens data blev læst fra kilden.
Verifikationshash: beregnet bagefter ved at læse den færdige kopi igen.

Stemmer de to, er kopien skrevet korrekt. Stemmer de ikke, er der sket noget mellem læsning og skrivning, eller kopien er ændret efterfølgende. En tredje værdi opstår, hvis originalen hashes igen senere. Den sammenligning siger noget om originalen, ikke om kopien, og den kan sagtens afvige uden at kopien er forkert.

De typiske årsager

Man sammenligner ikke det samme

Den hyppigste årsag er, at de to værdier dækker forskellige data:

Hash af en E01-fil eller en segmentfil sammenlignet med hash af de data, filen indeholder. E01 komprimerer og tilføjer metadata, så filens egen hash er en helt anden. Se Forensiske diskformater.
Hash af hele disken sammenlignet med hash af én partition.
Hash af en zip-fil med en eksport sammenlignet med hash af eksporten pakket ud.
En disk med skjulte områder (HPA eller DCO), som det ene værktøj læser og det andet ikke gør.
Forskellig algoritme, hvor værdierne tilfældigvis har en længde, der ligner hinanden.

Kilden ændrede sig under sikringen

Et levende system ændrer sig hele tiden. Hashes en kørende server, et monteret netværksdrev eller en tændt computer, får man en værdi, der ikke kan gentages, fordi logfiler, swap og tidsstempler skrives under læsningen. Det samme gælder en disk, der er monteret skrivbart, eller hvor styresystemet har skrevet til journalen ved tilslutning, fordi der ikke blev brugt skrivebeskyttelse. I de situationer er det kopien og dens egen hashværdi, der er referencen. Forskellen er forklaret i Live response.

Læsefejl

En disk med dårlige sektorer kan give forskellige resultater ved hver læsning. Mange værktøjer fylder ulæselige sektorer med nuller og fortsætter. Læses disken igen, kan en sektor, der fejlede første gang, lykkes anden gang, og så er hashværdien en anden. Værktøjets log over læsefejl er afgørende her. Se Defekte og fejlende diske.

Ustabile USB-kabler, overophedede adaptere og fejl i kopimediet kan give samme billede. En verifikationsfejl uden registrerede læsefejl peger oftere på skrivefejl eller et defekt destinationsmedie.

Værktøj og indstillinger

Forskellige værktøjer kan behandle samme kilde forskelligt: hvordan sidste ufuldstændige blok håndteres, om skjulte områder medtages, og hvordan fejl udfyldes. Selv to versioner af samme værktøj kan afvige. Ved logiske kopier kan alternative datastrømme, udvidede attributter og tomme mapper være med i det ene værktøj og ikke i det andet. Afprøvningen af værktøjer er beskrevet i Verifikation af forensiske værktøjer.

Ændring efter sikringen

Først når de ovenstående forklaringer er udelukket, er det relevant at overveje, om kopien er ændret efter sikringen, utilsigtet eller bevidst. Det kan skyldes en arbejdskopi, der ved en fejl blev monteret skrivbart, eller et lagersystem med fejl. Kæden af ansvar og logning af adgang til kopien er det, der kan afklare spørgsmålet.

Fejlsøgning i praksis

Gå systematisk frem og dokumentér hvert trin:

Bekræft, hvad hver værdi dækker: algoritme, objekt (disk, partition, fil, beholder), værktøj, version og tidspunkt.
Gennemgå sikringsloggen for læsefejl, afbrydelser, antal læste sektorer og diskens størrelse.
Sammenlign størrelser: Har kilde og kopi samme antal sektorer? En forskel peger på skjulte områder eller afkortning.
Genberegn med et andet værktøj på kopien for at udelukke en fejl i beregningen, fx med styresystemets egne kommandoer; se Hash af en fil.
Brug delhashværdier, hvis de findes. Mange formater gemmer hashværdier pr. blok eller segment, så man kan finde det område, der afviger.
Undersøg, om kilden var levende eller monteret uden skrivebeskyttelse.
Konklusion og handling: Kan kilden stadig læses, tages en ny kopi. Kan den ikke, beskrives afvigelsen og dens betydning.

Rør aldrig ved masterkopien under fejlsøgningen. Arbejd på en ny kopi af kopien, og hash den før og efter.

Hvornår betyder afvigelsen noget for sagen?

En afvigelse på grund af ulæselige sektorer betyder, at nogle få områder mangler eller er udfyldt med nuller. Det kan betyde noget, hvis netop de områder indeholder relevante data, men resten af kopien er stadig pålidelig. Bloklevel-hashværdier kan vise, at de afgørende filer ligger i områder, der stemmer.

En afvigelse mellem sikringshash og en senere kontrol af selve kopien er alvorligere, fordi den rammer kæden af ansvar. Her skal årsagen findes, og findes den ikke, må analysens resultater vurderes med det forbehold.

Forebyggelse

De fleste afvigelser kan undgås eller i det mindste forklares på forhånd:

Brug skrivebeskyttelse ved enhver tilslutning af et originalmedie, også når det kun skal identificeres.
Notér diskens størrelse og antal sektorer før sikringen, og sammenlign med det antal, værktøjet rapporterer.
Kontrollér kopien med det samme, mens kilden stadig er til rådighed, så en ny sikring kan tages, hvis verifikationen fejler.
Beregn to algoritmer samtidig, så en beregningsfejl i den ene kan opdages.
Gem værktøjets log sammen med kopien og hash den også.
Kontrollér destinationsmediet før brug, og undgå at skrive kopier til medier med kendte fejl.

Ved logiske kopier og eksporter bør hver fil hashes for sig ud over den samlede beholder. Viser kontrollen senere en afvigelse i beholderen, kan filhashværdierne vise, om indholdet stadig er intakt, og hvilke filer der eventuelt er berørt.

Hvad en afvigende hashværdi kan og ikke kan bevise

Den viser, at to datamængder ikke er bitidentiske. Den viser ikke, hvor forskellen ligger, hvor stor den er, eller hvem der har forårsaget den. Én ændret byte giver en helt ny værdi. En afvigelse er derfor ikke i sig selv bevis for manipulation, og den gør heller ikke automatisk kopien ubrugelig.

Dokumentation

Skjul aldrig en afvigelse. Den skal fremgå af arbejdsnoter og rapport med:

begge værdier fuldt udskrevet med algoritme,
hvad hver værdi er beregnet af, med hvilket værktøj og hvornår,
den fundne eller sandsynlige årsag og hvordan den er fundet,
hvad afvigelsen betyder for analysen, og hvilke data der eventuelt er berørt,
hvilke korrigerende skridt der er taget, fx en ny sikring.

En afvigelse, der er opdaget, forklaret og beskrevet af den, der foretog sikringen, svækker sjældent sagen. En afvigelse, som modparten finder selv, gør. Den formelle håndtering af fejl undervejs er beskrevet i Afvigelser og fejl undervejs.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Tidslinjeanalyse: metode, kilder og faldgruber · Mobiludtræk og cloud-eksporter: hvorfor hashværdien ikke kan gentages

→ Forensisk sikring · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik