Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen
Et tilbagedateret eller ændret dokument kan se helt troværdigt ud på skærmen, men filens indre struktur fortæller sjældent den samme historie. Word-filer bærer spor af redigeringssessioner, PDF-filer gemmer ofte tidligere versioner, og fonte kan være nyere end den dato, dokumentet påstår. Ingen af tegnene er afgørende alene, men flere uafhængige tegn, der peger i samme retning, kan være stærke.
Artiklen beskriver, hvor sporene ligger, hvordan de læses, og hvor fortolkningen typisk går galt. Den er overblikket. Sammenligningen med spor uden for filen står i Tilbagedaterede dokumenter, de enkelte metadatafelter i Office-metadata i core.xml og app.xml, og en ændret faktura i Ændret kontonummer i PDF-fakturaen. Skal en IT-sagkyndig undersøge dokumenterne, er opgaven beskrevet under Dokumentundersøgelse.
Office-filer: en ZIP med XML
Moderne Word-, Excel- og PowerPoint-filer (docx, xlsx, pptx) er ZIP-arkiver med XML-filer. Pakkes en kopi ud, kan de vigtigste dele læses direkte:
- docProps/core.xml · Forfatter, sidst gemt af, oprettet, ændret og revisionsnummer
- docProps/app.xml · Program og version, samlet redigeringstid, skabelon og firma
word/settings.xml· Liste over rsid-værdier- word/document.xml · Selve teksten med rsid-attributter
- word/theme/theme1.xml · Temaets standardfonte
Metadatafelterne kan ændres med almindelige værktøjer og endda direkte i Office. De enkelte værdier er derfor svage beviser. Uoverensstemmelser mellem felterne er mere interessante, fx et revisionsnummer på 1 kombineret med en redigeringstid på flere timer, eller en ændringsdato, der ligger før oprettelsesdatoen. Grundbegreberne er forklaret i Hvad er metadata?.
Bemærk også, at redigeringstiden tæller den tid, dokumentet har været åbent til redigering, ikke den tid, nogen aktivt har skrevet. Et dokument, der har stået åbent hen over en weekend, kan have en meget høj værdi uden at være mistænkeligt.
rsid i Word
Word tildeler hver redigeringssession en tilfældig værdi, et rsid (revision save id). Værdierne skrives som attributter på afsnit og tekststykker, fx w:rsidR, w:rsidRPr og w:rsidP, og samles i elementet w:rsids i settings.xml. w:rsidRoot angiver den første session.
Det kan bruges til at:
- se, hvilke afsnit der er tilføjet eller ændret i samme session,
- vise, at et bestemt afsnit, fx en ansvarsfraskrivelse eller en ændret pris, er tilføjet i en senere session end resten af dokumentet,
- sammenligne to dokumenter, hvor fælles rsid-værdier tyder på fælles oprindelse. Den bredere metode til sammenligning står i Dokumentlighed.
Begrænsningerne er væsentlige. rsid-værdierne indeholder ingen tidsstempler. Standarden for formatet (ISO/IEC 29500) beskriver stigende værdier for hver ny redigeringssession, men rækkefølgen i listen bør ikke alene bruges som kronologi. Andre programmer end Word, og andre udgaver af Word, skriver dem ikke nødvendigvis eller håndterer dem anderledes, så det anvendte program skal indgå i vurderingen. Kopiering af tekst mellem dokumenter kan også føre rsid-værdier med.
Fonte og skabeloner
- En font, der først blev udgivet efter dokumentets påståede dato, er et af de klareste tegn. Fontens udgivelse skal dokumenteres uafhængigt, typisk via versionsoplysninger i fontfilen og producentens historik.
- Temaets standardfonte og skabelonens navn kan pege på en bestemt Office-version. Ændres standardfonten i en ny Office-version, kan et dokument med den nye standard være vanskeligt at forene med en ældre dato.
- Forskellige fonte, fontstørrelser eller formatering i et afsnit, der ellers er ensartet, kan tyde på indsat tekst.
ZIP-strukturen
Microsoft Office skriver typisk ZIP-poster med en fast dato i 1980 og en bestemt rækkefølge af filerne. Er en Office-fil pakket om af et andet værktøj, kan datoer, rækkefølge og komprimering afvige. Det viser ikke forfalskning, men at filen er behandlet uden for Office, fx af et konverteringsværktøj, et dokumentsystem eller manuelt. Det skal forklares, hvis filen påstås at komme direkte fra Word.
PDF: Info-ordbog og XMP
En PDF kan have metadata to steder:
- Info-ordbogen med Producer, Creator,
CreationDateogModDate. - XMP-metadata (XML) med blandt andet
CreateDate,ModifyDate, DocumentID, InstanceID og eventuelt en redigeringshistorik.
Er de to sæt forskellige, er filen typisk ændret af et program, der kun har opdateret det ene. DocumentID følger dokumentet gennem versioner, mens InstanceID skifter ved ændringer. Producer-feltet kan afsløre, at en påstået scanning i virkeligheden er genereret direkte fra et tekstbehandlingsprogram. Om PDF som bevis generelt, se Kan man stole på et PDF-dokument?.
Inkrementelle opdateringer
PDF-formatet tillader, at ændringer tilføjes i slutningen af filen i stedet for at omskrive den. Hver opdatering tilføjer nye objekter, en ny krydsreferencetabel og en ny EOF-markering. Det betyder:
- Flere EOF-markeringer i filen tyder på, at den er ændret efter oprettelsen.
- Den tidligere version kan ofte genskabes ved at læse filen frem til en tidligere EOF-markering.
- Feltet Prev i trailer eller krydsreferencestrøm peger på den tidligere version.
Inkrementelle opdateringer er også helt normale, fx ved udfyldning af formularer, kommentarer eller digital signering. Det afgørende er, hvad der er ændret mellem versionerne. Ved digitalt signerede PDF-filer angiver ByteRange, hvilke bytes signaturen dækker. Ændringer efter signeringen ligger uden for dette område og kan identificeres og sammenholdes med signaturtidspunktet.
Sikring af dokumentet
Hvilket eksemplar der undersøges, er afgørende. En fil, der er sendt som vedhæftning, downloadet fra en portal eller gemt igen fra en mailklient, kan have mistet eller fået nye egenskaber undervejs. Det bedste udgangspunkt er derfor filen fra den kilde, hvor den er opstået eller først registreret:
- filen fra afsenderens eller forfatterens computer, helst fra en forensisk kopi af disken,
- den originale mail med vedhæftning i uændret form,
- filen og dens versionshistorik fra dokumentsystemet eller cloudlageret, eksporteret med de tilhørende metadata.
Notér for hvert eksemplar, hvor det kommer fra, hvem der har leveret det, og hvornår det er modtaget. Beregn hashværdien straks. Findes flere eksemplarer af samme dokument, er det i sig selv værdifuldt: Er hashværdierne ens, er filerne identiske, og er de forskellige, kan en sammenligning af struktur og metadata vise præcis, hvad der adskiller dem.
Værktøjskategorier
- Metadataværktøjer, der læser både Office og PDF.
- Arkiv- og XML-værktøjer til gennemgang af Office-filens dele.
- PDF-strukturværktøjer, der viser objekter, krydsreferencer og versioner.
- Hex-editorer til søgning efter rå strukturer og markører.
Arbejd altid på en kopi med kendt hashværdi, og notér værktøj og version for hvert fund. Se Hashalgoritmer i forensic.
Sammenhold med eksterne spor
Dokumentets indre spor bør sammenholdes med kilder uden for filen:
- filsystemets tidsstempler og MFT-poster på den computer, hvor filen er lavet,
- mails, hvor dokumentet er sendt, med serverens tidsstempler,
- versionshistorik i SharePoint, OneDrive eller Google Drive,
- backup fra den påståede periode.
Eksterne kilder kontrolleres af andre systemer og er vanskeligere at ændre samtidig. De vejer derfor ofte tungere end filens egne felter. En samlet kronologi bygges som beskrevet i Tidslinjeanalyse. Brugernes perspektiv på Office-filer som bevis findes i Word- og Excel-filer som bevis.
Typiske fejlkilder
- Konvertering mellem formater, fx doc til docx eller Word til PDF, ændrer metadata uden nogen hensigt om at skjule noget.
- Kopiering, download og mailvedhæftning kan ændre filsystemets tidsstempler, mens de interne felter bevares.
- Skabeloner kan føre forfatter, firma og ældre rsid-værdier med ind i nye dokumenter.
Formulering i rapporten
Tekniske tegn viser uoverensstemmelser, ikke hensigt. Rapporten bør beskrive hvert fund med kilde og rå værdi, opstille de mulige forklaringer og vurdere, hvor godt de passer med den påståede historik. Se Rapportskrivning.
Kilder og versioner
- Microsoft Learn: rsid-elementet i Open XML (ISO/IEC 29500)
- ISO 32000-2: PDF 2.0, herunder inkrementelle opdateringer
- Ecma-376: Office Open XML-formaterne
Senest gennemgået: oktober 2026.
Næste skridt
- Hvornår er billedet taget? EXIF, XMP og IPTC forklaret
- Metadata, der forsvinder ved upload og deling
- Falske chatbilleder: verifikation mod kildeenheden og appens database
- Audit trail i e-signaturløsninger
Del af: Analyse og fortolkning
Læs også: Hvilket kamera tog billedet? · Metadata i Office-filer: forfatter, tider og redigeringstid i core.xml og app.xml
→ Teknisk undersøgelse af dokumenter og metadata · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT