Когда пространства, имеющегося в PE-заголовке (или какой-либо другой части файла) оказывается недостаточно для размещения всего X-кода целиком, мы можем попробовать растянуть заголовок на величину, выбранную по своему усмотрению. До тех пор, пока SizeOf Headers не превышает физического смещения первой секции, такая операция осуществляется элементарно (см. «Внедрение в PE-заголовок»), но вот дальше начинаются проблемы, для решения которых приходится кардинально перестраивать структуру подопытного файла. Как минимум необходимо увеличить raw offset всех секций на величину, кратную принятой степени выравнивания, прописанной в поле File Alignment, и физически переместить хвост файла, записав X-код на освободившееся место.

Максимальный размер заголовка равен виртуальному адресу первой секции, что и неудивительно, т.к. заголовок не может перекрываться с содержимым страничного имиджа. Учитывая, что минимальный виртуальный адрес составляет 1000h, а типичный размер заголовка – 300h, мы получаем в свое распоряжение порядка 3 Кб свободного пространства, достаточного для размещения практически любого X-кода.

В крайнем случае можно поместить оставшуюся часть в оверлей. Хитрость заключается в том, что системный загрузчик загружает лишь первые SizeOfHeaders байт заголовка, а остальные (при условии, что они есть) оставляет в оверлее. Мы можем сдвинуть raw offset всех секций хоть на мегабайт, внедрив мегабайт X-кода в заголовок, но в память будет загружено только SizeOf Headers байт, а о загрузке остальных X-код должен позаботиться самостоятельно.

К сожалению, одной лишь коррекции raw offset для сохранения файлу работоспособности может оказаться недостаточно, поскольку многие служебные структуры (например, таблица отладочной информации) привязываются к своему физическому местоположению, которое после раздвижки заголовка неизбежно отнесет в сторону. Правила этикета требуют либо скорректировать все ссылки на абсолютные физические адреса (а для этого мы должны знать формат всех корректируемых структур, среди которых есть полностью или частично недокументированные – взять хотя бы ту же отладочную информацию), либо отказаться от внедрения, если один или несколько элементов таблицы DATA DIRECTORY содержат нестандартные структуры (ресурсы, таблицы экспорта, импорта и перемещаемых элементов используют только виртуальную адресацию, поэтому ни в какой дополнительной корректировке не нуждаются). Следует также убедиться и в отсутствии оверлеев, поскольку многие из них адресуются относительно начала файла. Проблема в том, что мы не можем надежно отличить настоящий оверлей от мусора, оставленного линкером в конце файла, и потому приходится идти на неоправданно спекулятивные допущения, что все, что занимает меньше одного сектора, – не оверлей. Или же различимыми эвристическими методами пытаться идентифицировать мусор.

Рисунок 10. Подопытный файл и его проекция в память до и после внедрения X-кода путем раздвижки заголовка