Восстановление структуры двоичного представления объектного файла
Рассмотрите дамп. Он получен с помощью системной утилиты dumpbin, которая создана именно для удобного и структурированного показа пользователям содержимого объектных файлов и исполняемых ехе-модулей.
Но наша задача состоит в изучении бинарника. Мы должны установить, где в нем находятся его функциональные части и, по возможности, структуру самих этих частей.
Задача будет решаться методом сопоставления. Мы будем в дампе находить очередную отдельную часть и по ее данным в бинарнике будем находить начало этой же части и ее конец. В тексте бинарника будем отделять найденную часть от остального текста линиями. Можно делать это карандашом на распечатке бинарника, а можно вносить эти линии в Worde прямо в документ (из опыта подскажем, что лучше всего графическая форма «ступенчатая линия»
При установлении соответствия числовых и символьных данных в дампе и бинарнике следует учитывать вот что.
Компилятор при создании объектного файла пишет в него числа либо как двухбайтные поля (16-битные целые), либо как 4-байтные поля (32-битные целые), причем вы столкнетесь и с первым, и со вторым вариантом. Текстовую информацию компилятор записывает в формате «байт на символ». Эти части бинарника легко опознать по колонке 3 (рис. 4.1). К примеру, текстовое поле «.text» во второй строке примера рис. 4.1 соответствует байтам «2E 74 65 78 74» в этой же строке, колонка 2.
Кроме того, что числа могут представляться двумя или четырьмя байтами, следует учитывать, что в дампе числа «для читателя-человека» приводятся в в 16-ричной системе счисления в позиционной записи (самый младший разряд справа), а в бинарнике они записываются «для компьютера» в «физическом» представлении по принципу «младшие байты чиса – по младшим адресам, старшие – по старшим». Например, в дампе читаем число 14С (все числа записываются в 16-ричной системе). В бинарнике это два байта «4С 01». В дампе число представлено «5346D91E», в бинарнике оно видно как бы «вывернутым задом наперед» - «1E D9 46 53». Это нужно учитывать при выполнении работы.
Замечание о переводе английских терминов в дампе. Большинство терминов переводятся без проблем, но о некоторых надо сказать особо.
Термин “Raw Data” означает «необработанные данные». Это последовательности байтов, которые dumpbin переносит из объектного файла в файл дампа «как есть», ничего не расшифровывая. Это нам на руку, потому что дает возможность идентифицировать в бинарнике эти части секций просто побайтным сравнением.
Рисунок 4.2 – Вид распечатки размеченного файла бинарного представления объектного файла.
Термин “Relocations” означает «неразрешенные ссылки в секции кода». Таблица “Relocations #1” описывает, где в секции номер 1 (ее имя .text, а по смыслу это секция кода) находятся эти поля, каким именам (“symbols”) исходного текста они соответствуют, и приводит ряд других сведений о них. Одна из ваших задач по расшифровке объектного файла – составить обоснованные предположения об информации, содержащейся в этой таблице.
Ну, и слово «symbol». В англоязычных текстах по программированию его следует понимать как «имена объектов». Так что заголовок «COFF Symbol Table» следует понимать как «Таблица имен сущностей в объектном файле типа COFF».
Всё, начинайте работу.
Задача – найти в бинарнике участки, соответствующие частям дампа, озаглавленным заголовками: «File header values», «Section header #1», «Raw data #1» , «Relocations #1» , «Section header #2» , «Raw data #2 2» , «Section header #3» , «Raw data #3» , «Linker directives» , «Coff symbol table ».
Провести разграничительные линии между найденными частями в бинарнике. Каждую такую часть подписать ее заголовком на правом свободном поле (вот для чего нужна альбомная ориентация листа бинарника).
Имена программных секций и их hex-представление в бинарнике (.text, .data, .drectve) выделить цветным маркером.
Составить структуру объектного файла (бинарника) в соответствии с проделанной работой в формате «Название части – смещение в бинарнике».
Примерный вид размеченного бинарника показан на рис.4.2.