Wie erkenne ich Dateitypen zuverlässig anhand von Dateisignaturen (Magic Numbers) statt nur über die Dateiendung?

Grundlagen: Dateisignaturen, Magic Numbers, Offsets und typische Fallstricke bei Containern und Varianten

Dateisignaturen (häufig als Magic Numbers bezeichnet) sind kurze Bytefolgen, die an definierten Positionen innerhalb einer Datei auftreten und Rückschlüsse auf das Format erlauben. Anders als Dateiendungen hängen sie nicht vom Namen im Dateisystem ab, sondern vom tatsächlichen Inhalt. In der Praxis dienen Signaturen als erster Filter für Parser, Forensik-Workflows, Upload-Validierung und Malware-Analysen. Die Aussagekraft ist hoch, aber nicht absolut: Viele Formate sind Container, einige teilen sich Basissignaturen, und manche Varianten unterscheiden sich erst in nachgelagerten Headerfeldern.

Der Begriff „Magic Number“ wird je nach Kontext eng (exakte Bytefolge) oder breit (inklusive Headerstruktur) verwendet. Für robuste Erkennung reicht ein einzelner Vergleich oft nicht aus: Validierung umfasst typischerweise eine Kombination aus Signaturprüfung, plausiblen Längen- und Feldwerten, optionalen Checksummen sowie einer konsistenten internen Struktur. Eine Datei kann zudem mehrere „Magics“ enthalten, etwa bei eingebetteten Ressourcen oder bei Polyglots, die absichtlich mehrere Parserpfade bedienen.

Magic Numbers und Header: Was tatsächlich verglichen wird

Eine Signaturprüfung vergleicht eine Bytefolge in Hexdarstellung (z. B. 25 50 44 46 für „%PDF“) mit dem Dateistrom. Dabei ist zu trennen zwischen (a) reinen „File Magics“ am Anfang, (b) Markern an anderen Offsets, und (c) strukturellen Merkmalen, die erst nach dem Parsen eines Headers validiert werden können. Viele Formate haben zusätzlich eine menschenlesbare ASCII-Komponente, doch die Erkennung muss immer auf Bytes erfolgen, nicht auf Textkodierung.

Ein verbreiteter Fallstrick ist die Verwechslung von Signatur und „Branding“. Bei ISO Base Media File Format (ISOBMFF) beginnt die Datei häufig mit einer ftyp-Box, deren Marken (z. B. isom, mp41, qt ) auf MP4/M4A/MOV hinweisen. Die ersten 12 Bytes lauten jedoch nicht immer identisch; je nach Boxlänge steht 66 74 79 70 („ftyp“) erst ab Offset 4. Ein bloßer Vergleich der ersten 4 Bytes wäre hier unzureichend.

Offsets, relative Positionen und das Ende-der-Datei-Problem

Offsets geben an, an welcher Byteposition eine Signatur erwartet wird. Üblich ist die Angabe als dezimaler oder hexadezimaler Offset ab Dateianfang (0-basiert). Einige Formate nutzen Marker am Dateiende, etwa ZIP mit dem „End of Central Directory“-Record; hier ist der relevante Marker zwar eindeutig, aber nicht an einer festen absoluten Position. Für solche Fälle wird mit einer Rückwärtssuche in einem begrenzten Fenster gearbeitet, um Performance- und Manipulationsrisiken zu steuern.

Auch Alignment und Voranstellen von Daten beeinflussen Offsets. Dateien können mit Präambeln oder übertragenen Wrappern (E-Mail, Base64, HTTP-Multipart) auftreten, die vor der eigentlichen Datei liegen. Für verlässliche Prüfroutinen ist deshalb zu definieren, ob auf dem Rohstrom, nach Dekodierung oder nach Extraktion geprüft wird. In Forensik-Workflows wird zudem zwischen „file carving“ (Suche nach Magic im Datenträgerabbild) und „file identification“ (Prüfung einer bereits extrahierten Datei) unterschieden; beide verwenden Offsets unterschiedlich.

Containerformate, „Formatfamilien“ und Mehrdeutigkeiten

