Udtræk fra mobiltelefoner: logisk, filsystem og fysisk

Forside › iPhone-forensik · Gennemgået oktober 2026 · Af John Nielsen

Når en mobiltelefon skal sikres forensisk, er det første tekniske spørgsmål, hvilken type udtræk der er mulig. Svaret afgør, hvor meget data man får, om systemartefakter og slettede poster kommer med, og hvilke spørgsmål der senere kan besvares. På moderne telefoner styres det i høj grad af kryptering, telefonens tilstand, styresystemets version og om koden er kendt.

Den praktiske side for ejeren af telefonen er beskrevet på hubben i Bevissikring af iPhone og Bevissikring af Android-telefon. Her ser vi på teknikken bag udtrækstyperne, på hvordan krypteringen afgør, hvad der overhovedet kan læses, og på hvordan resultatet dokumenteres, så det kan efterprøves. Artiklen er samtidig indgang til sitets specialartikler om mobilforensik, som er samlet nederst. Er du privatperson, er der en ikke-teknisk vejledning i, hvad en undersøgelse af din telefon kan vise.

De tre hovedtyper

• Logisk · Hvad man får: Data, som telefonen selv udleverer via backup- eller synkroniseringsfunktioner · Typisk metode: Krypteret lokal backup på iPhone, backup eller agent på Android
• Fuldt filsystem · Hvad man får: Hele filsystemet, inklusive app-databaser, systemfiler og logfiler · Typisk metode: Særlige forensiske værktøjer med understøttelse af den konkrete model
• Fysisk · Hvad man får: En bit-for-bit kopi af lagerchippen · Typisk metode: Stort set ikke længere relevant på moderne krypterede telefoner

Betegnelserne bruges ikke helt ens på tværs af værktøjer. Nogle kalder en udvidet logisk sikring for “avanceret logisk”, andre skelner mellem forskellige grader af filsystemadgang. Rapporten bør derfor beskrive, hvad der faktisk er hentet, frem for kun at bruge værktøjets betegnelse.

NIST’s niveauinddeling

NIST SP 800-101 Rev. 1 inddeler metoderne i fem niveauer efter stigende teknisk indgreb: manuel gennemgang af skærmen, logisk udtræk, hex-dump eller JTAG, chip-off og mikroskopisk aflæsning. Jo højere niveau, jo mere kræver metoden af udstyr og uddannelse, og jo større er risikoen for at beskadige enheden. Inddelingen er nyttig som fælles sprog, men den er skrevet, før fuld kryptering blev standard. I dag betyder et højt niveau ikke automatisk mere læsbar data, fordi en rå kopi af lageret er krypteret.

Den manuelle gennemgang, hvor skærmen fotograferes eller filmes, er stadig relevant som nødløsning, fx når en app ikke kan udtrækkes, eller når kun få beskeder er i spil. Den har klare svagheder: den viser kun det, appen præsenterer, den ændrer telefonens tilstand, og den giver ingen hashværdier for de underliggende data. Bruges den, skal det fremgå tydeligt af rapporten.

Kryptering afgør, hvad der kan læses

Moderne telefoner krypterer data pr. fil, og nøglerne er bundet til både hardwaren og brugerens kode. Det er derfor krypteringen, ikke værktøjet, der sætter den yderste grænse for et udtræk.

iPhone: beskyttelsesklasser

Apple beskriver i sin platformsikkerhedsguide fire beskyttelsesklasser for filer:

• A: Complete Protection · Kun mens telefonen er låst op; nøglen kasseres kort efter låsning
• B: Protected Unless Open · Åbne filer kan skrives, mens telefonen er låst; lukkede filer kan ikke genåbnes
• C: Protected Until First User Authentication · Utilgængelig indtil første oplåsning efter opstart, derefter også mens telefonen er låst
• D: No Protection · Kun beskyttet af enhedens egen nøgle

Klasse C er standard for data i tredjepartsapps. Det forklarer, hvorfor det betyder så meget, om telefonen har været låst op siden seneste genstart.

Android: CE- og DE-lager

