Forside › iPhone-forensik · Gennemgået oktober 2026 · Af John Nielsen
En rapport fra et mobiludtræk ser autoritativ ud: pæne tabeller med beskeder, opkald, billeder og placeringer, ofte på hundredvis af sider. Men rapporten er ikke selve dataene. Den er et analyseværktøjs fortolkning af databaser og filer fra telefonen, filtreret og formateret af den, der lavede den. For at vurdere en rapport skal man vide, hvilket udtræk den bygger på, hvilke felter der kommer direkte fra kilden, og hvilke der er beregnet eller gættet af værktøjet. Det gælder især markeringen “slettet”, tidsstempler og navne på kontakter.
Typerne af udtræk og deres begrænsninger er beskrevet i Udtræk fra mobiltelefoner. Her handler det om at læse og efterprøve den rapport, der kommer ud af det.
Rapportens opbygning
De fleste rapporter fra mobilanalyseværktøjer følger samme mønster:
- Sagsoplysninger · Hvad der skal stå: Sagsnummer, undersøger, dato · Hvad man kontrollerer: At rapporten kan knyttes til en bestemt sikring
- Enhed · Hvad der skal stå: Model, styresystem og version, serienummer, IMEI · Hvad man kontrollerer: At det er den rigtige telefon
- Udtræk · Hvad der skal stå: Udtrækstype, værktøj og version, start og slut, hashværdier · Hvad man kontrollerer: Om udtrækket kan rumme de data, rapporten bygger på
- Analyse · Hvad der skal stå: Analyseværktøj og version, valgte parsere, filtre · Hvad man kontrollerer: Om noget kan være fravalgt
- Datakategorier · Hvad der skal stå: Tabeller med beskeder, opkald, medier, placeringer · Hvad man kontrollerer: Felterne nedenfor
Mangler oplysninger om udtrækstype eller værktøjsversion, kan rapporten ikke efterprøves. Det er det første, der bør spørges om.
Kildefilen er nøglen
Hver post i en god rapport har en henvisning til den fil, den stammer fra, typisk en sti til en database i appens område og eventuelt tabel og række. Det er den vigtigste oplysning i rapporten, fordi den gør det muligt at gå tilbage til de rå data og kontrollere, at værktøjet har læst rigtigt.
Uden kildefil kan man ikke se, om en besked kommer fra appens aktive database, fra en cachefil, fra notifikationshistorikken eller fra en sikkerhedskopi på telefonen. Det har betydning: En notifikation viser, hvad telefonen fik vist, ikke nødvendigvis den fulde besked. Rapporter, der kun er udskrevet uden kildefelter, bør suppleres med en eksport, der indeholder dem.
Hvad “slettet” betyder
Markeringen slettet eller deleted dækker over flere forskellige ting, og rapporten skelner ikke altid:
- Markeret som slettet i databasen: Appen har sat et statusfelt, men rækken findes stadig.
- Gendannet fra frie sider eller WAL: Rækken er fjernet fra databasens aktive del, men rester er fundet. Indholdet kan være ufuldstændigt eller blandet med andre rækker.
- Udskåret (carved) fra ufordelt plads: Data fundet ved mønstersøgning uden databasens struktur. Tidsstempel og afsender kan være gættet.
- Fundet i en anden kilde: Beskeden findes i en sikkerhedskopi eller cache, men ikke længere i appen.
Gendannelse fra databaser er gennemgået i SQLite i forensic. Når en slettet besked er central, skal det fremgå præcist, hvilken af de fire situationer det er, og fundet bør verificeres manuelt i kildefilen.
Tidsstempler
Apps gemmer tid i mange formater: Unix-tid i sekunder, millisekunder eller mikrosekunder, Apples tidsregning fra 2001 og andre. Værktøjet konverterer og viser resultatet i den tidszone, analytikeren har valgt. Kontrollér:
- Hvilken tidszone rapporten bruger. Den bør stå i rapporten og helst være UTC med angivet forskydning.
- Hvilket tidspunkt feltet betyder: afsendt, modtaget, læst, oprettet i databasen eller ændret.
- Om tiden er telefonens eller serverens. En telefon med forkert ur giver forkerte lokale tider.
Formaterne er beskrevet i Tidsstempelformater. Et klassisk fejltegn er datoer, der ligger årtier forkert, fordi værktøjet har tolket enheden forkert.
Kontaktnavne og identiteter
Navnet ud for en besked er som regel slået op i telefonens kontaktbog på udtrækstidspunktet, ikke på det tidspunkt, beskeden blev sendt. Har ejeren omdøbt en kontakt, står det nye navn ved alle beskeder. Står der kun et telefonnummer eller et internt id, er kontakten ikke fundet i kontaktbogen.
Det samme nummer kan desuden optræde under flere apps med forskellige identiteter. Rapporten kan samle dem eller vise dem adskilt afhængigt af indstillinger. Retningen, altså indgående eller udgående, er normalt pålidelig, men bør kontrolleres for apps, hvor værktøjet har haft en ny eller ufuldstændig parser.
Parsere og versioner
Analyseværktøjer har en parser pr. app og version. Når en app opdateres, kan databasens struktur ændre sig, og en gammel parser kan læse felter forkert eller springe data over. Rapporten bør angive værktøjets version, og det bør kunne afklares, om parseren understøtter den app-version, telefonen havde. Værktøjsvalidering er gennemgået i Verifikation af forensiske værktøjer.
Data, som ingen parser genkender, kommer slet ikke med i rapporten. At en app ikke optræder, betyder ikke, at den ikke var installeret eller brugt.
Medier og vedhæftninger
Billeder og videoer vises i rapporten med miniature, filnavn, sti og metadata. Kontrollér, om det viste er originalen eller en miniature fra en cache. En miniature kan findes, selvom originalen er slettet, men den har ikke originalens metadata, og den viser ikke, hvornår billedet blev taget. Vedhæftninger i beskedapps er ofte kun henvisninger; selve filen kan mangle, fordi den aldrig blev hentet til telefonen, eller fordi appen har ryddet op. Rapporten bør skelne mellem en henvisning og en fundet fil, og hashværdier for centrale medier bør angives, så de kan genfindes i udtrækket.
Placeringer
Placeringsdata i rapporter kommer fra mange kilder: GPS, Wi-Fi, mobilmaster, billeders metadata og apps’ egne logs. Hver kilde har sin præcision, og rapporten viser ofte et punkt på et kort uden radius. En placering beregnet ud fra en mobilmast kan dække flere kilometer. Spørg efter kilde og nøjagtighed for hver afgørende placering.
Tjekliste til læsning
- ☐ Udtrækstype, værktøj, version og hashværdier er angivet.
- ☐ Tidszonen er angivet, og stikprøver passer med kendte hændelser.
- ☐ Afgørende poster har kildefil og helst tabel og række.
- ☐ Slettede poster er beskrevet præcist, og centrale fund er manuelt verificeret.
- ☐ Filtre og fravalg er beskrevet.
- ☐ Kontaktnavne er forstået som navne fra udtrækstidspunktet.
- ☐ Placeringer har kilde og nøjagtighed.
En samlet tjekliste for modpartens rapporter findes i Gennemgang af modpartens forensiske rapport.
Når mere end rapporten er nødvendig
Hvis rapporten bestrides, er den rigtige vej at få adgang til selve udtrækket og analysere det uafhængigt, eventuelt med et andet værktøj. Rapporten alene kan ikke efterprøves. Den juridiske adgang til modpartens data er en sag for advokaten; se Sikring af mobiltelefonen i en civil sag.
Hvad rapporten kan og ikke kan bevise
En korrekt udarbejdet rapport viser, hvad værktøjet fandt i et bestemt udtræk, fortolket med bestemte parsere og indstillinger. Den viser ikke, hvad der ikke blev fundet, og ikke hvem der brugte telefonen. Dens værdi afhænger af, at kilder, versioner og fravalg er åbne, så en anden kan nå samme resultat.
Kilder og versioner
- NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
Senest gennemgået: oktober 2026.
Næste skridt
- Synkronisering mellem Apple-enheder: når sporet stammer fra en anden enhed
- Messenger og Instagram teknisk: hvad der kan sikres
Del af: iPhone-forensik
Læs også: Messenger og Instagram teknisk: hvad der kan sikres · Wi-Fi- og Bluetooth-spor på enheden: netværksprofiler og parrede enheder
→ Mobilforensik i civile sager · Haster det? Forensisk sikring (hastesager koster ekstra) · For advokater · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