Containerformate bündeln Daten und Metadaten, ohne den eigentlichen Nutzinhalt festzulegen. Dadurch teilen sich unterschiedliche Dateitypen identische oder sehr ähnliche Signaturen. ZIP-basierte Office-Dokumente (DOCX/XLSX/PPTX), JAR/APK, EPUB und ODT sind klassische Beispiele: Sie beginnen als ZIP häufig mit 50 4B 03 04 (lokaler Header), unterscheiden sich aber durch spezifische Pfade und Dateien im Archiv (z. B. [Content_Types].xml, word/document.xml, META-INF/MANIFEST.MF, AndroidManifest.xml). Eine reine Magic-Prüfung identifiziert hier nur die Containerhülle.

Ähnliche Effekte treten bei RIFF (52 49 46 46) auf: WAVE, AVI und WebP nutzen denselben Container und unterscheiden sich über FourCCs in nachgelagerten Feldern (WAVE, AVI , WEBP). OLE Compound File (D0 CF 11 E0 A1 B1 1A E1) kapselt ältere Office-Formate (DOC/XLS/PPT) und weitere Anwendungen; die sichere Klassifikation erfordert das Prüfen von Stream-Namen und (wo vorhanden) anwendungsspezifischen Metadaten im Storage/Directory.

Typische Fallstricke: manipulierte Endungen, Polyglots, Trunkierung

Angriffe nutzen häufig die Differenz zwischen Dateiendung und Inhalt aus. Eine umbenannte ausführbare Datei mit Endung .jpg ist trivial, wird aber in E-Mail- oder Web-Kontexten dennoch regelmäßig angetroffen. Ebenso verbreitet sind „Doppelendungen“ (z. B. rechnung.pdf.exe) und Unicode-Tricks, die die Sichtbarkeit der tatsächlichen Endung beeinflussen. Eine Signaturprüfung reduziert diese Risiken, ersetzt aber keine Sicherheitsanalyse: Dateien können absichtlich so konstruiert sein, dass mehrere Parser sie akzeptieren (Polyglot), oder dass ein Parser abstürzt (Malformation).

Weitere Fehlerquelle ist Trunkierung: Ein Dateianfang mit korrekter Magic Number kann aus einem unvollständigen Download stammen oder absichtlich abgeschnitten sein. Gerade bei Formaten mit Endmarkern (JPEG) oder zentralen Verzeichnissen (ZIP) ist das Erkennen unvollständiger Strukturen entscheidend. Auch „SFX“-Varianten (selbstextrahierende Archive) enthalten vorn einen PE-Header und danach ZIP-Daten; je nach Erkennungslogik dominiert dann PE oder ZIP. In solchen Fällen sollte die Erkennung mehrere „Treffer“ protokollieren und eine Priorisierungsregel anwenden.

• Endung vs. Inhalt: Abgleich des MIME-Typs und der Dateiendung mit einer Inhaltsprüfung; bei Widerspruch als „mismatch“ markieren statt stillschweigend zu akzeptieren.
• Mehrstufige Validierung: Erst Magic/Offset prüfen, danach Headerfelder plausibilisieren (z. B. Längen, Versionen, zulässige FourCC/Brands) und bei Containern zusätzlich erwartete Einträge verifizieren.
• Trunkierung erkennen: Für ZIP die Konsistenz von EOCD, Central Directory-Größe und -Offset gegen die Dateilänge prüfen; für JPEG das Vorhandensein von FF D9 sowie konsistente Segmentlängen validieren.
• Polyglots und SFX: Bei mehreren plausiblen Signaturen (z. B. 4D 5A und 50 4B) alle Kandidaten erfassen und die weitere Analyse am konkreten Risiko- und Verarbeitungskontext ausrichten.
• Offset-Fenster begrenzen: Bei Rückwärtssuchen (ZIP) ein festes Suchfenster verwenden und bei Überschreitung als verdächtig behandeln, um manipulierte „Giga-Comments“ oder Performance-Angriffe zu entschärfen.

Prüfmethoden im Kern: Bytevergleich, Parser, Heuristiken

Ein belastbarer Prüfpfad trennt schnelle, deterministische Checks von komplexeren Analysen. Stufe 1 ist der Bytevergleich an definierten Offsets, vorzugsweise mit mehreren Signaturen pro Formatfamilie. Stufe 2 validiert strukturierende Elemente: Box-/Chunk-Längen, Pflichtfelder, zulässige Wertebereiche und die Konsistenz interner Offsets. Stufe 3 nutzt Parser oder Bibliotheken, die das Format vollständig interpretieren; hier entstehen zusätzliche Angriffsflächen, weshalb Parsen in Sicherheitskontexten restriktiv und isoliert erfolgen sollte (Timeouts, Größenlimits, Abbruch bei Rekursion).

