Структурные выравнивания в EXE: почему это важно и как с этим работать

Представьте, что вы передали заказчику готовую программу. Всё работает, но при проверке антивирусом файл «летит» в подозрительные, а на некоторых старых системах он вообще отказывается запускаться, выдавая ошибки чтения. Или вы пытаетесь «ужать» файл, убирая лишние нули из середины, и в итоге ломаете структуру. Скорее всего, проблема кроется в выравнивании секций (Section Alignment).

Это одна из тех тем на стыке реверс-инжиниринга и разработки, которая кажется скучной математикой, пока вы не столкнетесь с реальной задачей: упаковать малварь (или легальный софт) так, чтобы она работала, или понять, почему отладчик показывает не те адреса. В этой статье я объясню, что такое выравнивание, чем отличается файловое от в-memory, и почему их рассинхронизация — верный путь к крашу программы.

Суть проблемы: два мира одного файла

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

В заголовке PE-файла (Portable Executable, формат EXE/DLL в Windows) есть два критических параметра, которые управляют этим процессом:

• FileAlignment — определяет, как секции выравниваются на диске.
• SectionAlignment — определяет, как секции выравниваются в памяти.

Когда вы просто компилируете проект в Visual Studio или Delphi, компилятор сам выставляет эти значения. Обычно FileAlignment равен 512 байтам (или 0x200 в шестнадцатеричной системе), а SectionAlignment — 4096 байтам (0x1000), что соответствует размеру страницы памяти в Windows.

Почему так? Потому что дискам выгодно читать блоками по 512 байт (или 4Кб в современных SSD), а операционной системе выгодно загружать данные в память страницами по 4Кб. Если размер секции не кратен этим числам, система дополняет её «пустотой» (нулями) до нужного размера. Эта пустота и есть паддинг (padding).

Зачем нужно выравнивание: скорость и правила игры

Новички часто спрашивают: «Зачем нам эти нули? Они же занимают место! Давайте уберем их и сделаем файл меньше».

Технически вы можете убрать нули на диске, но тогда загрузчик Windows не сможет корректно разместить секции в памяти. Процессоры x86/x64 работают с памятью наиболее эффективно, когда данные выровнены по границам, кратным степени двойки (4, 8, 16, 4096 байт и т.д.). Если данные «перекошены», процессору приходится делать лишние циклы чтения, что замедляет работу. В худшем случае (на некоторых архитектурах, хотя x86 довольно всеяден) это вызывает исключение (exception) и краш приложения.

Но есть и более важный аспект — карта памяти. Когда Windows загружает EXE-файл, она читает заголовок, смотрит на SectionAlignment и говорит: «Окей, я выделю под эту секцию блок памяти, кратный 4096 байтам, начиная с адреса, кратного 4096».

Если вы вручную отредактируете файл в HEX-редакторе, сдвинете код секции .text на 10 байт назад, чтобы сэкономить место, но не поправите заголовки, загрузчик загрузит данные по старому адресу. А внутри кода будут жестко прописанные адреса (RVA — Relative Virtual Address), которые указывают на переменные в секции .data. Поскольку секция .data тоже сдвинулась (или её размер изменился), программа попытается обратиться по несуществующему адресу. Итог: Access Violation и вылет.

Файловое vs Виртуальное: в чем разница и где подвох

Самая частая ошибка при анализе вредоносного ПО или работе с packer’ами — путаница между физическим размером секции (Raw Size) и виртуальным (Virtual Size).

Давайте разберем на примере. Допустим, у вас есть секция с кодом размером 3000 байт.

На диске (FileAlignment = 512):
Система дополнит 3000 до ближайшего числа, кратного 512. Это 3072 байта (6 * 512). Файл на диске займет 3072 байта под эту секцию.

В памяти (SectionAlignment = 4096):
При загрузке в RAM система выделит под эту секцию 4096 байт (1 страница). Оставшиеся 1096 байт будут просто нулями в конце страницы.

Проблема возникает, когда эти значения не совпадают ожидаемым образом. Например, в упаковщиках (UPX, ASPack и самописных) часто делают трюк: они устанавливают FileAlignment равным SectionAlignment (оба по 0x1000). Зачем? Чтобы не пересчитывать смещения при распаковке. Файл на диске становится больше (так как шаг выравнивания на диске вырос с 512 до 4096), но логика загрузки упрощается: адрес в файле совпадает с адресом в памяти (с точностью до базового адреса загрузки).

Однако, если вы видите файл, где FileAlignment равен 0x200, а SectionAlignment — 0x200, это подозрительно. Стандарт Windows требует, чтобы SectionAlignment был не меньше FileAlignment. Если наоборот — файл, скорее всего, битый или это попытка обхода эвристик антивируса, которая часто приводит к нестабильной работе.

Сравнение сценариев выравнивания

Чтобы вам было проще ориентироваться, я составил таблицу с типичными ситуациями, с которыми вы столкнетесь при анализе или создании EXE.

Как выравнивание влияет на анализ и реверс-инжиниринг

Если вы занимаетесь анализом кода, выравнивание — это ваш компас. Когда вы открываете файл в дизассемблере (IDA Pro, Ghidra, x64dbg), программа считывает заголовки, чтобы построить карту памяти.

Представьте ситуацию: вы видите в дизассемблере, что секция .text заканчивается по адресу 0x401000, а секция .data начинается сразу за ней. Но в HEX-редакторе вы видите, что между ними есть 3000 байт мусора. Почему?

