Mobiludtræk og cloud‑eksporter: hvorfor hashværdien ikke kan gentages

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

Tager man to udtræk af den samme telefon eller to eksporter af den samme postkasse, får man næsten altid to forskellige hashværdier. Det er ikke en fejl og ikke et tegn på manipulation. Kilden er levende, og udtrækket er en ny fil, som værktøjet bygger hver gang. Hashværdien beskytter derfor udtrækket fra det øjeblik, det er lavet, men kan ikke bruges til at vise, at udtrækket er identisk med kilden, sådan som man kan med en diskkopi. Integriteten skal i stedet vises på andre måder.

Indsigelsen kommer typisk sådan: “Modpartens eget udtræk giver en anden hashværdi, så det fremlagte kan ikke være korrekt.” Denne artikel forklarer, hvorfor præmissen er forkert, og hvordan man underbygger udtrækket i stedet. Udtrækstyperne er beskrevet i Udtræk fra mobiltelefoner og overblikket i Mobilforensik, cloud-indsamling i Cloud-forensic via API og administratoreksport og Apples cloud i iCloud teknisk: datakategorier og lovlig eksport. Fejlsøgning, når en hashværdi af en diskkopi eller fil ikke stemmer, står i Når hashværdien ikke stemmer.

Diskkopien som sammenligningsgrundlag

Ved en slukket harddisk bag skrivebeskyttelse er kilden statisk. To uafhængige kopier giver samme hashværdi, og en modpart kan selv hashe originalen og få samme resultat. Det er den egenskab, der gør hashværdien så stærk ved diskkopier. Ved telefoner og cloud findes den egenskab ikke.

Hvorfor telefonen giver en ny værdi hver gang

Telefonen skriver hele tiden: Systemlogs, app-databaser, batteristatistik, netværksstatus og notifikationer opdateres, så længe den er tændt, også i flytilstand.
Udtrækket kræver interaktion: At låse op, parre med en computer og starte en backup eller en agent skaber selv nye poster.
Udtrækket er en beholder bygget af værktøjet: Rækkefølge af filer, komprimering, tidsstempler i beholderen og værktøjets egne metadata varierer mellem kørsler og versioner.
Backupbaserede udtræk afhænger af, hvad styresystemet vælger at levere, og det kan ændre sig mellem versioner.
Krypterede backups krypteres med nye tilfældige værdier ved hver kørsel, så selv samme indhold giver forskellige filer.

Hvorfor cloud-eksporter giver en ny værdi

En eksport fra Microsoft 365, Google Workspace eller et SaaS-system er en ny pakke, som tjenesten genererer på eksporttidspunktet. Pakken kan have en anden opdeling i filer, en anden rækkefølge, nye eksporttidsstempler og eksportrapporter med dato. Postkassen kan desuden have ændret sig: nye mails, flyttede elementer, opbevaringspolitikker, der har slettet noget. Selv to eksporter med få minutters mellemrum er sjældent bitidentiske.

Hvornår hashværdien skal beregnes

Fordi udtrækket ikke kan gentages, er tidspunktet for den første hashberegning afgørende. Mange mobilværktøjer beregner hashværdien automatisk, når udtrækket er færdigt, og skriver den i en rapport. Ved cloud-eksporter skal det ofte gøres manuelt, når pakken er hentet. Beregn hashværdien med det samme, før pakken flyttes, pakkes ud eller åbnes, og notér tidspunkt og værktøj. Hentes eksporten i flere dele, hashes hver del for sig, og antallet af dele noteres, så det kan ses, at intet mangler.

Hvad hashværdien så beskytter

Hashværdien af udtrækket eller eksporten, beregnet straks efter dannelsen, viser, at filen ikke er ændret siden. Det er stadig vigtigt: Den fastlåser beviset, så alle senere analyser kan føres tilbage til en bestemt, uændret fil. Det er den del af kæden af ansvar, som hashværdien kan bære. Spørgsmålet om, hvorvidt udtrækket gengiver kilden korrekt, skal besvares på andre måder.

Integritet på fil- og elementniveau

Det, der kan sammenlignes på tværs af to udtræk, er ofte de enkelte filer og poster inde i beholderen:

