Forensiske diskformater: raw, E01 og AFF4

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

En forensisk kopi indeholder de samme bytes, uanset hvilket format den gemmes i. Forskellen ligger i beholderen: om kopien er komprimeret, om sagsoplysninger og hashværdier er bygget ind, og om fejl i selve kopien kan opdages og lokaliseres. Valget af format ændrer ikke beviset, men det ændrer, hvor let det er at dokumentere, at beviset er uændret, og hvor let modparten kan efterprøve det.

Grundbegrebet er forklaret på hubben i Hvad er en forensisk kopi?. Her går vi ned i, hvordan formaterne er opbygget, hvordan de verificeres og konverteres, og hvilke fejl der typisk opstår, når kopier skifter hænder mellem parter. Artiklen samler også links til sitets specialartikler om selve sikringen og om håndteringen af kopierne bagefter.

Billede og beholder

Det hjælper at skelne mellem to lag. Billedet er rækkefølgen af bytes fra kildemediet, fra første til sidste sektor. Beholderen er den fil eller de filer, billedet er pakket i, sammen med eventuelle metadata, kontrolsummer og komprimering. Rå kopier har kun det første lag. E01 og AFF4 har begge.

Skelnen er vigtig, fordi de fleste misforståelser om forensiske kopier opstår, når nogen sammenligner noget fra det ene lag med noget fra det andet. Hashværdien i sikringsloggen gælder billedet. Filstørrelser, filnavne og hashværdier af segmentfiler gælder beholderen.

Rå kopi (raw, dd)

En rå kopi er en bit-for-bit kopi af mediet uden noget ekstra. Filen er præcis lige så stor som det kopierede område, og byte nummer 1.000.000 i filen er byte nummer 1.000.000 på disken. Filendelser som .dd, .raw, .img eller .001, .002 og så videre ved opdeling i segmenter er almindelige. Opdelingen ændrer intet ved indholdet; segmenterne skal blot sættes sammen i rækkefølge, før hashværdien beregnes.

Fordele:

• Kan læses af stort set alle værktøjer, også almindelige Linux-værktøjer og montering direkte i styresystemet.
• Intet proprietært lag, der skal fortolkes. Det gør formatet let at forklare i en rapport og let at efterprøve.
• Velegnet som mellemformat, når et analyseværktøj kræver direkte adgang til en blokenhed.

Ulemper:

• Ingen komprimering. En 2 TB-disk giver en 2 TB-fil, også selvom det meste er tomt. Det påvirker både lagerplads og overførselstid.
• Ingen indbyggede metadata. Sagsnummer, tidspunkt, værktøj, version og hashværdi skal dokumenteres i en separat log eller rapport, og den log skal følge kopien.
• Ingen indbygget kontrol af enkeltdele. Hvis en sektor i kopien senere bliver beskadiget, opdages det kun ved at genberegne hashværdien for hele kopien, og man ved ikke, hvor fejlen sidder.

Rå kopier i praksis

Fordi en rå kopi mangler metadata, står og falder den med den ledsagende dokumentation. En god praksis er at gemme en tekstfil ved siden af segmenterne med hashværdi, algoritme, antal bytes, værktøj og version, og at hashe den fil med. Ved opdeling i segmenter skal antallet og rækkefølgen fremgå, så en modtager kan kontrollere, at intet mangler. Virtuelle diskformater som VMDK og VHDX ligner på overfladen en rå kopi, men har egne strukturer og kan være tyndt allokerede; de skal behandles som en beholder, ikke som et billede. Se Virtuelle maskiner og servere.

E01 (Expert Witness Format)

E01 stammer oprindeligt fra EnCase og er i dag det mest udbredte format til diskkopier. Det kaldes også EWF. Kopien gemmes i segmentfiler (.E01, .E02 og så videre), og formatet indeholder:

• Et sagshoved med fx sagsnummer, bevisnummer, undersøger, beskrivelse, noter og tidspunkt for sikringen.
• Data i blokke (chunks), der kan komprimeres hver for sig. Komprimeringen er tabsfri; de udpakkede data er identiske med originalen.
• En kontrolsum pr. blok, så beskadigede dele kan lokaliseres i stedet for blot at konstatere, at noget er galt.
• En hashværdi for hele mediet, traditionelt MD5 og eventuelt SHA-1, beregnet under sikringen og gemt i filen.

Opbygningen lidt nærmere

