Префиксы Base64: как узнать файл по первым символам

Таблица префиксов

Каждая строка проверена кодированием настоящих магических байтов формата. Стабильный префикс здесь означает часть, которая у формата никогда не меняется. Символы после него зависят от остального содержимого файла.

Несколько строк требуют пояснения:

• RIFF сам по себе только контейнер. Название формата лежит в байтах с 8 по 11, а байты с 9 по 11 кодируются в символы с 13-го по 16-й: RUJQ для WebP (EBP), QVZF для WAV (AVE), Vkkg для AVI (VI ). Первая буква названия формата попадает в одну 3-байтную группу с размером файла, поэтому стабильного символа не даёт.
• zlib не имеет единого префикса. Второй байт хранит уровень сжатия: eJ для уровня по умолчанию, eN для уровней с 7 по 9, eF для 2–5, eA для 0 и 1 (так пишет zlib в Python).
• JSON начинается с eyJ, только если первые два символа {" идут без пробела. { "a": 1 } начинается с eyAi, отформатированный { с переводом строки даёт ewo, а массив [ даёт W.
• DER-структуры начинаются с тега SEQUENCE 30, и он всегда даёт M. Двухбайтная длина (30 82) даёт MII, а следующий символ зависит от длины: открытый ключ RSA 2048 начинается с MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA, типичный сертификат с MIIC, MIID или MIIE. Короткие структуры используют однобайтную длину: закрытый ключ Ed25519 начинается с MC4C, открытый ключ P-256 с MFkw.
• Открытые ключи SSH начинаются с 4-байтной длины в big-endian, поэтому блоб начинается с AAAA. Следующие символы кодируют тип ключа: AAAAC3NzaC1lZDI1NTE5 у ssh-ed25519, AAAAB3NzaC1yc2E у ssh-rsa, AAAAE2VjZHNh у ecdsa. Вне SSH череда A означает просто нулевые байты.
• MP3 без тега ID3 начинается сразу с заголовка фрейма. Его биты синхронизации FF Fx дают ведущие //, например //uQ для FF FB 90.
• Base64URL заменяет + и /, поэтому префикс JPEG превращается в _9j_. Остальные префиксы из таблицы не содержат ни одного из этих символов и в обоих алфавитах выглядят одинаково.

Почему префикс стабилен

Base64 работает с группами по 3 байта. Каждая группа из 3 байтов превращается ровно в 4 символа, и эти 4 символа зависят только от этих 3 байтов. Ничего из дальнейшей части файла назад не просачивается. Поэтому если формат всегда начинается с одних и тех же 3 байтов, его Base64 всегда начинается с одних и тех же 4 символов.

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

Если длина фиксированной сигнатуры не кратна 3 байтам, последняя группа смешивает известные биты с битами из остальной части файла. Возьмём 5-байтный %PDF-. Первые 3 байта дают 4 стабильных символа (JVBE). Следующие 2 байта дают ещё 2 (Ri), а седьмой символ смешивает последние 4 бита - с первыми 2 битами цифры версии. Любая цифра начинается с битов 00, поэтому на практике этот символ всегда 0. После JVBERi0 уже видна версия: JVBERi0xLjQ (%PDF-1.4), JVBERi0xLjc (%PDF-1.7), JVBERi0yLjA (%PDF-2.0).

Сигнатура PNG длиной 8 байт даёт 10 стабильных символов. Одиннадцатый смешивает последний байт сигнатуры с первым байтом длины фрагмента IHDR, а он всегда равен 0, поэтому iVBORw0KGgo сохраняется. Поскольку за сигнатурой в любом PNG идёт этот фрагмент IHDR, у настоящих PNG общий префикс ещё длиннее: iVBORw0KGgoAAAANSUhEUg.

Когда префикс сдвигается

Префикс работает, только если магические байты стоят со смещением 0, 3, 6 и так далее. Добавьте в начало один байт, и все группы сдвинутся, а символы изменятся полностью:

С 3 лишними байтами выравнивание восстанавливается, и знакомый префикс появляется на 4 символа позже. Типичные причины сдвинутого или пропавшего префикса:

• Метка порядка байтов (BOM). Текст UTF-8 с BOM начинается с 77u/ (EF BB BF). BOM занимает 3 байта, поэтому JSON после него всё равно даёт eyJ: 77u/eyJ…. Текст UTF-16 с BOM начинается с //4 или //5 (little-endian) либо с /v8 (big-endian).
• Текст в UTF-16. Текст в UTF-16LE ставит нулевой байт после каждого ASCII-символа, и получается много A: Hello превращается в SABlAGwAbABvAA==. Так выглядит -EncodedCommand в PowerShell. Используйте декодер PowerShell или Base64 в UTF-16.
• Сжатие или шифрование. Сжатый gzip-ом PNG начинается с H4sI, а у зашифрованного файла узнаваемого префикса нет вовсе.
• Data URI. data:image/png;base64, служит заголовком, Base64 начинается после запятой. Парсер data URI разделит их за вас.
• Переносы строк и пробелы. Байты они не сдвигают, но поиск префикса через startswith не сработает, если строка начинается с перевода строки или кавычки. Сначала обрежьте лишнее или прогоните строку через починку Base64.

Проверка префикса в коде

Можно сравнивать первые символы как строки, но сравнивать декодированные байты надёжнее: магические числа берутся прямо из спецификации каждого формата, и не нужно вычислять, какие символы стабильны. Декодирование первых 12 символов даёт первые 9 байтов, а этого хватает для большинства сигнатур:

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

Инструмент Base64 в файл делает ту же проверку по более длинному списку и показывает превью, если браузер умеет отображать формат. Как 6-битные группы соответствуют символам, рассказано в статье как работает Base64 и показано в таблице алфавита.

Вопросы и ответы