Определение типа файла по magic bytes: руководство для forensics CTF тасков

Определение типа файла по magic bytes: руководство для forensics CTF тасков

На forensics-таске CTF попался файл размером 2 МБ без расширения. file вернул лаконичное «data». Binwalk промолчал. Открываю hex-редактор — первые восемь байтов забиты нулями. Кто-то их затёр намеренно. Определение типа файла по magic bytes вручную заняло три минуты: строка IHDR на смещении 0x0C однозначно указала на PNG с убитым заголовком. Две правки в hex-редакторе — и восстановленное изображение содержало флаг.

Ситуация типичная и для CTF, и для реальной форензики. Расширение удалено, подменено или вовсе отсутствует. Файловая система разрушена. Единственный надёжный способ идентификации — анализ бинарных форматов файлов по сигнатурам прямо в hex-дампе.

Что такое magic bytes и почему расширение ничего не значит

Magic bytes (магические байты) — фиксированная последовательность байтов в начале файла, которая однозначно идентифицирует формат. Windows полагается на расширение: переименуй .exe в .jpg — проводник покажет иконку картинки и даже не подавится. Linux-команда file работает иначе — она читает хедер файла и сверяет первые байты с базой известных сигнатур. Подробнее — в нашем материале про расследование кибератаки.

В forensics CTF тасках расширение — бесполезная информация. Атакующие намеренно подменяют расширение или заголовок, чтобы скрыть содержимое. В классификации MITRE ATT&CK это Masquerade File Type (T1036.008, Defense Evasion). Рядом стоит Binary Padding (T1009) — добавление мусорных байтов для изменения хеша. Обе техники разбиваются одним навыком: чтением magic bytes напрямую из бинарного потока.

Сигнатуры файлов — таблица для forensics-тасков

Справочник сигнатур, которые встречаются на CTF и в реальных forensics-кейсах чаще всего. Значения — из спецификаций форматов и Gary Kessler's File Signatures Table (стандартный ресурс в цифровой форензике).

Формат	Magic bytes (hex)	ASCII	Смещение	Footer
PNG	89 50 4E 47 0D 0A 1A 0A	.PNG....	0	49 45 4E 44 AE 42 60 82
JPEG/JFIF	FF D8 FF E0	....	0	FF D9

Примечание: общий маркер начала JPEG — FF D8 FF, третий байт (APPn) варьируется. Формат JFIF/EXIF определяется по строке JFIF\0 или Exif\0 внутри соответствующего сегмента APP0/APP1.

| JPEG/EXIF | FF D8 FF E1 | .... | 0 | FF D9 | | GIF89a | 47 49 46 38 39 61 | GIF89a | 0 | 00 3B | | PDF | 25 50 44 46 2D | %PDF- | 0 | %%EOF | | ZIP | 50 4B 03 04 | PK.. | 0 | 50 4B 05 06 | | RAR4 | 52 61 72 21 1A 07 00 | Rar!... | 0 | Нет | | RAR5 | 52 61 72 21 1A 07 01 00 | Rar!.... | 0 | Нет | | 7z | 37 7A BC AF 27 1C | 7z.... | 0 | Нет | | ELF | 7F 45 4C 46 | .ELF | 0 | Нет | | PE (EXE/DLL) | 4D 5A | MZ | 0 | Нет | | SQLite | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | SQLite format 3 | 0 | Нет | | GZIP | 1F 8B | .. | 0 | Нет | | BMP | 42 4D | BM | 0 | Нет | | FLAC | 66 4C 61 43 | fLaC | 0 | Нет |

Форматы с известным footer (PNG, JPEG, ZIP, GIF, PDF) позволяют выполнять signature-based file recovery — carving по паре «header + footer». Форматы без footer требуют указания максимального размера при carving или разбора внутренней структуры бинарного формата.

Сигнатура PE-файла 4D 5A — всего два байта. Слабая: случайное совпадение вполне вероятно. На практике file и binwalk дополнительно проверяют заголовок PE\0\0 по смещению из DOS-стаба (e_lfanew), что делает итоговую идентификацию надёжной. Сигнатура SQLite (SQLite format 3\0) — 16 байт читаемого ASCII: длинная, уникальная, ложных срабатываний не бывает. Belkasoft в документации по carving прямо говорит: хорошая сигнатура должна быть достаточно длинной и константной — иначе инструменты завалят вас false positive.

Быстрая идентификация: file, binwalk и hex-редактор для форензики

Утилита file — первая линия

file mystery_file — первое, что запускаешь. Она читает magic bytes и выдаёт что-то вроде PNG image data, 800 x 600, 8-bit/color RGBA. Вариант file -b --mime-type mystery_file вернёт только MIME-тип — удобно для скриптов. Если file возвращает «data» — файл повреждён, обфусцирован или содержит нестандартный формат. Тут начинается настоящая работа.

binwalk — анализ файлов со вложенными данными

Binwalk ищет все известные сигнатуры по всему содержимому файла, а не только в начале. Для стеганографии и forensics CTF тасков, где внутри одного файла спрятан другой — незаменимая штука.