Heuristiken sind sinnvoll, wenn eindeutige Signaturen fehlen oder absichtlich verschleiert wurden. Dazu gehören Entropie- und Kompressionsindikatoren, typische Klartextsequenzen (z. B. XML-Prolog 3C 3F 78 6D 6C) oder das Erkennen von eingebetteten Objekten. Heuristiken liefern Wahrscheinlichkeiten, keine Beweise. Für ein Nachschlagewerk zur Dateityperkennung sollte deshalb stets dokumentiert werden, welche Kriterien „hart“ (signatur-/strukturgebunden) und welche „weich“ (heuristisch) sind.

Nachschlagewerk: Häufige Dateiformate mit Endung, Hex-Signatur und Offset-Position (inklusive Containerformate)

Die folgende Übersicht ordnet verbreitete Dateiformate nach typischer Endung, Hex-Signatur (Magic Number) und Offset-Position. Die Signatur beschreibt Bytefolgen, die an einer festen Stelle im Header stehen. Bei Containerformaten (z. B. ZIP-basierte Office-Dokumente, MP4/QuickTime, Matroska/EBML) hängt die Erkennung zusätzlich von Strukturmerkmalen ab; dort genügt eine einzelne Magic Number oft nicht, um Inhalt und Typ eindeutig zu bestimmen.

Binäre Signaturen: Hinweise zur Interpretation

Hexwerte werden als Bytefolge gelesen, beispielsweise 89 50 4E 47 0D 0A 1A 0A. Der Offset ist in der Regel dezimal angegeben und beginnt bei 0 (erstes Byte der Datei). Einige Formate haben mehrere gültige Signaturen oder Varianten, etwa durch unterschiedliche Marker (z. B. JPEG) oder durch Containerboxen, deren Reihenfolge variieren kann (z. B. ISO Base Media). In solchen Fällen gelten zusätzliche Prüfregeln wie „Signatur am Offset 0, plus Strukturprüfung im weiteren Header“.

Tabelle: Häufige Formate (Header-Signatur und Offset)

Containerformate: Signatur reicht nicht, Struktur entscheidet

Container bündeln Datenströme oder mehrere Dateien. Eine ZIP-Signatur am Offset 0 belegt zunächst nur „ZIP-kompatibel“; ein .docx unterscheidet sich von einem beliebigen ZIP-Archiv durch definierte Verzeichnisstrukturen und XML-Teile. Ähnlich verhält es sich bei RIFF (WAV/AVI), ISO Base Media (MP4/MOV) oder EBML (MKV/WebM): Der Containerheader ist eindeutig, der tatsächliche Inhaltstyp ergibt sich erst aus Marken/Boxen/Elementen im Inneren.

Praktische Prüfmethoden (ohne Vollanalyse)

• Hexdump (erste Bytes): xxd -g 1 -l 64 -- datei.bin
hexdump -C -n 64 datei.bin
• Signaturabgleich und „Best Guess“: file -b --mime-type -- datei.bin
file -b --extension -- datei.bin
• Gezieltes Lesen am Offset (Linux): dd if=datei.bin bs=1 skip=4 count=16 2>/dev/null | xxd -g 1
• Gezieltes Lesen am Offset (Windows PowerShell): $fs=[IO.File]::OpenRead("datei.bin"); $fs.Seek(4,[IO.SeekOrigin]::Begin)|Out-Null; $b=New-Object byte[] 16; $fs.Read($b,0,16)|Out-Null; $fs.Close(); ($b|ForEach-Object { $_.ToString("X2") }) -join " "
• Container-Inspektion ZIP ohne Extraktion: zipinfo -1 -- datei.zip
7z l -ba -- datei.docx
• MP4/QuickTime-Header prüfen: ffprobe -v error -show_format -show_streams -- datei.mp4
• Archivsignatur vs. tatsächliche Nutzlast: binwalk --signature --quiet -- datei.bin

Typische Stolperstellen bei Endung und Signatur

Dateiendungen lassen sich trivial ändern und eignen sich nur als Metadatum. In der Praxis treten Mischformen auf: Dateien mit gültiger Signatur, aber manipulierten Folgefeldern; oder polyglotte Dateien, die mehrere Parser akzeptieren (beispielsweise HTML/JS mit eingebetteten Daten, oder Bilddateien mit angehängten Archiven). Für belastbare Zuordnung sollten mindestens zwei Kriterien erfüllt sein: korrekte Signatur an erwarteter Position und eine plausibel konsistente Struktur (Chunks/Boxen/Directory, Längenfelder, CRC/Checksummen, Abschlussmarker).