Ifølge den tekniske beskrivelse i libewf-projektet er en blok som standard 64 sektorer, altså 32 KiB ved 512-byte sektorer. Ukomprimerede blokke får en Adler-32-kontrolsum, mens komprimerede blokke er beskyttet af den kontrolsum, der indgår i zlib-formatet. MD5-værdien gemmes i en særlig hash-sektion, og SHA-1 kan gemmes i en tilsvarende digest-sektion. Kontrolsummerne pr. blok er ikke kryptografiske; de afslører utilsigtede fejl som en defekt sektor på lagermediet. Det er hashværdien for hele billedet, der dokumenterer integriteten over for en modpart.

Segmentfilerne nummereres .E01 til .E99 og fortsætter derefter med bogstaver, .EAA, .EAB og så videre. Ved meget store kopier med små segmenter kan man derfor se endelser, der ikke ligner E01, selvom det er samme sæt.

Ex01 og logiske varianter

Den efterfølgende version, Ex01 (EWF2), understøtter blandt andet kryptering af beholderen og andre komprimeringsmetoder. Den er mindre udbredt, og ikke alle værktøjer kan læse den. Open source-biblioteket libewf understøtter på tidspunktet for gennemgangen (oktober 2026) ikke krypterede Ex01-filer, og skrivning af Ex01 er under udvikling. Til udveksling mellem parter er klassisk E01 derfor det sikre valg.

Det open source-bibliotek libewf gør det muligt at oprette, verificere og montere E01-filer uden kommercielle værktøjer. Det er en fordel, når modparten eller en anden sagkyndig skal kunne efterprøve kopien uden at købe samme software. Biblioteket indeholder blandt andet ewfacquire til at oprette kopier, ewfinfo til at vise de lagrede metadata, ewfverify til at genberegne og kontrollere hashværdien, ewfexport til at eksportere til rå kopi og ewfmount til at montere billedet skrivebeskyttet.

Da E01 gemmer MD5 og eventuelt SHA-1, bør SHA-256 beregnes særskilt og dokumenteres, hvis værktøjet ikke selv gør det. Baggrunden er forklaret i Hashalgoritmer i forensic.

AFF4

AFF4 (Advanced Forensic Format 4) er en nyere, åben standard, der er designet til store datamængder og mere komplekse kilder. Den afløser det ældre AFF-format, som ikke længere udvikles.

Kendetegn:

• Beholderen er baseret på ZIP, og metadata beskrives i et struktureret format (RDF), så oplysninger om kilde, værktøj og hashværdier kan læses maskinelt.
• Understøtter hurtige komprimeringsmetoder og kan registrere tomme eller ensartede områder effektivt i stedet for at gemme dem fuldt ud.
• Kan beskrive, hvordan data fra flere kilder hænger sammen, fx diskene i et RAID eller et hukommelsesbillede med huller i adresserummet.
• Bruges blandt andet til sikring af arbejdshukommelse, se Hukommelsessikring (RAM).

Understøttelsen er mere spredt end for E01. Før AFF4 vælges, bør man sikre sig, at modtageren af kopien kan læse den, eller aftale at levere en konvertering sammen med originalformatet.

Sammenligning

• Komprimering · Raw: Nej · E01: Ja · AFF4: Ja
• Indbyggede sagsoplysninger · Raw: Nej · E01: Ja · AFF4: Ja
• Indbygget hashværdi · Raw: Nej · E01: Ja · AFF4: Ja
• Kontrol af enkeltblokke · Raw: Nej · E01: Ja · AFF4: Afhænger af implementering
• Værktøjsunderstøttelse · Raw: Næsten universel · E01: Meget bred · AFF4: Mere begrænset

Logiske beholdere

Ved siden af diskformaterne findes formater til logiske udvalg af filer, fx L01 og AD1. De bruges, når kun bestemte mapper, en brugerprofil eller en postkasse sikres. De er ikke kopier af hele mediet og indeholder derfor ikke slettede data, ledig plads eller filsystemets interne strukturer. De bevarer typisk filernes metadata og hashværdier pr. fil, men ikke alt det, en fuld kopi rummer. Samme logik gælder for cloud-data, hvor en fysisk kopi slet ikke er mulig; se Cloud-forensic via API og administratoreksport.

Valget mellem fuld kopi og logisk udvalg skal begrundes i rapporten, fordi det afgør, hvilke spørgsmål der senere kan besvares. Hvornår en målrettet sikring er tilstrækkelig, er gennemgået i Målrettet indsamling og Fysisk, logisk eller målrettet sikring. Ved logiske udvalg er et hashmanifest pr. fil den bærende dokumentation; se Hashmanifest for filsamlinger og produktioner.

Hashværdien gælder data, ikke beholderen