Android bruger filbaseret kryptering, og alle enheder, der lanceres med Android 10 eller nyere, skal anvende den. Lageret er delt i to:

• Device Encrypted (DE): tilgængeligt allerede under opstarten, før brugeren har indtastet sin kode, så fx vækkeur og visse tilgængelighedsfunktioner virker.
• Credential Encrypted (CE): standardplaceringen for appdata, som først bliver tilgængelig, når brugeren har låst enheden op efter opstart.

Producenterne har desuden egne sikkerhedslag ovenpå, og derfor kan to Android-telefoner med samme version opføre sig forskelligt under et udtræk.

Telefonens tilstand: BFU og AFU

• BFU (before first unlock): Telefonen er genstartet og ikke låst op siden. Det meste data er stadig krypteret med nøgler, der først frigives ved oplåsning.
• AFU (after first unlock): Telefonen er låst op mindst én gang siden genstart. Flere nøgler er i hukommelsen, og flere data er tilgængelige.

Derfor er det vigtigt, at en tændt telefon holdes tændt, opladet og afskærmet fra netværk, indtil den er sikret. Nyere styresystemer kan selv genstarte en telefon, der ikke har været låst op i en periode, hvilket sender den tilbage i BFU. Den praktiske håndtering er beskrevet i Sådan opbevarer du en telefon, der skal sikres.

Afskærmning fra netværk har to formål. Det forhindrer fjernsletning via fx Find min eller en MDM-løsning, og det forhindrer, at nye beskeder, synkronisering og automatisk oprydning ændrer indholdet. Flytilstand er det enkleste, men kræver betjening af telefonen, og nogle telefoner kan genoptage Wi-Fi eller Bluetooth. En afskærmet pose eller boks undgår betjening, men øger strømforbruget, fordi telefonen leder efter signal. Valget og tidspunktet noteres. Om fjernsletning og MDM: se MDM og Intune som datakilde.

Logisk udtræk

Det logiske udtræk er det mest udbredte. På en iPhone svarer det i princippet til en krypteret lokal backup, som indeholder beskeder, kontakter, billeder, opkaldslister, noter og data fra mange apps. Krypteringen af backuppen er en fordel: ifølge Apple kan en krypteret backup indeholde gemte adgangskoder, Wi-Fi-indstillinger, webhistorik, helbredsdata og opkaldshistorik, som ikke kommer med i en ukrypteret. Det kræver, at telefonen er låst op, og at den har tillid til computeren. Backuppens opbygning er beskrevet i iOS-backup: krypteret, ukrypteret og hvad den indeholder.

På Android er det logiske udtræk mere uensartet. Producentens egne backupfunktioner, Googles backup og forensiske værktøjers agenter giver forskellige resultater, og meget afhænger af producent og version. Den ældre backup via adb medtager fra Android 12 som udgangspunkt ikke data fra apps, der er bygget til Android 12 eller nyere, så den giver sjældent et fyldestgørende udtræk. Se også Android-backup og Google-kontoens sikkerhedskopi.

Begrænsninger ved logisk udtræk:

• Ikke alle apps indgår i backup. Nogle apps fravælger det bevidst, især apps med fokus på privatliv.
• Slettede data er sjældent med, ud over hvad der stadig ligger i app-databaser.
• Systemlogs og mange artefakter om brug af telefonen mangler, fx detaljer om skærmtid, app-brug og netværk.
• Nogle beskedapps har egen kryptering af den lokale database eller egen backupmekanisme, som ikke følger telefonens backup.

Fuldt filsystem

Et fuldt filsystemudtræk giver adgang til de databaser, apps bruger internt, og til systemartefakter, der kan vise, hvornår telefonen var i brug, hvilke apps der var i forgrunden, hvilke netværk den var forbundet til, og hvornår den blev låst op. Det giver også bedre muligheder for at finde slettede poster inde i databaserne, fx i SQLite-filernes frie sider og skrivejournaler (WAL); se SQLite i forensic: WAL-filer, frie sider og slettede rækker.

