Häufige Base64-Präfixe: eine Datei an ihrem Anfang erkennen

Tabelle der Präfixe

Jede Zeile wurde geprüft, indem die echten Magic Bytes des Formats kodiert wurden. Das „stabile Präfix“ ist der Teil, der sich für dieses Format nie ändert. Die Zeichen danach hängen vom Rest der Datei ab.

Ein paar Zeilen verdienen eine Anmerkung:

• RIFF ist ein Container. Der Formatname steht in den Bytes 8 bis 11, und die Bytes 9 bis 11 werden zum 13. bis 16. Zeichen kodiert: RUJQ für WebP (EBP), QVZF für WAV (AVE), Vkkg für AVI (VI ). Der erste Buchstabe des Formatnamens teilt sich eine 3-Byte-Gruppe mit der Dateigröße und ergibt daher kein stabiles Zeichen.
• zlib hat kein einzelnes Präfix. Das zweite Byte hält die Kompressionsstufe fest: eJ für die Standardstufe, eN für die Stufen 7 bis 9, eF für 2 bis 5, eA für 0 und 1 (so, wie Pythons zlib sie schreibt).
• JSON beginnt nur dann mit eyJ, wenn die ersten beiden Zeichen {" ohne Leerzeichen sind. { "a": 1 } beginnt mit eyAi, formatiertes { plus Zeilenumbruch mit ewo, und ein Array [ mit W.
• DER-Strukturen beginnen mit dem SEQUENCE-Tag 30, das immer M ergibt. Eine Zwei-Byte-Länge (30 82) ergibt MII, und das nächste Zeichen folgt der Länge: Ein RSA-2048-Public-Key ist MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA, ein typisches Zertifikat MIIC, MIID oder MIIE. Kurze Strukturen verwenden eine Ein-Byte-Länge: Ein privater Ed25519-Schlüssel beginnt mit MC4C, ein P-256-Public-Key mit MFkw.
• Öffentliche SSH-Schlüssel beginnen mit einer 4-Byte-Big-Endian-Länge, der Blob startet daher mit AAAA. Die folgenden Zeichen buchstabieren den Schlüsseltyp: AAAAC3NzaC1lZDI1NTE5 ist ssh-ed25519, AAAAB3NzaC1yc2E ist ssh-rsa, AAAAE2VjZHNh ist ecdsa. Außerhalb von SSH bedeutet eine Folge von A einfach Nullbytes.
• MP3-Dateien ohne ID3-Tag beginnen direkt mit einem Frame-Header. Seine Sync-Bits FF Fx ergeben ein führendes //, zum Beispiel //uQ für FF FB 90.
• Base64URL ersetzt + und /, daher wird das JPEG-Präfix zu _9j_. Die übrigen Präfixe in der Tabelle enthalten keines dieser Zeichen und sehen in beiden Alphabeten gleich aus.

Warum das Präfix stabil ist

Base64 arbeitet mit Gruppen von 3 Bytes. Jede Gruppe aus 3 Bytes wird zu genau 4 Zeichen, und diese 4 Zeichen hängen nur von diesen 3 Bytes ab. Nichts aus dem späteren Teil der Datei wirkt nach vorn zurück. Beginnt ein Format also immer mit denselben 3 Bytes, beginnt sein Base64 immer mit denselben 4 Zeichen.

bytes:   FF       D8       FF
bits:    11111111 11011000 11111111
groups:  111111 111101 100011 111111
index:   63     61     35     63
chars:   /      9      j      /

Ist die feste Signatur kein Vielfaches von 3 Bytes lang, mischt die letzte Gruppe bekannte Bits mit Bits aus dem Rest der Datei. Nehmen Sie das 5 Bytes lange %PDF-. Die ersten 3 Bytes ergeben 4 stabile Zeichen (JVBE). Die nächsten 2 Bytes ergeben 2 weitere (Ri), und das siebte Zeichen mischt die letzten 4 Bit von - mit den ersten 2 Bit der Versionsziffer. Jede Ziffer beginnt mit den Bits 00, in der Praxis ist dieses Zeichen also immer 0. Nach JVBERi0 scheint die Version durch: JVBERi0xLjQ ist %PDF-1.4, JVBERi0xLjc ist %PDF-1.7, JVBERi0yLjA ist %PDF-2.0.

Die PNG-Signatur hat 8 Bytes, was 10 stabile Zeichen ergibt. Das elfte mischt das letzte Signaturbyte mit dem ersten Byte der Länge des IHDR-Chunks, das immer 0 ist, daher gilt iVBORw0KGgo. Da jedes PNG mit diesem IHDR-Chunk weitergeht, teilen echte PNGs sogar ein noch längeres Präfix: iVBORw0KGgoAAAANSUhEUg.

Wenn sich das Präfix verschiebt

Das Präfix funktioniert nur, wenn die Magic Bytes an Position 0, 3, 6 und so weiter stehen. Ein Byte davor verschiebt jede Gruppe, und die Zeichen ändern sich vollständig:

Mit 3 zusätzlichen Bytes stimmt die Ausrichtung wieder, und das vertraute Präfix taucht 4 Zeichen später auf. Häufige Gründe für ein verschobenes oder fehlendes Präfix:

• Eine Byte-Order-Mark. UTF-8-Text mit BOM beginnt mit 77u/ (EF BB BF). Die BOM hat 3 Bytes, nachfolgendes JSON zeigt also weiterhin eyJ: 77u/eyJ…. UTF-16-Text mit BOM beginnt mit //4 oder //5 (Little-Endian) oder /v8 (Big-Endian).
• UTF-16-Text. Als UTF-16LE gespeicherter Text setzt hinter jedes ASCII-Zeichen ein Nullbyte, was viele A erzeugt: Hello wird zu SABlAGwAbABvAA==. PowerShells -EncodedCommand sieht so aus. Nutzen Sie den PowerShell-Decoder oder Base64 in UTF-16.
• Kompression oder Verschlüsselung. Ein mit gzip komprimiertes PNG beginnt mit H4sI, eine verschlüsselte Datei hat überhaupt kein erkennbares Präfix.
• Eine Data-URI. data:image/png;base64, ist ein Header, das Base64 beginnt nach dem Komma. Der Data-URI-Parser trennt beides für Sie.
• Zeilenumbrüche und Leerraum. Sie verschieben die Bytes nicht, aber eine Präfixsuche mit startswith scheitert, wenn die Zeichenkette mit einem Zeilenumbruch oder einem Anführungszeichen beginnt. Kürzen Sie sie vorher oder schicken Sie sie durch Base64 reparieren.

Ein Präfix im Code prüfen

Man kann die ersten Zeichen als Zeichenketten vergleichen, der Vergleich dekodierter Bytes ist aber weniger fehleranfällig: Die Magic Numbers stammen direkt aus der Spezifikation des jeweiligen Formats, und man muss nie ausrechnen, welche Zeichen stabil sind. Dekodiert man nur die ersten 12 Zeichen, erhält man die ersten 9 Bytes, genug für die meisten Signaturen:

import base64

SIGNATURES = {
    b"\x89PNG\r\n\x1a\n": "png",
    b"\xff\xd8\xff": "jpeg",
    b"%PDF-": "pdf",
    b"PK\x03\x04": "zip",
    b"\x1f\x8b": "gzip",
}

def sniff(b64: str) -> str:
    head = base64.b64decode(b64.strip()[:12])
    for magic, name in SIGNATURES.items():
        if head.startswith(magic):
            return name
    return "unknown"

print(sniff("iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB"))  # png
print(sniff("JVBERi0xLjcKJcfsj6IK"))              # pdf

Das Tool Base64 in Datei führt dieselbe Prüfung mit einer längeren Liste durch und zeigt eine Vorschau, wenn der Browser das Format darstellen kann. Wie die 6-Bit-Gruppen auf Zeichen abgebildet werden, zeigen So funktioniert Base64 und die Alphabet-Tabelle.

Häufige Fragen