Et vigtigt punkt ved tolkning: Den hashværdi, der dokumenterer beviset, er hashværdien af mediets data, ikke af E01-filen eller ZIP-beholderen. Konverteres en kopi fra raw til E01 eller omvendt, får beholderfilerne andre hashværdier, men hashværdien af de indeholdte data er den samme. En kopi kan derfor konverteres uden at miste sin bevisværdi, så længe dataenes hashværdi kontrolleres før og efter konverteringen, og begge værdier noteres.

Det modsatte gælder også: Hvis nogen hasher E01-segmentfilerne og sammenligner med den hashværdi, der står i sikringsloggen, vil tallene ikke passe. Det er ikke et tegn på manipulation, men på at der er sammenlignet forkerte ting. Skriv derfor altid præcist i rapporten, hvad en hashværdi er beregnet over. Andre årsager til afvigende hashværdier og den rette håndtering er gennemgået i Når hashværdien ikke stemmer.

Ved overdragelse kan det alligevel være praktisk at hashe segmentfilerne. Det giver en hurtig kontrol af, at overførslen er gået rigtigt, uden at hele billedet skal pakkes ud. Den værdi er en transportkontrol og skal betegnes sådan; den erstatter ikke verifikationen af billedet.

Verifikation og konvertering

En kopi er først færdig, når den er verificeret. Det betyder, at billedets hashværdi genberegnes ud fra den færdige beholder og sammenlignes med den værdi, der blev beregnet, mens data blev læst fra kilden. For E01 gør ewfverify eller det tilsvarende i et kommercielt værktøj netop det. For en rå kopi beregnes hashværdien af de sammensatte segmenter.

Konvertering mellem formater forekommer, fx når en modpart ønsker en rå kopi, eller når en ældre kopi skal flyttes til et format med SHA-256. Fremgangsmåden er enkel at beskrive:

1. Verificér den eksisterende kopi og notér resultatet.
2. Konvertér med et dokumenteret værktøj og version.
3. Beregn billedets hashværdi i det nye format.
4. Sammenlign med den oprindelige værdi, og notér begge med algoritme og tidspunkt.
5. Behold originalbeholderen, indtil sagen er afsluttet.

Uafhængig kontrol med et andet værktøj end det, der tog kopien, styrker dokumentationen. Det er beskrevet nærmere i Verifikation af forensiske værktøjer.

Komprimering, segmentstørrelse og lagring

Komprimering sparer plads, men koster tid under sikringen, og gevinsten afhænger af indholdet. En næsten tom disk komprimerer meget, mens en fuld disk med krypterede eller allerede komprimerede data som video og zip-filer stort set ikke bliver mindre. En krypteret disk, der kopieres uden at være låst op, ligner tilfældige data og komprimerer derfor ikke.

Segmentstørrelsen vælges efter det medie, kopien skal ligge på og overføres via. Små segmenter er lettere at overføre og kontrollere enkeltvis, men giver mange filer. Uanset valget skal antal segmenter og samlet størrelse noteres. Til meget store systemer, hvor tid og plads bliver afgørende, se Store datamængder: forensisk kopi af multi-terabyte-systemer.

Formatet påvirker også, hvordan kopien opbevares og overføres. Kryptering ved opbevaring og transport løses i praksis oftest uden for selve beholderen, fx med et krypteret lagermedie, fordi E01 ikke har kryptering. Se Overførsel af beviskopier, Opbevaring af beviskopier og Langtidsopbevaring: kan beviskopien læses om ti år?. Det sidste er et argument for de brede formater: et format, mange værktøjer kan læse i dag, er også det mest sandsynlige at kunne læses om mange år.

Typiske fejlkilder

• Ufuldstændig kopi: Læsefejl, en afbrudt sikring eller et skjult område (HPA eller DCO) kan betyde, at kopien ikke dækker hele mediet. Sikringsloggen skal vise antal sektorer og eventuelle fejl.
• Forkert kilde: Kopi af en partition i stedet for hele disken giver en gyldig hashværdi, men mangler partitionstabel og ikke-allokerede områder.
• Manglende segmenter: Mangler et segment, kan kopien ikke verificeres. Kontrollér antallet ved hver overdragelse.
• Versionsforskelle: Forskellige versioner af samme værktøj kan skrive metadata forskelligt. Notér version.
• Læsefejl, der udfyldes: Ved defekte sektorer udfylder mange værktøjer de ulæselige områder med nuller. Kopien kan stadig verificeres, men den er ikke identisk med det, der stod på disken, og områderne skal fremgå af loggen; se Defekte og fejlende diske.
• Krypteret kildemedie: En kopi af en krypteret disk er korrekt, men uden lovlig adgang til nøglen kan den ikke analyseres; se BitLocker og FileVault i bevissikring.
• Sektorstørrelse: Diske med 4K-sektorer og ældre med 512 byte skal beskrives korrekt i metadata, ellers kan offsets i rapporten blive misforstået.
• Arbejde på masteren: Analyse direkte på masterkopien i stedet for en arbejdskopi skaber risiko for utilsigtede ændringer; se Arbejdskopier og masterkopi.

Eksempel: en modpart kan ikke åbne kopien

En typisk situation er, at en modparts sagkyndige modtager en kopi og melder tilbage, at den ikke kan åbnes, eller at hashværdien ikke stemmer. Den systematiske gennemgang starter med beholderen: Er alle segmenter modtaget, og er de hele? Kan værktøjet læse formatet og versionen? Derefter billedet: Er hashværdien beregnet over billedet, med samme algoritme som i loggen? Langt de fleste tilfælde viser sig at være et manglende segment, et format, modtagerens værktøj ikke understøtter, eller en sammenligning af beholderhash med billedhash. Når forklaringen er fundet, skrives den ned, så begge parter kan se, at kopien er intakt.

Valg i praksis

• E01 som standard ved diske, fordi formatet bærer sagsoplysninger og hashværdi med sig og læses af næsten alle.
• Raw, når et særligt værktøj kræver det, eller når kopien skal monteres direkte, og dokumentationen ligger separat.
• AFF4 ved meget store datamængder eller hukommelse, hvis modtageren kan læse formatet.
• Logisk beholder, når en fuld kopi ikke er mulig eller ikke er proportional, og begrænsningen er beskrevet.

Dokumentér altid format, værktøj og version, komprimeringsniveau, segmentstørrelse, antal segmenter og hashværdier med algoritme. Kopien skal tages med skrivebeskyttelse, så originalen ikke ændres undervejs; se Skrivebeskyttere. Selve sikringen fra kilde til verificeret kopi er beskrevet i Forensisk image trin for trin, og filsystemernes forskelle, som påvirker hvad billedet senere kan vise, i Filsystemer sammenlignet.

Tjekliste til en færdig kopi

• ☐ Kilden er identificeret med model, serienummer og kapacitet, og antal sektorer stemmer med loggen.
• ☐ Skrivebeskyttelse er brugt og noteret.
• ☐ Format, værktøj, version, komprimering og segmentstørrelse er dokumenteret.
• ☐ Hashværdien er beregnet under læsningen og igen ved verifikation, med SHA-256 som en af algoritmerne.
• ☐ Læsefejl og udfyldte områder er noteret med placering.
• ☐ Antal segmenter er talt, og segmenterne er kontrolleret ved overdragelse.
• ☐ Det står klart i dokumentationen, om en hashværdi gælder billedet eller beholderen.
• ☐ Analyse sker på en arbejdskopi, og masterkopien opbevares uberørt.

Hvad formatet kan og ikke kan bevise

Et format med indbygget hashværdi og blokkontrol gør det let at vise, at kopien ikke er ændret siden sikringen. Det beviser ikke, at originalen var uberørt før sikringen, eller at det rigtige medie blev kopieret. Det skal dokumenteres i sikringsloggen og i kæden af ansvar med serienumre, fotos og tidspunkter.

Specialartikler om kopier og formater

• Før sikringen: Identifikation af datakilder, Triage eller fuld kopi, Skrivebeskyttere
• Selve sikringen: Forensisk image trin for trin, Store datamængder, Defekte diske, SSD, TRIM og gendannelse
• Særlige kilder: Virtuelle maskiner og servere, NAS-enheder, Sikring af moderne Mac
• Efter sikringen: Arbejdskopi og masterkopi, Overførsel, Opbevaring, Hashværdien stemmer ikke

Kilder og versioner

• libewf (libyal): bibliotek og værktøjer til EWF-formaterne E01 og Ex01
• libewf: teknisk beskrivelse af Expert Witness Compression Format
• NIST: Computer Forensics Tool Testing Program (CFTT)
• NIST: hashfunktioner og godkendte algoritmer

Senest gennemgået: oktober 2026.

Næste skridt

• Live response: sikring af en kørende computer eller server
• Fjernindsamling via agent eller netværk
• Sluk, isolér eller lad den køre? Beslutningen ved en tændt enhed
• Kopiering af netværksdrev og filshares uden at ændre tidsstempler

Del af: Sikring: metoderne samlet

Læs også: E01-image: montering og verifikation · Skrivebeskyttere (write blockers): hvordan og hvorfor

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