Распаковка в учебных целях

Чтобы анализировать упакованный файл, его нужно получить в распакованном виде — разбираем концепцию: OEP, дамп памяти, ручная распаковка на своём бинаре.

Распаковка (unpacking) — получение оригинального, готового к анализу кода программы из упакованного файла: дать stub распаковать образ в память, поймать момент перехода на OEP и снять дамп.

В прошлом уроке мы научились распознавать упаковку. Теперь — что с ней делать аналитику. Раз настоящий код проявляется только в рантайме, логичная идея: запустить программу в контролируемой среде, дождаться, пока stub закончит работу, и зафиксировать память в этот момент. Получится образ, в котором оригинальный код уже распакован и пригоден для дизассемблирования. Рассматриваем это исключительно как учебную процедуру на собственном бинаре в изолированной лаборатории.

Зачем это знать защитнику

Аналитик безопасности (Blue Team, исследователь) обязан уметь добраться до настоящего кода, иначе разбор подозрительного или защищённого ПО невозможен. Понимание распаковки также показывает разработчику реальную ценность упаковки как защиты: она снимается стандартными приёмами, а значит, не должна быть единственным барьером. Тренируются на безопасных образцах: своих программах, специально подготовленных учебных файлах, заданиях CTF и площадок вроде TryHackMe.

Ключевая идея: OEP и дамп памяти

Весь процесс крутится вокруг двух понятий:

OEP (Original Entry Point) — адрес, на который stub передаёт управление, когда распаковка завершена. До OEP исполняется распаковщик; начиная с OEP — оригинальная программа. Поймать OEP значит застать память в момент, когда код уже распакован, но ещё не начал исполняться (или только начал).
Дамп памяти — сохранение содержимого памяти процесса в файл. Если снять дамп в районе OEP, в нём окажется распакованный код. Дамп ещё нужно «починить» (восстановить заголовки и таблицу импортов), чтобы он снова стал корректным анализируемым файлом.

запуск процесса
  -> исполняется stub (распаковка в память)
  -> [ОЭП: переход на оригинальную точку входа]   <- здесь снимаем дамп
  -> исполняется оригинальный код

Концепция ручной распаковки

Обобщённый учебный алгоритм (принцип, не пошаговое оружие) выглядит так:

Запустить под отладчиком в изоляции. Свой бинар открывают в отладчике внутри ВМ. На старте управление у stub.
Найти переход на OEP. Распаковщик заканчивается «дальним прыжком» (tail jump) на распакованный код. Идея — дождаться завершения распаковки и определить адрес, куда уходит управление. У stub есть характерные приёмы (сохранение/восстановление регистров, цикл распаковки), по которым находят финальный переход.
Снять дамп. Остановившись на OEP, фиксируют образ процесса в файл — оригинальный код уже в памяти.
Восстановить импорты и заголовки. В дампе таблица импортов нередко повреждена/неполна; её реконструируют, чтобы файл снова стал валидным и открывался в дизассемблере. Для этого есть вспомогательные инструменты.

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

Частный случай: UPX на своём бинаре

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

# упаковать свой бинарь (демонстрация в лаборатории)
upx -o myapp.packed myapp

# распаковать обратно штатным режимом UPX
upx -d myapp.packed -o myapp.unpacked

Так на безопасном примере видно само явление: до распаковки секции называются UPX0/UPX1 и имеют высокую энтропию, после — возвращаются нормальные секции и читаемый код. Это идеальная учебная демонстрация концепции «упаковка обратима». Авторы вредоносного ПО, конечно, часто намеренно ломают штатную распаковку (меняют заголовки, версии), чтобы upx -d не сработал — и тогда применяют общий подход через дамп памяти, описанный выше. В учебных же целях достаточно своего нетронутого UPX-файла.

Как это работает под капотом

Почему распаковка вообще всегда возможна? Потому что для исполнения процессор должен видеть настоящие инструкции — зашифрованный или сжатый код выполнить нельзя. Значит, в какой-то момент времени оригинальный код обязан появиться в памяти в исходном виде. Этот момент и есть окно для дампа. Никакая упаковка не отменяет данного факта: она лишь усложняет нахождение точного момента и последующую починку дампа. Поэтому распаковка — не «обход защиты» в смысле взлома, а следствие того, как работает выполнение кода.

Как защититься

Что отсюда следует для разработчика и аналитика:

Для защитников: раз код всё равно оказывается в памяти, упаковка не защищает секреты. Не храните ключи и критичную логику в клиенте; держите проверки на сервере. Упаковку используйте как удобство (размер), а не как охрану.
Анти-дамп приёмы существуют (затирание заголовков в памяти, проверка отладчика), но они лишь повышают стоимость и не делают распаковку невозможной — это гонка, а не стена.
Для аналитика: всегда работайте в изолированной ВМ со снапшотами; распаковывайте только свои или явно разрешённые образцы (CTF, учебные стенды).
Инструменты: отладчик для контроля выполнения, средства снятия дампа процесса, утилиты восстановления таблицы импортов — это стандартный набор Blue Team и исследователя.

Распаковка законна на собственных файлах, разрешённых образцах и в учебных лабораториях/CTF. Несанкционированный доступ к чужим системам и работа с чужим вредоносным ПО вне разрешённой среды наказуемы (ст. 272–274 УК РФ).

Итоги

Настоящий код упакованного файла всегда оказывается в памяти при выполнении — это окно для распаковки.
OEP — точка, где stub передаёт управление оригинальной программе; около неё снимают дамп памяти.
Ручная распаковка: запуск под отладчиком в изоляции, поиск перехода на OEP, дамп, восстановление импортов и заголовков.
UPX — обратимый упаковщик: на своём файле распаковывается штатно командой upx -d, что делает его идеальным учебным примером.
Раз код неизбежно появляется в памяти, упаковка не защищает секреты; критичную логику держат на сервере.