Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen
Om et skærmbillede af en sms, en iMessage eller en WhatsApp-samtale er ægte, afgøres sjældent ved at se på billedet. Det afgøres ved at finde samtalen der, hvor den er gemt: i beskedappens database på en af de involverede telefoner, i en backup eller i en eksport fra tjenesten. Findes beskeden med samme tekst, samme afsender og samme tidspunkt, er billedet bekræftet. Findes den ikke, skal det forklares, fordi fraværet kan have flere årsager.
Hvad advokaten bør spørge om, når modparten fremlægger skærmbilleder, står på Modparten fremlægger skærmbilleder. Den tekniske vurdering af selve billedfilen er beskrevet i Teknisk vurdering af et skærmbillede. Denne artikel handler om verifikationen mod kilden.
Hvordan et falsk chatbillede typisk opstår
Det kræver ingen særlig teknik at lave et billede af en samtale, der aldrig har fundet sted. De almindelige veje er:
- Ændret kontaktnavn. Navnet øverst i en samtale kommer fra telefonens egen kontaktbog. Gemmes et andet nummer under en kendt persons navn, ser samtalen ud til at være med den person.
- Redigeret billede, hvor tekst, tidspunkt eller afsender er ændret i et billedprogram.
- Apps og websider, der efterligner en beskedapps udseende og laver et billede ud fra indtastet tekst.
- Udklip og sammensætning, hvor beskeder fra forskellige samtaler eller tidspunkter sættes sammen, eller hvor svar er klippet væk.
- Slettede eller redigerede beskeder, hvor billedet viser en tidligere version af samtalen, som den ene part siden har ændret.
AI-genereret materiale er en mulighed, men ikke den mest almindelige. Metoder til at vurdere det står i AI-genereret indhold.
Kilden: beskedappens database
Beskedapps gemmer samtaler i lokale databaser, typisk SQLite. På iPhone ligger sms og iMessage i sms.db, og WhatsApp har sin egen database, på Android typisk msgstore.db. Signal og andre krypterede apps har krypterede databaser, der kun kan læses i et udtræk fra den oplåste telefon. Strukturen er beskrevet i sms.db og iMessage og WhatsApp-databasen.
For hver besked kan databasen typisk vise:
- teksten og eventuelle vedhæftninger,
- om beskeden er sendt eller modtaget,
- modpartens telefonnummer eller konto-id, ikke kun et navn,
- tidspunktet for afsendelse, levering og læsning, gemt i et format, der skal omregnes,
- en intern rækkefølge og id, der viser beskedens plads i samtalen,
- markeringer for redigerede eller slettede beskeder, afhængigt af app og version.
Sammenlign hvert element på skærmbilledet med den tilsvarende række. Navnet på billedet sammenholdes med kontaktbogens kobling til nummeret, ikke kun med databasen over beskeder.
Sikring af kilden
Verifikationen kræver et udtræk af telefonen, ikke et nyt skærmbillede eller en eksport fra appen. Et logisk udtræk eller et udtræk af filsystemet giver adgang til databaserne, mens appens egen eksport ofte udelader tidsstempler, status og slettede rækker. Metoderne er beskrevet i Udtræk fra mobiltelefoner. Adgangen skal ske ad lovlige veje, typisk med ejerens samtykke og kode.
Det er en fordel at sikre begge parters telefoner, hvis det er muligt. En besked, der findes hos afsender, men ikke hos modtager, eller omvendt, fortæller noget i sig selv. Krypterede backups og cloudsynkronisering kan være et supplement, hvis en telefon er udskiftet.
Slettede beskeder og fravær
At en besked ikke findes i databasen, betyder ikke automatisk, at billedet er falsk. Beskeden kan være slettet af brugeren, slettet automatisk efter en indstillet periode, eller ligge på en anden enhed, fx en tidligere telefon eller en computer med samme konto. Slettede rækker kan i nogle tilfælde findes i databasens frie sider eller i WAL-filen, se SQLite: WAL-filer og slettede rækker.
Omvendt kan et hul i rækkefølgen af interne id’er eller et spring i tidsstemplerne pege på, at noget er slettet. Det viser, at der har været en række, ikke hvad den indeholdt.
Layout og versioner
Selve billedet kan sammenholdes med det, appen faktisk viste på det tidspunkt:
- Statuslinjen: klokkeslæt, batteri, netværk og ikoner skal passe med telefonens model og styresystem.
- Appens layout: farver, bobler, skrift og ikoner ændres med appversionerne. Et layout, der først kom i en senere version, passer ikke med en ældre dato.
- Tidsformat og sprog skal passe med telefonens indstillinger.
Disse spor er svagere end databasen, fordi de afhænger af referencemateriale for de konkrete versioner. De bruges, når kilden ikke er tilgængelig. Referencebilleder skal være lavet på en kendt version, og det skal dokumenteres. Ældre appversioner kan ikke altid fremskaffes, og kan referencen ikke laves på den relevante version, skal det fremgå, og sporet tillægges tilsvarende mindre vægt.
Skærmbilledet på enheden
Er telefonen, der tog skærmbilledet, tilgængelig, kan billedet også findes i mediebiblioteket. Billedets oprettelsestid og eventuelle markering som skærmbillede kan sammenholdes med tidspunktet for den sidste viste besked. Et skærmbillede taget før den seneste besked på billedet er et klart problem. Spor efter apps, der efterligner beskedvisninger, kan også findes i oversigten over installerede apps og deres brug.
Fremgangsmåde
En verifikation kan følge disse trin:
- Modtag skærmbillederne som filer, ikke som udskrifter eller indsat i et dokument, og beregn hashværdi for hver fil.
- Udtræk de synlige oplysninger fra hvert billede: navn eller nummer, tekst, klokkeslæt, dato-adskillere, statusmarkeringer og rækkefølge.
- Sikr kildeenheden ved et udtræk, og beregn hashværdier for de relevante databaser.
- Find samtalen ud fra nummer eller konto-id, ikke ud fra navn, og sammenhold hver besked med billedet.
- Søg efter slettede rækker og huller i rækkefølgen omkring det relevante tidsrum.
- Sammenhold med andre kilder, fx den anden parts telefon, opkaldslister, mails eller kalenderaftaler, der nævnes i samtalen.
- Dokumentér afvigelser enkeltvis med de mulige forklaringer.
Rækkefølgen sikrer, at sammenligningen bygger på den stærkeste kilde, og at fortolkningen af svagere spor først kommer, når kilden er udtømt. Arbejd på kopier af databaserne, ikke ved at åbne appen på telefonen, fordi appen kan ændre status, synkronisere og slette efter egne regler.
Typiske fejlkilder
- Tidszoner og tidsformater. Databaserne gemmer tid i forskellige epoker og enheder. En forkert omregning giver en tilsyneladende uoverensstemmelse.
- Flere enheder. iMessage og WhatsApp kan bruges på flere enheder med samme konto, og indholdet er ikke altid ens på alle.
- Gruppesamtaler. Afsenderen fremgår på en anden måde end i en samtale mellem to.
- Ændrede kontakter. Kontaktbogen kan være ændret efter samtalen, så navnet i dag ikke er det samme som dengang.
Hvad verifikationen kan og ikke kan bevise
Findes samtalen i databasen med samme indhold, tidspunkt og nummer, er skærmbilledet bekræftet med høj sikkerhed som en gengivelse af en reel samtale på den enhed. Findes den ikke, og er der ingen spor af sletning, er det et tungt argument mod billedet, men ikke et endeligt bevis. Ingen af delene viser, hvem der fysisk skrev beskeden.
I rapporten
Gengiv for hver besked på billedet den tilsvarende række med nummer eller konto-id, rå og omregnet tid, retning og status. Beskriv udtrækket, værktøj og version, og angiv hashværdier for databaser og billeder. Afvigelser og mulige forklaringer skrives særskilt.
Kilder og versioner
- NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics
- SQLite: Databasens filformat
- SWGDE: Publicerede dokumenter om mobil forensik og billeder
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Analyse og fortolkning
Læs også: Tilbagedaterede dokumenter: filsystemets tidsstempler mod dokumentets egne · Teknisk vurdering af et skærmbillede
→ Teknisk undersøgelse af dokumenter og metadata · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