binwalk mystery_file покажет список найденных сигнатур с их смещениями. binwalk -e mystery_file автоматически вырежет все найденные объекты в отдельную директорию. Типичный CTF-сценарий: внутри PNG-картинки на смещении 0x1A3F0 обнаруживается ZIP-архив. Binwalk находит сигнатуру 50 4B 03 04, вырезает архив, внутри — текстовый файл с флагом. Классика жанра.

Ещё одна полезная вещь — анализ энтропии через binwalk -E mystery_file. Если участок файла показывает энтропию, близкую к 1.0, — данные зашифрованы или сжаты. Это помогает обнаружить payload, обфусцированный через Encrypted/Encoded File (T1027.013, Defense Evasion по MITRE ATT&CK).

Hex-редактор — когда автоматика бессильна

Когда file и binwalk молчат, открывайте файл напрямую. Для быстрого просмотра — xxd mystery_file | head -20 в терминале. Для полноценной работы — HxD (Windows), 010 Editor (кросс-платформенный) или hexedit в терминале. Вот как выглядит хедер валидного PNG в hex-дампе:

Offset    00 01 02 03 04 05 06 07   ASCII
00000000  89 50 4E 47 0D 0A 1A 0A   .PNG....
00000008  00 00 00 0D 49 48 44 52   ....IHDR
00000010  00 00 03 20 00 00 02 58   ... ...X

Первые 8 байт — сигнатура PNG. Байт 89 предотвращает интерпретацию файла как текста. Пара 0D 0A (CR LF) и одиночный 0A (LF) — индикаторы повреждения при передаче в текстовом режиме: если они изменились, файл испорчен. Дальше идёт чанк IHDR: 00 00 00 0D — длина данных (13 байт), 49 48 44 52 — тип чанка в ASCII. Побайтовый разбор структуры бинарного формата — единственный способ определить тип, когда magic bytes повреждены частично.

File carving forensics: восстановление файлов из сырых данных

File carving — техника извлечения файлов из образа диска или дампа памяти без опоры на файловую систему. Инструмент сканирует поток байтов, ищет известные header и footer, вырезает всё между ними. NIST Computer Forensics Tools Catalog описывает это как «searching for and reconstructing files based on content, rather than file system metadata».

foremost и scalpel для signature-based file recovery

Foremost — классика file carving. foremost -i disk.dd -o recovered/ сканирует образ диска и раскладывает найденные файлы по папкам: jpg/, png/, pdf/, zip/. Конфигурация сигнатур живёт в /etc/foremost.conf — туда можно добавить кастомные правила.

Scalpel — форк foremost с более гибкой настройкой. Конфиг /etc/scalpel/scalpel.conf содержит закомментированные правила для десятков форматов. Раскомментируйте нужные строки и укажите header, footer и максимальный размер файла. Пример строки для JPEG: jpg y 20000000 \xff\xd8\xff\xe0 \xff\xd9 (в header не стоит фиксировать байты длины сегмента APP0 — отсечёте валидные JPEG с другой длиной) — где y указывает на case-sensitive поиск, 20000000 — лимит 20 МБ.

PhotoRec работает с сотнями форматов «из коробки» и не требует ручной настройки. Для массового восстановления данных после повреждения образа — самое то. Но для кастомных или обфусцированных форматов он менее гибок.

Когда file carving не работает

У carving есть чёткие ограничения, и о них лучше знать заранее:

• SSD с включённым TRIM — контроллер физически обнуляет блоки после удаления. Данных для восстановления просто нет.
• Полнодисковое шифрование — без ключа содержимое выглядит как случайный шум. Сигнатуры не обнаруживаются, carving бесполезен.
• Сильная фрагментация — если файл разбит на десятки несмежных кластеров, header/footer carving соберёт только первый фрагмент. Belkasoft подтверждает: contiguous-данные восстанавливаются хорошо, а фрагментированные при простом signature-based подходе — практически нет.

Восстановление повреждённых файлов: ремонт хедеров вручную

Восстановление повреждённых файлов в CTF обычно сводится к одному из трёх сценариев: стёрты первые N байтов, подменена сигнатура или повреждён контрольный чанк. Алгоритм одинаков для любого формата.

Шаг 1 — определите формат. Ищите характерные строки внутри файла: IHDR/IDAT/IEND указывают на PNG, JFIF/Exif — на JPEG, PK — на ZIP. Команда strings mystery_file | grep -iE 'ihdr|jfif|pk|%pdf' ускоряет поиск.

Шаг 2 — сравните первые байты с эталонной сигнатурой из таблицы выше.

Шаг 3 — исправьте повреждённые байты в hex-редакторе. В HxD или hexedit перейдите на нужное смещение, введите правильные значения, сохраните.

Конкретный пример — файл, где file говорит «data», но strings показывает IHDR:

До:    00 00 00 00 00 00 00 00  00 00 00 0D 49 48 44 52
После: 89 50 4E 47 0D 0A 1A 0A  00 00 00 0D 49 48 44 52

Восемь нулевых байтов заменены на стандартную PNG-сигнатуру. После сохранения файл открывается в любом вьювере. На CTF CyberSkyline аналогичный таск решался тем же способом: JPEG с подменённым последним байтом сигнатуры (0D вместо 01) не открывался, пока его не привели к стандарту FF D8 FF E0 00 10 4A 46 49 46 00 01.

Для JPEG ситуация аналогична: если внутри файла есть строка JFIF — первые байты должны быть FF D8 FF E0. Для ZIP ищите PK и восстанавливайте четырёхбайтовый заголовок 50 4B 03 04.

Автоматизация проверки сигнатур на Python

Когда файлов десятки, ручная проверка непрактична. Минимальный скрипт для определения типа файла по magic bytes:

import sys
SIGS = {b'\x89PNG\r\n\x1a\n': 'PNG', b'\xff\xd8\xff': 'JPEG',
        b'%PDF': 'PDF', b'PK\x03\x04': 'ZIP', b'\x7fELF': 'ELF',
        b'MZ': 'PE', b'Rar!\x1a\x07': 'RAR', b'SQLite format 3\x00': 'SQLite'}
with open(sys.argv[1], 'rb') as f:
    header = f.read(16)
for sig, fmt in SIGS.items():
    if header[:len(sig)] == sig: print(fmt); break
else: print(f'Unknown: {header[:8].hex(" ")}')

Скрипт считывает первые 16 байт и сравнивает с известными сигнатурами. Если совпадений нет — выводит hex как отправную точку для ручного анализа. Словарь SIGS расширяется до нужного количества форматов; в серьёзном проекте его стоит вынести в JSON-файл.

Как атакующие маскируют тип файла: антифорензика по MITRE ATT&CK

В реальной форензике и на продвинутых CTF файлы не просто повреждены — они намеренно обфусцированы. Несколько техник из MITRE ATT&CK, которые стоит уметь распознавать:

Masquerade File Type (T1036.008, Defense Evasion) — подмена расширения или magic bytes. Исполняемый PE-файл маскируется под документ. Определение типа файла по magic bytes разоблачает подмену: внутри «картинки» обнаруживается заголовок 4D 5A. Красивый фантик, а внутри — exe'шник.

Obfuscated Files or Information (T1027, Defense Evasion) — обфускация содержимого. Подтехника Encrypted/Encoded File (T1027.013): payload закодирован XOR или Base64, стандартные сигнатуры не детектятся. При carving такие файлы пропускаются — нужен анализ энтропии через binwalk -E.

Binary Padding (T1009, Defense Evasion) — добавление мусорных байтов к файлу. Меняет хеш и может сместить внутреннюю структуру. Binwalk справляется: он ищет сигнатуры по всему файлу, а не только в первых байтах.

При анализе подозрительного файла из инцидента проверяйте все три вектора последовательно: magic bytes, энтропию, внутреннюю структуру.

Практический чеклист: от неизвестного файла до результата

1. file mystery_file — если ответ не «data», формат определён.
2. binwalk mystery_file — если найдены вложенные сигнатуры, извлечь через binwalk -e.
3. xxd mystery_file | head -20 — сравнить первые байты с таблицей сигнатур.
4. strings mystery_file | grep -iE 'ihdr|jfif|pk|pdf' — если magic bytes повреждены, искать характерные строки внутри файла.
5. Исправить хедер в hex-редакторе, подставив правильные magic bytes.
6. Проверить результат — открыть файл в соответствующем приложении или парсере.

Для образов дисков (.dd, .raw) шаги 1-2 заменяются на foremost -i image.dd -o output/ — инструмент сам просканирует весь образ и разложит восстановленные файлы по директориям.

Большинство forensics CTF тасков среднего уровня решаются этим чеклистом за 5-10 минут. Сложные таски добавляют XOR-шифрование заголовка, кастомные форматы или намеренную фрагментацию — но базовый подход остаётся тем же: найти сигнатуру, понять структуру бинарного формата, восстановить.

Часто слышу, что для forensics-тасков достаточно знать три команды: file, binwalk -e и foremost. На тасках начального уровня — да, работает. На соревнованиях уровня DEF CON или HackTheBox — уже нет. Авторы тасков читают те же туториалы и намеренно делают файлы, которые ломают стандартный пайплайн: кастомные magic bytes, XOR первых 16 байт, подменённый CRC в чанках PNG. Если нет навыка открыть hex-дамп и прочитать структуру бинарного формата побайтово, первое нестандартное задание становится стеной.

Наблюдаю это на CTF регулярно: команда, которая пишет собственные парсеры на Python и знает спецификацию PNG/ZIP/ELF наизусть, решает forensics-категорию в два раза быстрее той, что полагается только на готовые тулзы. Инструменты ускоряют рутину, но понимание структуры делает вас независимым от инструмента. Формат меняется, тулза падает, конфиг не подходит — а байты остаются байтами. Если от CTF-тасков хочется перейти к системному пентесту с пониманием, почему формат устроен именно так — на WAPT в Codeby School эту базу закрывают в лабах с прогрессией от простого к сложному.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «pentest-machines».