Анализ неразрешенных внешних ссылок в объектном файле
Здесь работа будет вестись сравнением файла coff1.bin.rtf (мы называем его «бинарник») и файла coff1.asm.elst («листинг»).
Разметить листинг на секции. Найдите начало каждой секции и отделите ее линией от остального текста. Секционные директивы .code выделите маркером одного цвета, а .data – другого.
Находите в бинарнике образ секции кода – raw data #1. В листинге находите начало первой секции .code.
Сопоставляя их тексты, размечаете рамочками в raw data #1 команды с их операндами. К примеру, в листинге записано:
00000005 8A 15 0000001A R Mov dl, [Str2 + 3] ; J
В бинарнике этой команде соответствует
00000090 … 8A 15 03 00 00 00 …
Здесь желтым отмечены неразрешенные внешняя ссылки. В исходном тексте эта ссылка соответствует операнду [Str2 + 3].
Обращаем внимание, что одна и та же неразрешенная ссылка в листинге записана как число 0000001А, а в объектный файл она попала как число 03000000. Это не ошибка, а следствие разных подходов к отображению неразрешенной ссылки.
Так, макрогенератор в листинге отобразил неразрешенную ссылку как число 0000001A (десятичное 26). Что это? Обратимся к листингу. Найдем в секции данных описание строки Str2. Какой символ стоит в ней со смещением 3? Это ‘J’ и мы можем прочесть рядом его код – 4А. Теперь обратимся к бинарнику. Соединенная секция данных в нем – это Raw Data #2. Найдем в ней байт со смещением 26. Что это? Правильно, 4А, то есть тот же самый символ ‘J’. Так мы установили соответствие – в листинг неразрешенные ссылки записываются как смещения данных в секции Raw Data#2 бинарника.
С другой стороны, в самом бинарнике, в его секции Raw Data #1 (секция кода) неразрешенная ссылка содержит число 3. Сравнение с другими ссылками позволяет сформулировать правильную догадку – это смещение читаемого данного относительно базовой метки. То есть это та же самая «тройка», что и в записи [Str2 + 3].
Выделите маркером одинакового цвета пары соответствующих неразрешенных ссылок в бинарнике и листинге. На этом пока всё.
Примерный вид размеченного дампа показан на рис.4.3.
Рисунок 4.3 – Примерный вид размеченного дампа.
Состав отчета по работе
Номер и название работы, фамилия и группа студента.
Цель работы.
Протокол выполнения работы с текстами ответов на все вопросы в заданиях пункта «Выполнение работы».
Развернутые выводы по работе
Вопросы для самопроверки
Как открыть любой файл как цепочку байтов, не обращая внимания на тип файла?
Что означает термин «reverse engeneering»?
Почему при компиляции возникают неразрешенные внешние ссылки?
Из каких частей состоит объектный файл формата COFF?
Какой цели служит утилита dumpbin?
ИССЛЕДОВАНИЕ ИСПОЛНЯЕМОГО ЕХЕ-МОДУЛЯ
Цель работы
Изучить структуру ехе-модуля формата РЕ, полученного компоновкой объектного COFF-файла. Научиться выполнять под отладчиком программу, полученную из ехе-модуля. Составить карту размещения программы в виртуальной памяти процесса. Установить, какие истинные рабочие значения получили ссылки, которые в предыдущей работе были «неразрешенными».
Теоретические сведения
Исполняемые модули формата РЕ (ехе-файлы)
Формат РЕ (portable executable) является общим форматом исполняемых файлов (исполняемых модулей) компьютерных систем под управлением ОС Windows. (В других операционных системах используются аналогичные по назначению форматы: в Linux формат ELF, в MacOS формат Mach-O). Все они устроены похоже, но отличаются в деталях.)
Формальное описание формата РЕ можно найти в MSDN, а неформальное – в статье Мэтта Пайтрека по ссылке
http://msdn.microsoft.com/en-us/library/ms809762.aspx
Исполняемый файл содержит не программу, а её образ. Для сведения приводим на рис. 5.1 схему РЕ-файла. На рисунке начало файла внизу, смещения растут вверх.
Рисунок 5.1 – Структура исполняемого файла формата РЕ.
Исполняемый РЕ-файл - это строго документированная структура данных, которую читает специальная компонента операционной системы – программный РЕ-загрузчик. Загрузчик на основании данных ехе-файластроит в оперативной памяти программу и сообщает диспетчеру задач ОС адрес точки входа в неё. Далее операционная система организует исполнение программы на общих основаниях.
Программа в оперативной памяти всегда представлена совокупностью видимых в отладчике программных секций (сегментов) кода, данных и стекаи (при необходимости) ряда невидимых служебных секций, которые мы тут не обсуждаем.
В РЕ-файле в самом начале (смещение 00h) располагается «заглушка»MSDOS(DOSstub) , начинающаяся с символов “MZ”. Она нужна при попытке запустить программу в реальном режиме. В этом случае на консоль будет выведено «ThisprogramcannotberuninDOSmode.», после чего программа завершится без ошибки.
По смещению 3ChвDOS-заглушке располагается 4-байтное смещение, по которому в ехе-файле начинаетсяPE-заголовок. Его сигнатура – символы “PE” и два ноль-байта после них (вhex-кодах 50 45 00 00).
Одной из наших задач будет восстановление структуры исполняемого РЕ-файла с помощью расшифровки, полученной утилитой dumpbin.