Om det kan lade sig gøre, afhænger af telefonmodel, styresystemets version og det værktøj, der er til rådighed. Det ændrer sig løbende, når producenterne opdaterer styresystemet. Rapporten bør derfor angive værktøjets version og den præcise styresystemversion, så resultatet kan forstås i sin tid.

Hvad filsystemet typisk tilføjer

• Beskeder · Eksempler på iPhone: sms.db med iMessage og SMS · Eksempler på Android: mmssms.db eller producentens beskeddatabase
• Tredjepartsapps · Eksempler på iPhone: Appens container med SQLite og plist · Eksempler på Android: /data/data/<pakke>/ med databaser og indstillinger
• Brugsmønstre · Eksempler på iPhone: Biome, KnowledgeC på ældre versioner, skærmtid · Eksempler på Android: Usage stats, Digital Wellbeing
• Billeder · Eksempler på iPhone: Photos.sqlite med albumdata og redigeringer · Eksempler på Android: Mediedatabasen og kameraappens data
• Placering · Eksempler på iPhone: Systemets placeringsdatabaser · Eksempler på Android: Google-tjenesters og producentens lokationsdata

Databaserne og deres fortolkning er beskrevet i specialartiklerne: sms.db og iMessage, iPhone-artefakter: Biome, skærmtid og placeringsdata, Photos.sqlite, Android-artefakter: usage stats og Digital Wellbeing og Plist, LevelDB og andre app-formater. Stierne og databasenavnene skifter mellem versioner, så de skal altid aflæses i det konkrete udtræk.

Fysisk udtræk

På ældre telefoner kunne man læse hele lagerchippen. På moderne iPhone og Android-telefoner er lageret krypteret med nøgler, der er bundet til hardwaren og til brugerens kode. En rå kopi af chippen er derfor ikke læsbar uden nøglerne, og fysisk udtræk har i praksis mistet betydning. Når litteratur eller ældre rapporter nævner fysisk udtræk, gælder det typisk ældre enheder. Valget mellem metoderne i bredere forstand er beskrevet i Fysisk, logisk eller målrettet sikring.

Koden

I civile sager er koden i praksis en forudsætning. Udtræk sker med ejerens samtykke og medvirken, med koden udleveret af ejeren eller af den, der lovligt råder over enheden, eller på grundlag af en afgørelse. Uden koden er mulighederne meget begrænsede, og forsøg på at komme uden om den hører ikke til i en civil sag. Grundlaget for udtræk fra arbejdstelefoner og private telefoner er et juridisk spørgsmål, som er beskrevet i Medarbejderens private data på arbejdsudstyr. De lovlige alternativer, når koden mangler, er gennemgået i Krypterede data i en undersøgelse: de lovlige adgangsveje.

Koden noteres ikke i rapporten. Det dokumenteres, hvem der udleverede den, hvornår og på hvilket grundlag, og at den er håndteret fortroligt.

Cloud og operatør som supplement

Meget af telefonens indhold findes også i iCloud eller Google-kontoen. Et cloud-udtræk kan supplere et logisk udtræk eller erstatte det, hvis telefonen ikke er tilgængelig. Omvendt kan cloud mangle data, som kun ligger lokalt. Metoden er beskrevet i Cloud-forensic via API og administratoreksport, og Apples datakategorier i iCloud teknisk: datakategorier og lovlig eksport. Er telefonen nulstillet, er backup og cloud ofte de eneste kilder; se Den nulstillede firmatelefon.

Teleoperatøren har andre data end telefonen, fx trafikdata om opkald og SMS, men ikke indholdet af beskeder i apps. Forskellen er gennemgået i Telefonen eller teleoperatøren: hvilke data findes hvor.

Arbejdsgangen trin for trin