Потому что в памяти (Virtual) секции выровнены по границе 0x1000. А на диске (Raw) они могут быть прижаты плотно друг к другу, если FileAlignment маленький. Если вы попытаетесь сделать дамп памяти (dump) работающей программы и сохранить его как EXE, не исправив выравнивание, вы получите «битый» файл. В дампе из памяти секции будут идти подряд с интервалами в 4Кб. Если записать это на диск без коррекции заголовков (без пересчета SizeOfRawData и PointerToRawData), загрузчик будет искать данные не там, где они лежат.

Практический пример:
Вы дампируете процесс. В памяти секция .rsrc (ресурсы) лежит по адресу 0x405000 и занимает 0x200 байт. Виртуальный размер — 0x1000 (из-за выравнивания).
Чтобы сохранить это на диск корректно, вы должны:
1. Обрезать лишние нули в конце секции (оставить реальные 0x200 байт).
2. Указать в заголовке, что на диске эта секция занимает 0x200 байт (выровненных до 0x200 или 0x1000 в зависимости от FileAlignment).
3. Сдвинуть все последующие секции в файле, чтобы они шли друг за другом без гигантских дыр.

Если этого не сделать, файл будет весить столько же, сколько оперативная память процесса (десятки мегабайт), вместо пары сотен килобайт.

Частые ошибки при работе с выравниванием

Работая с HEX-редакторами и заголовками PE, легко наломать дров. Вот список граблей, на которые наступают чаще всего:

1. Изменение размера секции без пересчета смещений.
   Вы добавили код в секцию .text, и она выросла на 100 байт. Если новая длина превышает текущий выделенный блок (Raw Size), вы «залезете» на территорию следующей секции. Файл сломается мгновенно. Нужно увеличить SizeOfRawData и сдвинуть все последующие секции в файле.
2. Игнорирование кратности.
   Выставили FileAlignment = 0x200, но секция начинается по смещению 0x205. Загрузчик Windows может отказаться грузить такой файл или загрузить его со сдвигом, что приведет к неверным RVA внутри кода. Все смещения секций (PointerToRawData) должны быть строго кратны FileAlignment.
3. Путаница Virtual Size и Raw Size.
   В заголовке секции есть два размера. VirtualSize — сколько байт реально нужно в памяти. SizeOfRawData — сколько байт занято на диске. Часто SizeOfRawData >= VirtualSize. Если вы сделаете SizeOfRawData меньше VirtualSize, при загрузке в память часть данных просто не дочитается (будут нули), и программа крашнется при обращении к этим данным.
4. Слишком маленькое выравнивание.
   Некоторые пытаются поставить FileAlignment = 1 (байт), чтобы убрать весь паддинг. Теоретически это возможно, но многие инструменты анализа, антивирусы и даже сам загрузчик Windows в строгих режимах считают это аномалией. Лучше держаться стандарта 0x200.

Что выбрать в зависимости от вашей задачи

Стратегия работы с выравниванием зависит от того, что именно вы делаете.

Ситуация 1: Вы разработчик и хотите уменьшить размер дистрибутива

Не трогайте выравнивание вручную. Используйте стандартные средства сжатия (UPX) или настройки линкера. Попытка вручную «вырезать» нули из PE-файла без глубокого понимания структуры приведет к тому, что вы потратите часы на отладку крашей. Современные компиляторы уже достаточно умны, чтобы не раздувать файл без нужды.

Ситуация 2: Вы реверс-инженер и «дампите» память

Вам нужно привести файл в «дисковое» состояние. После снятия дампа из памяти обязательно используйте инструменты вроде LordPE или скрипты для Scyller, которые автоматически пересчитывают заголовки. Они обнулят лишние байты в конце секций (приведут Virtual Size к реальному используемому) и пересчитают смещения, чтобы файл стал валидным EXE.

Ситуация 3: Вы пишете малварь или протектор (теоретический аспект)

Изменение выравнивания — популярный метод обхода сигнатурного анализа. Если стандартный файл имеет FileAlignment 0x200, а вы поставите 0x400 или 0x80, хеш файла изменится, и простые эвристики могут пропустить его. Однако помните: слишком экзотические значения (например, 0x7FF) сразу привлекут внимание поведенческих анализаторов как подозрительная аномалия структуры.

Как проверить и исправить выравнивание

Если вы подозреваете проблему с выравниванием, не гадайте. Используйте инструменты:

• CFF Explorer или PE-bear. Откройте файл и посмотрите вкладку NT Headers -> Optional Header. Сравните значения FileAlignment и SectionAlignment.
• Проверьте секции (Section Headers). Убедитесь, что PointerToRawData каждой секции делится на FileAlignment без остатка.
• Убедитесь, что VirtualAddress каждой секции делится на SectionAlignment без остатка.

Если вы видите несоответствия (например, смещение 0x205 при выравнивании 0x200), файл поврежден. Исправить это вручную в HEX-редакторе можно, но это ювелирная работа: нужно сдвигать весь массив данных после ошибки, что меняет все последующие адреса. Проще использовать специализированные утилиты для восстановления заголовков (PE Fixers), если у вас есть исходный валидный дамп.

Итог: золотые правила работы с секциями

Структурные выравнивания — это фундамент, на котором стоит загрузка программы. Ошибки здесь не прощают.

Запомните три главных правила, которые спасут вас от головной боли:

1. Не трогайте выравнивание без крайней нужды. Стандартные 0x200 (диск) и 0x1000 (память) работают везде и всегда.
2. Следите за соотношением. SectionAlignment всегда должен быть больше или равен FileAlignment. Обратное — признак битого файла.
3. При дампе памяти всегда пересчитывайте заголовки. То, что лежит в RAM, не готово к записи на диск «как есть». Ему нужна «упаковка» обратно в файловый формат с правильным паддингом.

Понимание того, как байты перетекают из файла в память, отличает новичка, который тыкает HEX-редактор наугад, от специалиста, который точно знает, почему программа не запускается, и может это исправить за пару минут.

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