Praxis und Sicherheit: Prüfmethoden, Tooling und Erkennung manipulierter Endungen sowie gängiger Malware-Tarntechniken

In operativen Umgebungen entscheidet selten die Dateiendung über das tatsächliche Risiko, sondern der Inhalt. Dateisignaturen (Magic Numbers) liefern dafür einen robusten, binär überprüfbaren Anker. Dennoch bleiben Randfälle: Containerformate, Dateien mit führenden Nullen, mehrteilige Signaturen, verschachtelte Archive oder bewusst manipulierte Header. Verlässliche Prüfmethoden kombinieren deshalb mehrere Perspektiven: Headerprüfung, Plausibilitätschecks der internen Struktur, Kontextinformationen (Quelle, Transportweg, Metadaten) sowie sicherheitsorientierte Ausführungskontrollen.

Prüfmethoden in der Praxis: mehrstufig statt „Endung prüfen“

Ein praxisnaher Ablauf beginnt mit einer schnellen Klassifikation anhand der ersten Bytes (und relevanter Offsets), gefolgt von einer Validierung der Formatstruktur. Bei ZIP-basierten Formaten (z. B. Office Open XML) reicht 50 4B 03 04 am Anfang nicht aus, weil sowohl harmlose Dokumente als auch ausführbare Inhalte (z. B. verschachtelte Skripte in Archiven) als ZIP erscheinen. Ergänzend sollten zentrale Verzeichnisstrukturen, erwartete Dateien (z. B. [Content_Types].xml) und Größen-/Offset-Konsistenzen geprüft werden. Ähnlich gilt bei PDF: Ein %PDF--Header ist hilfreich, aber nicht hinreichend; entscheidend sind auch Cross-Reference-Strukturen, Objekt-Streams und auffällige Inhalte wie eingebettete Dateien oder JavaScript-Aktionen.

Für sicherheitsrelevante Entscheidungen empfiehlt sich eine „Trust-minimierende“ Behandlung: Ein unbekanntes oder nur teilweise plausibles Format bleibt bis zur abschließenden Bewertung potenziell gefährlich. Das betrifft insbesondere Dateien, die aus E-Mail-Anhängen, Chat-Plattformen, Download-Portalen oder Wechseldatenträgern stammen, sowie Inhalte mit doppelten Endungen oder unüblichen Namen.

• Header- und Offset-Prüfung: Erste Bytes und gegebenenfalls weitere Marker an festen Positionen lesen, z. B. unter Linux/Unix xxd -g 1 -l 64 -- datei.bin oder hexdump -C -n 64 datei.bin.
• Erkennung über Dateityp-Datenbanken: Mimetyp-/Magic-DB nutzen, z. B. file -b --mime-type -- datei und ergänzend file -b --extension -- datei (falls verfügbar), um Anomalien zwischen Signatur und Inhalt sichtbar zu machen.
• Strukturvalidierung statt „Signatur passt“: Parser/Validatoren einsetzen, z. B. pdfinfo datei.pdf (Poppler), qpdf --check datei.pdf oder 7z t datei.zip, um Inkonsistenzen, kaputte Verzeichnisse und ungewöhnliche Einbettungen zu erkennen.
• Extraktion in Quarantäne: Inhalte nur in isolierter Umgebung entpacken, z. B. 7z x -y -o./extract -- datei und Pfad-Traversal-Indikatoren (../, absolute Pfade) im Ergebnis prüfen.
• Hashing und Wiedererkennung: Vor jeder Weitergabe Hashes bilden, z. b. sha256sum datei oder unter Windows Get-FileHash -Algorithm SHA256 .\datei, um spätere Abweichungen und Manipulationen zu belegen.

Tooling nach Plattform: schnelle Checks und tiefe Analyse

Für die tägliche Arbeit reichen oft kleine, deterministische Werkzeuge: Hexdump für die ersten Bytes, ein „Magic“-Resolver (z. B. file) und ein Format-spezifischer Checker (z. B. qpdf für PDF). Für tiefergehende Analysen unbekannter Dateien kommen Dissectoren und Container-Parser hinzu. Bei Windows-Dateien ist außerdem zu unterscheiden, ob eine Datei vom Explorer als ausführbar behandelt wird (PE/COFF) oder ob ein Script/Shortcut indirekt Ausführung auslöst (LNK, URL, HTA, JavaScript, PowerShell).

