Иначе поступает автор статьи «Об упаковщиках в последний раз» (http://www.wasm.ru/print.php?article= packlast01 и http://www.wasm.ru/print.php?article=packers2), сосредоточивший свои усилия на исследовании системного загрузчика W2K/XP и допустивший при этом большое количество фактических ошибок, полный разбор которых потребовал бы отдельной статьи. При всей ценности этой работы она нисколько не проясняет ситуацию и только добавляет вопросов. Автор сетует на то, что работа загрузчика полностью не документирована и даже у Руссиновича обнаруживаются лишь обрывки информации. Ну была бы она документирована – что бы от этого изменилось? Какое нам дело до того, что в W2K/XP загрузка файла сводится к вызову MmCreateSection? Во-первых, в остальных системах это не так, а во-вторых, это сегодня Microsoft стремится весь ввод/вывод делать через mmap, но когда до горячих американских парней дойдет, что это тормоза, а не ускорение, политика изменится, и MmCreateSection отправятся на заслуженный отдых (в чулан ее, на полку!).

Дизассемблировать ядро совсем небесполезно, но вот закладываться на полученные результаты, не проверив их на остальных осях, ни в коем случае нельзя! Верить в спецификации по меньшей мере наивно, ведь всякая спецификация – это только слова, а всякий программный код – лишь частный случай реализации. И то, и другое непостоянно и переменчиво. Чтение книжек (равно как и протирание штанов в учебных заведениях различной степени тяжести) еще никого не сделало программистом. Лишь «опыт, сын ошибок трудных», да общение с коллегами-системщиками, позволят избежать грубых ошибок[1]. Как говорится, не падает только тот, кто лежит, а кто бежит – падает, наступает на грабли и попадает в логические ямы, глубокие, как колодцы из романа Мураками.

Автор, имеющий богатый опыт в работе с PE-файлами и помнящий численные значения смещений всех структур как отче наш, в процессе работы над статьей в такие колодцы попадал неоднократно (да и сейчас там сидит). Всякое значение подобно больному зубу – если его не трогать, он не будет ныть. Отдельные пробелы, неясности и непонятности неизбежны. Когда пишешь рабочие заметки «для себя», просто махаешь рукой и говоришь: да какая разница, что этот большой красный рубильник делает? Работает ведь – и ладно… Статья – дело другое и тут хочешь не хочешь, а будь добр разложить все по полочкам! Автор выражает глубокую признательность удивительному человеку, мудрому программисту и создателю замечательного линкера ulink Юрию Харону (ftp://ftp.styx.cabel.net/pub/UniLink), терпеливо отвечавшему на мои сумбурные и нечетко сформулированные вопросы. Если бы не его консультации, эта статья ни за что бы не получилось такой, какова она есть!

Общие концепции и требования, предъявляемые к PE-файлам

Структурно PE-файл состоит из заголовка (header), страничного имиджа (image page) и необязательного оверлея (overlay). Представление PE-файла в памяти называется его виртуальным образом (virtual image) или просто образом, а на диске – файлом или дисковым образом. Если не оговорено обратное, то под образом всегда понимается виртуальный образ.

Образ характеризуется двумя фундаментальными – адресом базовой загрузки (image base) и размером (image size). При наличии перемещаемой информации (relocation/fixup table) образ может быть загружен по адресу, отличному от image base и назначаемому непосредственно самой операционной системой.