Вижу, что хотя бы кто-то откликнулся… И то хорошо…
Цитата
а надо ли велосипед изобретать? есть же готовые утилиты конвертирующие в HEX. Ну а там, где HEX - и до bin не далеко ))
Изобретать, таки надо… В HEX родной и смотрим, а за одно и одним глазом в документацию по эльфу…
И, вот что я там увидел…
Допустим у нас есть некий тест TEST_1_1.abs (он прикреплён ). Смотрим на него, например, через Total Commander. Анализируя содержимое и, сопоставляя с написанным в доках по эльфу, приходим к таким результатам:
1) Первые 16 байт, это наш заголовок в котором говориться, что это непосредственно эльф-файл, заточен он под 32-бита, data представлена в виде LSB. И ещё там версия заголовка, которая нам, в принципе, до одного места.
Хорошо, смотрим дальше.
2) Два следующих байта говорят нам, что это исполняемый файл.
3) Следящая пара сообщает, что файл предназначен для «такого-то» железа.
4) Далее, целых четыре байта – «очередная» версия.
5) А вот здесь начинают твориться непонятные штуки. Четыре байта адреса, по которому побежит наша система для запуска процесса. Смотрим по этому адресу (0x400) и видим, что там у нас пустота. То есть всё в нопах вплоть до section header table, который находиться в самом конце файла, как будет понятно далее.
6) В следующих четырёх байтах содержится сдвиг от начала файла, по которому у нас лежит program header table (0x34). А следующие четыре байта говорят, где находиться section header table(0x13D0). Тут всё ясно.
7) Потом четвёрка нулевых байтов. Это флаг, который используется в объектниках.
8) Два байта. Это размер заголовка, в котором мы сейчас роемся(0x34).
9) В следующих двух байтах хранится инфа о размере входа в program header table. Причём все остальные энтры такие же.
10) Два байта, которые говорят нам количество файлов program header таблиц.
11) и 12) тоже самое, что и 9) , 10) но для section header table.
13) Последние два байта эта таблица индексов для section name string table.
Насколько я понял из документации, что для того, чтобы нам вытянуть требуемый .bin, то section header table не нужен. А нужен он лишь при линковке. Поэтому туда я даже не заглядывал (лишь краем глаза).
Взялся за program header table. Смотрю по адресу 0x34:
1) Первые четыре байта это тип сегмента. Как видим он у нас равен 1. Это значит, что сегмент загружаемый.
2) Следующая четвёрка показывает, где у нас находиться начало этого сегмента в файле (0xB0).
3) Четыре байта. Это адрес, по которому должен размещаться сегмент в виртуальной памяти(0x00000000).
4) Далее четыре байта. Физический адрес в памяти (0x00000000).
5) Четыре байта. Размер сегмента в файле (0x00000010).
6) Четыре байта. Размер сегмента в памяти(0x00000010).
7) Четыре байта. Флаг. Что он значит, я не нашёл, но он всё равно в нулях.
8) Последняя четвёрка. Выравнивание в памяти и в файле. У нас равно 0х8.
Далее идёт ещё таблица следующего сегмента. Всё тоже самое, только описываются другие адреса и размеры.
Потом идет, судя по всему какой-то string table. А далее собственно сами сегменты.
В итоге, до чего я додумался. Я просто взял эти два сегмента и поместил их в память, так как они идут в самом файле (таблицу секций в конце я откинул).
Но меня терзают смутные сомнения. Всё ли я сделал правильно. И ещё это адрес входа 0х400… К чему он? Проверить пока что не могу, проблемы с платой. Может ещё с таблицей секций чёто делать надо? Или этот непонятный string table тоже куда-то всунуть?
Цитата
Для раздраконивания elf есть штатная утилита objdump.
Не разраконивается... Не разобрался я в ней... Мрачная она какая-то... Но всё равно спасибо...
abs2bin, Помогите с форматом
Nov 16 2010, 14:43