1. Modtagelse: Fotografér telefonen, skærmens tilstand og eventuelle meddelelser. Notér tid, batteriniveau og om den er tændt.
2. Isolering: Afskærm fra netværk, og hold strøm på, hvis telefonen er tændt.
3. Afgrænsning: Aftal med opdragsgiver, hvilke apps, kontakter og perioder analysen skal dække.
4. Valg af udtrækstype: Vælg den mest omfattende type, der er mulig og proportional, og notér hvorfor.
5. Udtræk: Gennemfør udtrækket med dokumenteret værktøj og version, og gem værktøjets log.
6. Hashværdier: Beregn hashværdier for de filer, udtrækket består af, og arbejd derefter på kopier.
7. Verifikation: Efterprøv centrale fund direkte i de underliggende databaser.
8. Tilbagelevering eller opbevaring: Dokumentér telefonens videre vej.

En samlet tjekliste til feltbrug findes i Tjekliste: tekniske trin ved sikring af en mobiltelefon.

Typiske fejlkilder i fortolkningen

• Synkroniserede data: Beskeder og billeder kan stamme fra en anden enhed på samme konto. At noget findes på telefonen, viser ikke, at det er skabt der; se Synkronisering mellem Apple-enheder og Tilknyttede enheder i WhatsApp, Messenger og Signal.
• Tidsstempler: Apps gemmer tid i forskellige formater og tidszoner. Værktøjets omregning skal kontrolleres stikprøvevis; se Tidslinjeanalyse og Tidsstempelformater.
• Værktøjets fortolkning: Parsere kan fejle ved nye app-versioner. Vigtige fund bør efterprøves direkte i den underliggende database.
• Manglende data er ikke sletning: En tom tabel kan skyldes app-indstillinger, automatisk oprydning, forsvindende beskeder eller en udtrækstype, der ikke dækker området.
• Lokationsdata: Præcisionen varierer meget mellem GPS, Wi-Fi og mobilmaster, og et punkt på et kort er ofte et estimat; se Lokationsdata på telefonen: præcision og fejlkilder.
• Ændringer under sikringen: Selve udtrækket skriver logposter og kan opdatere tidsstempler. Det skal kunne skelnes fra brugerens aktivitet.
• Gentagelse: Et nyt udtræk giver ikke samme hashværdi som det første; se Mobiludtræk og cloud-eksporter: hvorfor hashværdien ikke kan gentages.

Eksempel: et spørgsmål om slettede beskeder

Et typisk spørgsmål er, om en bestemt samtale i en beskedapp er slettet, og hvornår. Et logisk udtræk kan vise, at samtalen ikke længere findes, men sjældent mere. Et filsystemudtræk kan give adgang til appens database, dens skrivejournal og eventuelle frie sider, hvor rester af slettede rækker kan ligge. Om de findes, afhænger af appens design, hvor længe siden sletningen er sket, og hvor meget telefonen er brugt siden. Svaret i rapporten bliver derfor ofte betinget: hvad der blev fundet, hvad der ikke kunne undersøges med den valgte udtrækstype, og hvilke andre kilder, fx modpartens telefon eller en backup, der kunne belyse spørgsmålet. Realistiske forventninger er gennemgået i Slettede beskeder på telefonen og de appspecifikke artikler om WhatsApp, Signal og Telegram og Messenger og Instagram.

Hvad udtrækket kan og ikke kan bevise

Et udtræk kan vise, hvad der lå på telefonen på sikringstidspunktet, og med systemartefakter ofte også, hvordan telefonen blev brugt. Det viser ikke uden videre, hvem der holdt telefonen. Sammenhængen mellem bruger og handling må understøttes af andre forhold, fx oplåsningsmønstre, placering og samtidige hændelser på andre enheder.

Spørgsmålet om, hvorvidt en telefon er kompromitteret, er et særligt område med egne metoder og begrænsninger; se Er telefonen hacket? Hvad en undersøgelse kan vise. Hvis sagen handler om digital stalking, kan Nielco IT hjælpe med at sikre spor og lukke adgange: hjælp ved digital stalking.

Afgrænsning

Et logisk eller filsystemudtræk indeholder meget privat data. I civile sager afgrænses analysen typisk til bestemte apps, kontakter eller perioder, og afgrænsningen aftales før gennemgangen. Hele udtrækket sikres, men kun det relevante analyseres og fremlægges. Fremgangsmåden ved firmatelefoner er beskrevet i Firmatelefonen i en ansættelsessag: afgrænset og selektivt udtræk og Beskedapps i ansættelsessager.

Hvilken type skal man vælge?

Man vælger normalt den mest omfattende type, der er mulig og proportional for den konkrete telefon, og afgrænser så analysen. Det sikrer, at data ikke går tabt, hvis sagen senere udvikler sig. Er kun en bestemt app relevant, og er telefonen privat, kan et snævert logisk udtræk eller en kontrolleret eksport være det proportionale valg, selvom det giver mindre.

Dokumentation

For hvert udtræk dokumenteres:

• telefonmodel, serienummer eller IMEI, styresystem og version,
• tilstand ved modtagelse: tændt eller slukket, låst, AFU eller BFU, flytilstand, batteriniveau,
• hvem der udleverede koden, og på hvilket grundlag udtrækket blev foretaget,
• udtrækstype, værktøj og version samt eventuelle fejl eller advarsler under udtrækket,
• hashværdier for de filer, udtrækket består af,
• tidspunkt for start og afslutning, og hvem der udførte det.

Notér også, hvad der skete med telefonen før sikringen, fx om den er blevet genstartet, opdateret eller nulstillet, og om nogen har gennemset den. Sådanne handlinger kan ændre eller fjerne artefakter, og de skal kunne forklares senere. Oplysningerne indgår i kæden af ansvar, så hver overdragelse af telefonen og af udtrækket kan følges fra modtagelse til fremlæggelse.

Bemærk, at et udtræk ikke kan gentages med samme resultat. Telefonen ændrer sig, så snart den er tændt, og et senere udtræk vil indeholde andre logposter og tidsstempler. Derfor er det udtrækket og dets hashværdier, der er beviset, ikke telefonen i sin nuværende tilstand. Hvordan en modtager læser den færdige rapport kritisk, er beskrevet i Sådan læses en mobiludtræksrapport.

Tjekliste

• ☐ Telefonen er fotograferet ved modtagelse, og tilstanden (tændt, låst, AFU eller BFU) er noteret.
• ☐ Netværk er afskærmet, og strøm er sikret, hvis telefonen er tændt.
• ☐ Grundlaget for udtrækket og hvem der udleverede koden er dokumenteret.
• ☐ Afgrænsningen af analysen er aftalt skriftligt.
• ☐ Udtrækstype, værktøj og version er noteret, og værktøjets log er gemt.
• ☐ Hashværdier er beregnet for alle filer i udtrækket.
• ☐ Centrale fund er efterprøvet i de underliggende databaser.
• ☐ Rapporten skelner mellem lokale data, synkroniserede data og data, som udtrækstypen ikke dækker.

Specialartikler om mobilforensik

Emnet samlet: iPhone-forensik og Mobilforensik i civile sager. Om beskedapps som område: Beskedapps og forensik.

• Sikring: Tjekliste til mobilsikring, iOS-backup, Android-backup, iCloud teknisk
• Analyse: sms.db og iMessage, WhatsApp, Signal og Telegram, iPhone-artefakter, Android-artefakter
• Fortolkning: Lokationsdata, Synkronisering mellem Apple-enheder, Mobiludtræksrapporten
• Arbejdsplads: Firmatelefonen, MDM og Intune, Den nulstillede firmatelefon

Kilder og versioner

• NIST SP 800-101 Rev. 1: retningslinjer for mobilforensik
• Apple Platform Security: databeskyttelse på iPhone
• Apple Platform Security: beskyttelsesklasser for data
• Apple Support: om krypterede backups på iPhone
• Android Open Source Project: filbaseret kryptering
• Android Developers: adfærdsændringer i Android 12, herunder adb backup

Senest gennemgået: oktober 2026.

Del af: iPhone-forensik

Læs også: Diagnosedata fra iPhone og Android · iOS-backup: krypteret, ukrypteret og hvad den indeholder

→ Mobilforensik i civile sager · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT