Как определить используемый упаковщик по сигнатурам в заголовке PE-файла

Как определить используемый упаковщик по сигнатурам в заголовке PE-файла

Ты работаешь с исполняемыми файлами — может, анализируешь вредоносное ПО, проверяешь лицензионность софта или просто хочешь понять, кто упаковал программу, чтобы избежать ложных срабатываний антивируса. Ты открываешь файл в хекс-редакторе, смотришь на заголовок PE — и видишь странные последовательности байтов. Что они значат? Кто их оставил? Это не случайный мусор. Это следы упаковщика.

Упаковщики — это инструменты, которые сжимают и шифруют исполняемый код, чтобы уменьшить размер файла, скрыть его от анализа или защитить от обратной разработки. Но они не умеют полностью исчезать. Оставляют следы. И если ты знаешь, где искать, эти следы — как отпечатки пальцев. Ты можешь точно сказать: «Это UPX», «Это Themida», или «Это кастомный упаковщик, который не встречался раньше».

В этой статье — только то, что нужно, чтобы определить упаковщик по сигнатурам в PE-заголовке. Без теории про архитектуру Windows, без обсуждения анти-анализа. Только конкретные байты, где их искать и что они значат.

Где искать сигнатуры — и почему именно там

PE-файл начинается с заголовка DOS, за ним — PE-заголовок. Внутри PE-заголовка есть разделы — секции. Их структура описана в IMAGE_SECTION_HEADER. Именно в этих заголовках секций чаще всего прячутся сигнатуры упаковщиков.

Почему именно там? Потому что упаковщик:

• заменяет оригинальный код на свой загрузчик;
• добавляет новые секции — например, .text становится .upx1 или .packed;
• меняет имена секций, чтобы сбить с толку анализаторы;
• пишет в начало новой секции уникальный набор байтов — сигнатуру.

Ты не ищешь сигнатуры в самом начале файла — там DOS-заголовок и MZ-подпись. И не в конечных данных — там может быть ресурсы или цифровая подпись. Ищи в именах секций и в первых 16–32 байтах первых новых секций.

Сигнатуры популярных упаковщиков — таблица

Вот что реально встречается на практике. Не теоретические примеры из статей 2010 года — а то, что ты увидишь сегодня в реальных файлах. Сигнатуры даны в виде HEX-строк, как ты их увидишь в хекс-редакторе. Начинаются они сразу после начала секции — в поле PointerToRawData или в первых байтах секции.

Запомни: имя секции — это только подсказка. Сигнатура — это доказательство. Упаковщик может переименовать секцию в .data, но сигнатура останется. И наоборот — имя .upx1 может быть подделано. Поэтому всегда проверяй и то, и другое.

Как искать — пошагово

Вот как ты действуешь на практике. Не теория — шаг за шагом, как делают на реальных инцидентах.

1. Открой файл в хекс-редакторе (HxD, HexFiend, 010 Editor — неважно, главное, чтобы показывал PE-структуру).
2. Найди сигнатуру 50 45 00 00 — это начало PE-заголовка. Сдвинься на 0x18 от неё — там будет NumberOfSections. Запомни это число.
3. Сдвинься на 0x18 + 0x10 + (0x28 * NumberOfSections) — ты окажешься в начале секций. Каждая секция занимает 0x28 байт.
4. Посмотри на первые 8 байт каждой секции — это имя секции. Ищи нестандартные имена: .upx, .packed, .enigma, .aspack.
5. Если имя стандартное (.text, .data), не пропускай её. Перейди к первым 32 байтам этой секции — в них может быть сигнатура.
6. Сравни байты с таблицей выше. Если нашёл совпадение — упаковщик определён.
7. Если ничего не нашёл — проверь смещение 0x100–0x300 от начала файла. Иногда сигнатуры пишут туда, особенно в кастомных упаковщиках.

Пример: ты видишь секцию с именем .text, но в первых 4 байтах — 55 50 58 00. Это UPX. Даже если имя секции стандартное — сигнатура говорит правду.

Что делать, если сигнатуры нет?

Бывает. Особенно в кастомных упаковщиках или если файл был упакован несколько раз. Тогда ты переходишь на следующий уровень анализа.

• Смотри на размеры секций. UPX часто создаёт секции размером 0x1000–0x4000 байт. Themida — 0x2000–0x8000. Если одна секция занимает 90% всего файла — это почти всегда упакованный код.
• Проверь RVA и размеры. В нормальном PE-файле размеры секций логичны. Если VirtualSize в 10 раз больше SizeOfRawData — это признак упаковки.
• Ищи необычные импорты. UPX и ASpack часто добавляют импорт kernel32.dll с функциями вроде VirtualAlloc, VirtualProtect — для распаковки в памяти.
• Проверь начальную точку входа (OEP). Если она указывает на середину секции, а не на начало — это почти всегда упаковщик. Настоящий OEP обычно в начале .text.

Если ты всё это проверил — и ничего не подтвердилось — вероятно, это кастомный упаковщик. Тогда тебе нужно собрать его поведение: как он распаковывается, какие API вызывает, как меняет память. Но это уже другая задача — и она требует отладчика.

Частые ошибки — и как их избежать

Люди, которые только начинают, делают одни и те же ошибки. Вот самые опасные.

• Доверяют только имени секции. Секция может называться .text, но внутри — UPX. Проверяй байты, а не имена.
• Ищут сигнатуры в начале файла. UPX-сигнатура 55 50 58 не в начале. Она в начале новой секции. Если ты смотришь только на первые 100 байт — пропускаешь всё.
• Считают, что если сигнатуры нет — упаковщика нет. Нет сигнатуры — значит, упаковщик не из списка. Не значит, что его нет.
• Путают сигнатуры с кодом распаковки. Внутри секции может быть код, который выглядит как сигнатура — но это просто случайные байты. Сравнивай с известными шаблонами, а не с любым подозрительным набором.
• Игнорируют размеры и RVA. Если секция 0x100000 байт, а файл — 0x120000 — это почти всегда упаковка. Не жди сигнатуры, если структура выглядит подозрительно.

Что выбрать — в зависимости от ситуации

Ты не всегда хочешь знать, что за упаковщик. Ты хочешь понять: безопасно ли это? Нужно ли его анализировать глубже?

• Если ты анализируешь подозрительный файл (вредоносное ПО):
  — Если нашёл Themida или WinLicense — это почти всегда вредонос. Они дорогие, используются в APT и киберпреступности.
  — Если UPX — не всегда плохо. Многие легальные программы упаковывают UPX. Но если файл маленький, а поведение агрессивное — это подозрительно.
• Если ты проверяешь софт от компании:
  — Если это Enigma Virtual Box — скорее всего, это легальный инструмент для упаковки .NET-приложений.
  — Если это ASPack — старый, но безопасный. Часто используется в старых программах.
• Если ты разрабатываешь программу и хочешь упаковать её:
  — Используй UPX. Он открытый, легальный, не оставляет следов, которые вызывают ложные срабатывания.
  — Не используй Themida или WinLicense — они вызывают флаги у антивирусов даже у легального ПО.
• Если ты видишь неизвестную сигнатуру:
  — Запомни байты. Сравни с базами в VirusTotal или Any.Run.
  — Если файл запускается и не делает ничего подозрительного — возможно, это кастомный упаковщик для внутреннего использования.
  — Если он вызывает подозрения — не запускай его. Ищи другие признаки вредоносности.

Как лучше делать — рекомендации

• Создай себе локальную базу сигнатур. Сохраняй в текстовом файле: UPX: 55 50 58 00, Themida: 54 68 65 6D 69 64 61 — и копируй её в хекс-редакторе. Это сэкономит тебе часы.
• Используй PEiD или Detect It Easy — но не как основной инструмент. Они часто ошибаются. Используй их как подсказку, а потом проверяй вручную.
• Если ты работаешь с тысячами файлов — напиши простой скрипт на Python с pefile. Он будет искать сигнатуры автоматически. Это быстрее, чем открывать каждый файл вручную.
• Не полагайся на антивирус. Он может не распознать упаковщик, но поставить флаг «подозрительно». Ты должен понимать, почему.
• Всегда сравнивай с оригинальным файлом. Если ты знаешь, как выглядел файл до упаковки — ты сразу увидишь изменения.

Итог — что делать прямо сейчас

Если ты открыл PE-файл и хочешь понять, кто его упаковал — сделай так:

1. Найди начало секций (после PE-заголовка).
2. Проверь имена секций — ищи .upx, .aspack, .enigma и т.д.
3. Если имена стандартные — смотри первые 32 байта каждой секции. Сравни с таблицей.
4. Если нашёл совпадение — упаковщик определён. Запомни его.
5. Если не нашёл — смотри на размеры, RVA, импорты и точку входа. Подозрительная структура = упаковка, даже без сигнатуры.
6. Не доверяй именам. Доверяй байтам.

Сигнатуры — это не магия. Это следы. И ты — детектив, который умеет читать эти следы. С каждым файлом ты становишься лучше. Не гонись за сложными инструментами. Просто смотри на байты — и ты увидишь то, что другие пропускают.

Информация в этой статье носит ознакомительный характер. Анализ исполняемых файлов может быть связан с юридическими и этическими рисками. Всегда действуй в рамках закона и с разрешения владельца ПО.