Uændrede filer har samme hashværdi: Et billede, en vedhæftning eller et dokument, der ikke er ændret på telefonen eller i kontoen, har samme hashværdi i begge udtræk. Det gælder ikke databaser, som ændres løbende.
Poster i databaser kan sammenlignes indholdsmæssigt: En besked med samme tekst, tidsstempel, afsender og interne id i begge udtræk er den samme besked, selv om databasefilen har en ny hashværdi.
Mails har stabile identifikatorer: Message-ID og headere kan sammenlignes. Hashværdien af en mail afhænger derimod af eksportformatet.
Et filmanifest fra første udtræk gør sammenligningen mulig. Se Hashmanifest for filsamlinger og produktioner.

Ved cloud kan visse tjenester levere en hashværdi eller kontrolsum pr. fil, beregnet af tjenesten selv. Hvis den findes, er den et stærkt, uafhængigt sammenligningspunkt. Algoritmen varierer: Google Drive-API’et oplyser MD5 og, hvor det er muligt, SHA-1 og SHA-256 for filer med binært indhold; Dropbox bruger en egen content_hash bygget på SHA-256 over blokke af 4 MB; OneDrive og SharePoint oplyser typisk Microsofts egen quickXorHash; og Amazon S3 kan gemme kontrolsummer i flere algoritmer. En værdi i en egen algoritme kan kun sammenlignes med en værdi beregnet på samme måde.

Andre måder at underbygge udtrækket

Værktøjets log over start, slut, antal elementer, fejl og advarsler.
Enhedens tilstand ved udtrækket: tid på enheden, styresystemversion, låsetilstand, flytilstand.
Tjenestens auditlog, der uafhængigt viser, at eksporten blev foretaget af en bestemt konto på et bestemt tidspunkt.
Krydsvalidering af centrale fund med et andet værktøj eller ved manuel kontrol af den rå database.
Fotodokumentation af centrale skærmbilleder på enheden, hvis det er relevant og sker kontrolleret.
Uafhængige kilder som modtagerens kopi, mailserverens logs eller teleoperatørens data.

Når modparten fremlægger sit eget udtræk

Har to parter hver sit udtræk af samme telefon eller konto, er den relevante sammenligning ikke hashværdien af de to beholdere. Spørgsmålene er:

Er udtrækkene af samme type (logisk, filsystem, backup), og med hvilke værktøjer og versioner?
Hvornår er de taget, og hvad er sket med enheden eller kontoen imellem?
Findes de afgørende filer og poster i begge, og stemmer deres hashværdier og indhold?
Er der poster i det ene, som mangler i det andet, og kan det forklares med tidsforskellen eller udtrækstypen?

Forskelle forklaret af tid og metode er normale. Forskelle i indholdet af en bestemt besked eller fil, der burde være uændret, er det, der kræver en forklaring. Den juridiske side af ægthedsindsigelser er beskrevet i Indsigelse mod et digitalt bevis’ ægthed.

Typiske fejlkilder

At love gentagelighed: En rapport, der antyder, at modparten kan genskabe samme hashværdi ved et nyt udtræk, inviterer til en unødig indsigelse.
At hashe for sent: En eksport, der ligger i en downloadmappe i dagevis, før den hashes, har et hul i kæden.
At pakke eksporten ud og pakke den sammen igen: Den nye zip-fil har en ny hashværdi og kan ikke kobles til den oprindelige uden dokumentation.
At sammenligne en brugerforanlediget eksport med en forensisk. De kan have helt forskelligt indhold. Se Selvindsamling.

Hvad det kan og ikke kan bevise

Udtrækkets hashværdi beviser, at den fremlagte fil er den samme, som blev dannet ved udtrækket. Filhashværdier og stabile identifikatorer kan vise, at konkrete filer og beskeder er uændrede mellem to udtræk. Ingen af delene beviser alene, at udtrækket er fuldstændigt, eller at kilden ikke var ændret før udtrækket.

Dokumentation

Skriv i rapporten, at udtrækket ikke kan gentages bitidentisk, og hvorfor. Angiv hashværdien af beholderen, hvornår den er beregnet, og hvilke filer eller poster der er hashet for sig. Beskriv værktøj, version, udtrækstype og enhedens tilstand. Så er indsigelsen besvaret, før den bliver rejst. Ved uforklarede afvigelser i en diskkopi gælder i stedet fejlsøgningen i Når hashværdien ikke stemmer.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Når hashværdien ikke stemmer: årsager og håndtering · Hashmanifest for filsamlinger og produktioner

→ Mobilforensik i civile sager · 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

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Eller kontakt os på