Bei Windows sollten zusätzlich Alternate Data Streams (ADS) und Mark-of-the-Web (MOTW) berücksichtigt werden, weil sie die Ausführungsentscheidung und SmartScreen/Office-Schutzmechanismen beeinflussen können. ADS lassen sich prüfen, ohne den Inhalt zu öffnen, etwa mit dir /r oder PowerShell Get-Item -Stream *. Der MOTW-Stream ist typischerweise Zone.Identifier; eine fehlende Markierung bei „Internet-Dateien“ kann auf ungewöhnliche Transferpfade oder bewusste Entfernung hindeuten.

Manipulierte Endungen und Doppel-Erweiterungen: typische Muster

Manipulationen zielen häufig darauf, visuelle oder prozessuale Filter zu umgehen. Die simpelste Variante ist das Umbenennen: ausführbare Inhalte erhalten harmlose Endungen (.jpg, .pdf), während die Magic Number weiterhin auf ein PE, ein Script oder ein Archiv verweist. Häufiger sind Kombinationsmuster: Doppelerweiterungen wie rechnung.pdf.exe, Unicode-/RTL-Steuerzeichen im Dateinamen zur visuellen Umkehr, oder sehr lange Namen, die relevante Endungen in UI-Ansichten abschneiden. Auch „Polyglots“ kommen vor: Dateien, die von mehreren Parsern akzeptiert werden (z. B. Bilddatei mit angehängtem Archiv), wobei die tatsächliche Wirkung vom konsumierenden Programm abhängt.

• Doppelte Endung: Sichtprüfung ersetzt keine Headerprüfung; automatisiert erkennbar über Muster wie *.pdf.exe oder *.docm.zip und Abgleich mit file --mime-type.
• Verdeckte Erweiterung durch RTL/Unicode: Dateinamen können Steuerzeichen enthalten; unter Windows liefert PowerShell Details über [int][char]-Codes, z. B. $n="datei"; $n.ToCharArray() | % {[int]$_} (für forensische Sichtung in kontrollierter Umgebung).
• Mehrdeutige Container: ZIP-basierte Formate unterscheiden sich erst über Inhalte; prüfen mit 7z l und gezielt nach erwarteten Pfaden suchen, z. B. word/document.xml, xl/workbook.xml, [Content_Types].xml.
• Angehängte Payload („Append“): Viele Parser ignorieren Daten nach dem formalen Ende; Indikator sind unerwartete „Trailing Bytes“, sichtbar über Größenvergleich und Suchen nach sekundären Signaturen, z. B. grep -aob "PK\x03\x04" datei.

Gängige Malware-Tarntechniken im Dateiformat-Kontext

Malware nutzt Dateitypen, die in Arbeitsabläufen plausibel wirken und dennoch Codeausführung ermöglichen oder nachladen. Dazu gehören LNK-Dateien, die per Shortcut Kommandos starten, Script-Dateien (JS/VBS/PS1), HTML-Anwendungen (HTA) sowie Office-Dokumente mit Makros oder Template-Injection. Ein häufiger Pfad führt über Archive: Ein scheinbar harmloses .zip enthält eine LNK oder ein Script; das äußere Format passiert Filter, der innere Inhalt triggert Ausführung. Auch ISO/VHD/VHDX-Images werden als Container missbraucht, weil sie Datei- und MotW-Semantik in manchen Ketten verändern können.

Für die Erkennung sind drei Prüfprinzipien besonders wirksam: erstens die konsequente Header- und Strukturprüfung jeder eingebetteten Datei nach dem Entpacken; zweitens die Bewertung von „ausführbaren“ Dateitypen unabhängig von der äußeren Verpackung; drittens die Korrelation mit Kontextsignalen wie Herkunftszone (MOTW), unerwarteten Icon-/Name-Kombinationen oder ungewöhnlichen Dateipfaden in Shortcuts. In sicherheitskritischen Workflows sollte die Verarbeitung unbekannter Dateien in einer isolierten Umgebung erfolgen, mit deaktivierter automatischer Ausführung von Inhalten und restriktiven Dateityp-Policies.