Не создается файл elf

Обновлено: 05.07.2024

Sbtrn. Devil
Подскажите, граждане - реально ли написать для виндовса вручную загрузчик и запускатор какого-нибудь неродного формата (например, ELF)?

>soflot: есть такое мнение, что при наличии прямых рук, светлой головы и обилии мануалов теориетически можно

Sbtrn. Devil
Это не вопрос прямых рук (. ). Дело в том, что специалисты в окрестностях меня высказывали мнение на предмет следующего: низзя, мол, создать сегмента с кодовыми правами выполнения из-под процесса юзерского уровня. Ибо это, мол, привилегия ядра системы. Ибо, мол, в противном случае был бы беспредел и рай для вирусов.
(. )

"в тупую" запускать код нельзя. А если сделать эмулятор, то можно. Если сильно исхитриться и заменять все ОС-зависимые участки кода этого файла неродного формата на аналогичные участки кода родного формата ОС, то наверно тоже можно (хотя это для гениев/безумцев)

>низзя, мол, создать сегмента с кодовыми правами выполнения из-под процесса юзерского уровня.
Это гон.
Код уже загруженный в память активно изменяется разными программами, например отладчиком.
Thunks вполне работают.
VirtualProtect позволяет совершенно свободно разрешить выполнение кода с любой страницы VM.

Конишуа
>Это гон.
>Код уже загруженный в память активно изменяется разными программами, например
>отладчиком.
>Thunks вполне работают.
>VirtualProtect позволяет совершенно свободно разрешить выполнение кода с любой
>страницы VM.

Т. е., можно сделать так:

void *codepage = VirtualAlloc(хачу_адрес,хачу_размер,MEM_COMMIT,PAGE_EXECUTE_READWRITE);
FILE *f = fopen ("my_super_format_code.xxx","rb");
int (*entry_point) (int,char**) = MySuperLoader (codepage,xxx);
entry_point (argc,argv);

и будет щастье, и ничего нам за это не будет?

Даже больше. У старых x86 нет флажка NoExecute. Так что VirtualProtect что-то там защищает на исполнение с каких-то там сервиспаков XP и на новых CPU, не по дефолту. По дефолту и так все открыто.

Проблемы нет взять и отмапить elf в память, а потом выдать ему управление. Проблема есть в том что elf файл в своей линк-секции наверняка захочет поиспользовать какие-нибудь динамические библиотеки. Надо будет их поднимать и линковать. Если ограничиться libc.so ( скомпилировать под Windows libc.dll и звать функции оттуда ) - то пожалуй хорошее упражнение. Пожалуй "Hello World" можно поднять за пару дней.

На мой взгляд - можно. Я например писал эдакое извращение - делегаты для WinAPI:
1) Выделял память (HeapAlloc . )
2) Запихивал туда код:

И ведь работало.

Вот ссылка, прадва про загрузку PE и DLL но может помочь.

Ну, формат-то можно сделать и свой, который не требует для линкажа чего-нибудь сверхъестественного.
У меня ведь почему такой праздный интерес. Зародилась такая теоретическая идея на предмет повышения кросс-ОСности игр (в принципе, не только, но с играми проще всего, ибо они (кроме отмороженных сапёров, ессно) не используют стандартный ОС-зависимый юзер-интерфейс, поэтому не требуют дизайновых изменений при переносе на другой бакэнд). Смысл:

1) Взаимодействие софта со служебными сервисами (графика, звук, файлы и пр.) идёт не через систему, а через вызовы в некий фрамеворк собственного авторства, реализованные через "вызов функции по указателю, который сообщён при запуске".
2) На каждой интересующей нас ОС делается по реализации фрамеворка.
3) Выполнябельный код держится в тех самых исполняемых файлах собственного формата, а фрамеворк умеет их грузить. Причём, реализации таковы, что фрамеворк с разных ОС, но на одинаковой процессорной платформе распознает один и тот же исполняемый файл одинаково. Патчи для одной и той же проц. платформы, соответственно, тоже универсальные. (Если только какие-нть ОСы не пользуют процессор в совсем уж нестандартном режиме, но таких на компутере среднестатистического юзера или не стоит, или (ДОС) позволяется менять режим процессора в любой нужный.)
4) Версии фрамеворка для наиболее общеупотребительных ОС могут входить в стандартный комплект поставки, а для остальных могут фриварно скачиваться с суппортного сайта производителя софта (оттуда же и фреймворкные патчи).

Таким образом, можно достичь всяких полезных результатов. Например, охватить более широкую аудиторию при существенно меньших затратах, чем если бы пришлось сочинять по порту программы на каждую ОС. (Естественно, это проявится за счёт того, что фрамеворк можно реюзать в многих продуктах.) А фрамеворк можно сделать отдельным продуктом и делать на нём отдельный бизнес (завлекать народ распространением бесплатных СДК, продавать лицензии, и т. п.)

Запустить ELF под Windows вполне реально и довольно прость.
Одно время я хотел написать Wine-подобный эмулятор linux под windows, но проект быстро загнулся из-за полной невостребованности.

Правка+:
Sbtrn. Devil
4) Версии фрамеворка для наиболее общеупотребительных ОС могут входить в стандартный комплект поставки, а для остальных могут фриварно скачиваться с суппортного сайта производителя софта (оттуда же и фреймворкные патчи).

Что-то это звучит очень похоже на то, что сейчас вытворяет Microsoft. Идея то хорошая, только вот кто же этим не через Ж займётся?

Какие преимущества, кроме того что собирается один-единственный бинарник для разных платформ? Этот кросплатформенный layer можно попробовать вынести в библиотеку, тот же самый результат только проще. Думаю очевидно, что твоя идея идет лесом если должны поддерживаться несовместимые архитектуры процессоров.

Конишуа
>Какие преимущества, кроме того что собирается один-единственный бинарник для
>разных платформ? Этот кросплатформенный layer можно попробовать вынести в
>библиотеку, тот же самый результат только проще.

А унифицированный бинарник - это не так уж и мало. 8) Помимо той стороны, про которую я уже сказал, есть и ещё.

1) Допустим, в круг наших интересов включается новый ОС (на том же процессоре, ессно). Портируем на него фрамеворк, и.
- если оно было прилинковано библиотекой, все ранее написанные программы, которые использовали наш фрамеворк, для портации под новый ос придётся переделывать каждую.
- если оно было через унифицированный бинарник, все ранее написанные программы автоматически готовы к употреблению - юзеру только нужно качнуть и поставить фрамеворк.

2) Фрамеворк, помимо всего, может включать и свою собственную поддержку инсталляции, предназначенную для работающих под него программ. Естественно, тоже унифицированную. А это значит, что у нас единый не только бинарник, но и весь дистрибутив. То есть, можно собрать один и тот же дистрибутивный сидюк и распространять его на общих основаниях, и будет он иметь смысл и для виндузоидов, хоть для линуксоидов, и даже и для пользователей тех осов, которые мы пока ещё не включили в круг интересов, но собираемся. А это уже посерьёзнее.

>Думаю очевидно, что твоя идея
>идет лесом если должны поддерживаться несовместимые архитектуры процессоров.
Тут да. Но, учитывая, что процессорная архитектура у целевой аудитории практически одинаковая. :)

>Что-то это звучит очень похоже на то, что сейчас вытворяет Microsoft. Идея то
>хорошая, только вот кто же этим не через Ж займётся?

Да идеи у мелко$офта вообще хорошие (в истоках). Но они извращаются и губятся на корню через жадность и тщеславие.

Sbtrn. Devil
>> Что-то это звучит очень похоже на то, что сейчас вытворяет Microsoft. Идея то хорошая, только вот кто же этим не через Ж займётся?
> Да идеи у мелко$офта вообще хорошие (в истоках). Но они извращаются и губятся на корню через жадность и тщеславие.
Чем лучше идея, тем проще её изгадить. :(

идея эта уже реализована, только называется Wine и запускает виндовские приложения под линуксом

O01eg
> идея эта уже реализована, только называется Wine и запускает виндовские приложения под линуксом
Очередной намёк на то, что линукс круче всех? :/

Здесь, насколько я понял, речь идёт не о запуске софта для одной ОС на другой ОС (виндовские под *nix или наоборот, неважно), а о том, чтобы скомпилить 1 исполняемый файл и запускать его на любой системе.

Dinosaur
>Здесь, насколько я понял, речь идёт не о запуске софта для одной ОС на другой ОС (виндовские под *nix или наоборот, неважно), а о том, чтобы скомпилить 1 исполняемый файл и запускать его на любой системе.
А в чём разница? В том, что необходим внешний loader? Так он в любом случае понадобится

keltar
Просто мне показалось, что смысл поста O01eg'а был что-то вроде "есть же Wine и нефиг велосипед изобретать". Возможно, я его не так понял.

Есть в мире вещи, которые мы принимаем как нечто само собой разумеющееся, хотя они являются истинными шедеврами. Одними из таких вещей являются утилиты Linux, такие, как ls и ps. Хотя они обычно воспринимаются как простые, это оказывается далеко не так, если мы заглянем внутрь. И таким же оказывается ELF, Executable and Linkable Format. Формат файлов, который используется повсеместно, но мало кто его понимает. Это краткое руководство поможет вам достичь понимания.

Прочтя это руководство, вы изучите:

Зачем нужен формат ELF и для каких типов файлов он используется
Структуру файла ELF и детали его формата
Как читать и анализировать бинарное содержимое файла ELF
Какие инструменты используются для анализа бинарных файлов

Что представляет собой файл ELF?

ELF — это сокращение от Executable and Linkable Format (формат исполняемых и связываемых файлов) и определяет структуру бинарных файлов, библиотек, и файлов ядра (core files). Спецификация формата позволяет операционной системе корректно интерпретировать содержащиеся в файле машинные команды. Файл ELF, как правило, является выходным файлом компилятора или линкера и имеет двоичный формат. С помощью подходящих инструментов он может быть проанализирован и изучен.

Зачем изучать ELF в подробностях?

Перед тем, как погрузиться в технические детали, будет не лишним объяснить, почему понимание формата ELF полезно. Во-первых, это позволяет изучить внутреннюю работу операционной системы. Когда что-то пошло не так, эти знания помогут лучше понять, что именно случилось, и по какой причине. Также возможность изучения ELF-файлов может быть ценна для поиска дыр в безопасности и обнаружения подозрительных файлов. И наконец, для лучшего понимания процесса разработки. Даже если вы программируете на высокоуровневом языке типа Go, выа всё равно будет лучше знать, что происходит за сценой.

Итак, зачем изучать ELF?

Для общего понимания работы операционной системы
Для разработки ПО
Цифровая криминалистика и реагирование на инциденты (DFIR)
Исследование вредоносных программ (анализ бинарных файлов)

От исходника к процессу

Какую бы операционную систему мы не использовали, необходимо каким-то образом транслировать функции исходного кода на язык CPU — машинный код. Функции могут быть самыми базовыми, например, открыть файл на диске или вывести что-то на экран. Вместо того, чтобы напрямую использовать язык CPU, мы используем язык программирования, имеющий стандартные функции. Компилятор затем транслирует эти функции в объектный код. Этот объектный код затем линкуется в полную программу, путём использования линкера. Результатом является двоичный файл, который может быть выполнен на конкретной платформе и конкретном типе CPU.

Прежде, чем начать

Этот пост содержит множество команд. Лучше запускать их на тестовой машине. Скопируйте существующие двоичные файлы, перед тем, как запускать на них эти команды. Также мы напишем маленькую программу на С, которую вы можете скомпилировать. В конечном итоге, практика — лучший способ чему-либо научиться.

Анатомия ELF-файла

Распространённым заблуждением является то, что файлы ELF предназначены только для бинарных или исполняемых файлов. Мы уже сказали, что они могут быть использованы для частей исполняемых файлов (объектного кода). Другим примером являются файлы библиотек и дампы ядра (core-файлы и a.out файлы). Спецификация ELF также используется в Linux для ядра и модулей ядра.

Структура

В силу расширяемости ELF-файлов, структура может различаться для разных файлов. ELF-файл состоит из:

заголовок ELF

Как видно на скриншоте, заголовок ELF начинается с «магического числа». Это «магическое число» даёт информацию о файле. Первые 4 байта определяют, что это ELF-файл (45=E,4c=L,46=F, перед ними стоит значение 7f).

Заголовок ELF является обязательным. Он нужен для того, чтобы данные корректно интерпретировались при линковке и исполнении. Для лучшего понимания внутренней работы ELF-файла, полезно знать, для чего используется эта информация.

Класс

После объявления типа ELF, следует поле класса. Это значение означает архитектуру, для которой предназначен файл. Оно может равняться 01 (32-битная архитектура) или 02 (64-битная). Здесь мы видим 02, что переводится командой readelf как файл ELF64, то есть, другими словами, этот файл использует 64-битную архитектуру. Это неудивительно, в моей машине установлен современный процессор.

Данные

Далее идёт поле «данные», имеющее два варианта: 01 — LSB (Least Significant Bit), также известное как little-endian, либо 02 — MSB (Most Significant Bit, big-endian). Эти значения помогают интерпретировать остальные объекты в файле. Это важно, так как разные типы процессоров по разному обрабатывают структуры данных. В нашем случае используется LSB, так как процессор имеет архитектуру AMD64.

Эффект LSB становится видимым при использовании утилиты hexdump на бинарном файле. Давайте посмотрим заголовок ELF для /bin/ps.

Мы видим, что пары значений другие, из-за интерпретации порядка данных.

Версия

Затем следует ещё одно магической значение «01», представляющее собой номер версии. В настоящее время имеется только версия 01, поэтому это число не означает ничего интересного.

OS/ABI

Каждая операционная система имеет свой способ вызова функций, они имеют много общего, но, вдобавок, каждая система, имеет небольшие различия. Порядок вызова функции определяется «двоичным интерфейсом приложения» Application Binary Interface (ABI). Поля OS/ABI описывают, какой ABI используется, и его версию. В нашем случае, значение равно 00, это означает, что специфические расширения не используются. В выходных данных это показано как System V.

Версия ABI

При необходимости, может быть указана версия ABI.

Машина

Также в заголовке указывается ожидаемый тип машины (AMD64).

Поле типа указывает, для чего предназначен файл. Вот несколько часто встречающихся типов файлов.

CORE (значение 4)
DYN (Shared object file), библиотека (значение 3)
EXEC (Executable file), исполняемый файл (значение 2)
REL (Relocatable file), файл до линковки (значение 1)

Смотрим полный заголовок

Хотя некоторые поля могут быть просмотрены через readelf, их на самом деле больше. Например, можно узнать, для какого процессора предназначен файл. Используем hexdump, чтобы увидеть полный заголовок ELF и все значения.

(вывод hexdump -C -n 64 /bin/ps)

Выделенное поле определяет тип машины. Значение 3e — это десятичное 62, что соответствует AMD64. Чтобы получить представление обо всех типах файлов, посмотрите этот заголовочный файл.

Хотя вы можете делать всё это в шестнадцатиричном дампе, имеет смысл использовать инструмент, который сделает работу за вас. Утилита dumpelf может быть полезна. Она показывает форматированный вывод, соответствующий заголовку ELF. Хорошо будет изучить, какие поля используются, и каковы их типичные значения.

Теперь, кгда мы объяснили значения этих полей, время посмотреть на то, какая реальная магия за ними стоит, и перейти к следующим заголовкам!

Данные файла

Помимо заголовка, файлы ELF состоят из трёх частей.

Программные заголовки или сегменты
Заголовки секций или секции
Данные

Заголовки программы

Файл ELF состоит из нуля или более сегментов, и описывает, как создать процесс, образ памяти для исполнения в рантайме. Когда ядро видит эти сегменты, оно размещает их в виртуальном адресном пространстве, используя системный вызов mmap(2). Другими словами, конвертирует заранее подготовленные инструкции в образ в памяти. Если ELF-файл является обычным бинарником, он требует эти программные заголовки, иначе он просто не будет работать. Эти заголовки используются, вместе с соответствующими структурами данных, для формирования процесса. Для разделяемых библиотек (shared libraries) процесс похож.

Программный заголовок в бинарном ELF-файле

Мы видим в этом примере 9 программных заголовков. Сначала трудно понять, что они означают. Давайте погрузимся в подробности.

GNU_EH_FRAME

Это сортированная очередь, используемая компилятором GCC. В ней хранятся обработчики исключений. Если что-то пошло не так, они используются для того, чтобы корректно обработать ситуацию.

GNU_STACK

Этот заголовок используется для сохранения информации о стеке. Интересная особенность состоит в том, что стек не должен быть исполняемым, так как это может повлечь за собой уязвимости безопасности.

Если сегмент GNU_STACK отсутствует, используется исполняемый стек. Утилиты scanelf и execstack показывают детали устройства стека.

dumpelf (pax-utils)
elfls -S /bin/ps
eu-readelf –program-headers /bin/ps

Секции ELF

Заголовки секции

Заголовки секции определяют все секции файла. Как уже было сказано, эта информация используется для линковки и релокации.

Секции появляются в ELF-файле после того, как компилятор GNU C преобразует код С в ассемблер, и ассемблер GNU создаёт объекты.

Как показано на рисунке вверху, сегмент может иметь 0 или более секций. Для исполняемых файлов существует четыре главных секций: .text, .data, .rodata, и .bss. Каждая из этих секций загружается с различными правами доступа, которые можно посмотреть с помощью readelf -S.

Содержит исполняемый код. Он будет упакован в сегмент с правами на чтение и на исполнение. Он загружается один раз, и его содержание не изменяется. Это можно увидеть с помощью утилиты objdump.

Инициализированные данные, с правами на чтение и запись.

.rodata

Инициализированные данные, с правами только на чтение. (=A).

Неинициализированные данные, с правами на чтение/запись. (=WA)

dumpelf
elfls -p /bin/ps
eu-readelf –section-headers /bin/ps
readelf -S /bin/ps
objdump -h /bin/ps

Группы секций

Некоторые секции могут быть сгруппированы, как если бы они формировали единое целое. Новые линкеры поддерживают такую функциональность. Но пока такое встречается не часто.

Хотя это может показаться не слишком интересным, большие преимущества даёт знание инструментов анализа ELF-файлов. По этой причине, обзор этих инструментов и их назначения приведён в конце статьи.

Статические и динамические бинарные файлы

Когда мы имеем дело с бинарными файлами ELF, полезно будет знать, как линкуются эти два типа файлов. Они могут быть статическими и динамическими, и это относится к библиотекам, которые они используют. Если бинарник «динамический», это означает, что он использует внешние библиотеки, содержащие какие-либо общие функции, типа открытия файла или создания сетевого сокета. Статические бинарники, напротив, включают в себя все необходимые библиотеки.

Если вы хотите проверить, является ли файл статическим или динамическим, используйте команду file. Она покажет что-то вроде этого:

Чтобы определить, какие внешние библиотеки использованы, просто используйте ldd на том же бинарнике:

Совет: Чтобы посмотреть дальнейшие зависимости, лучше использовать утилиту lddtree.

Инструменты анализа двоичных файлов

Если вы хотите анализировать ELF-файлы, определённо будет полезно сначала посмотреть на существующие инструменты. Существуют тулкиты для обратной разработки бинарников и исполняемого кода. Если вы новичок в анализе ELF-файлов, начните со статического анализа. Статический анализ подразумевает, что мы исследуем файлы без их запуска. Когда вы начнёте лучше понимать их работу, переходите к динамическому анализу. Запускайте примеры и смотрите на их реальное поведение.

Часто задаваемые вопросы

Что такое ABI?

ABI — это Бинарный Интерфейс Приложения (Application Binary Interface) и определяет, низкоуровневый интерфейс между операционной системой и исполняемым кодом.

Что такое ELF?

ELF — это Исполняемый и Связываемый Формат (Executable and Linkable Format). Это спецификация формата, определяющая, как инструкции записаны в исполняемом коде.

Как я могу увидеть тип файла?

Используйте команду file для первой стадии анализа. Эта команда способна показать подробности, извлечённые из «магических» чисел и заголовков.

Заключение

Файлы ELF предназначены для исполнения и линковки. В зависимости от назначения, они содержат необходимые сегменты и секции. Ядро ОС просматривает сегменты и отображает их в память (используя mmap). Секции просматриваются линкером, который создаёт исполняемый файл или разделяемый объект.

Файлы ELF очень гибкие и поддерживаются различные типы CPU, машинные архитектуры, и операционные системы. Также он расширяемый, каждый файл сконструирован по-разному, в зависимости от требуемых частей. Путём использования правильных инструментов, вы сможете разобраться с назначением файла, и изучать содержимое бинарных файлов. Можно просмотреть функции и строки, содержащиеся в файле. Хорошее начало для тех, кто исследует вредоносные программы, или понять, почему процесс ведёт себя (или не ведёт) определённым образом.

Ресурсы для дальнейшего изучения

Если вы хотите больше знать про ELF и обратную разработку, вы можете посмотреть работу, которую мы выполняем в Linux Security Expert. Как часть учебной программы, мы имеем модуль обратной разработки с практическими лабораторными работами.

Для тех из вас, кто любит читать, хороший и глубокий документ: ELF Format и документ за авторством Брайана Рейтера (Brian Raiter), также известного как ELFkickers. Для тех, кто любит разбираться в исходниках, посмотрите на документированный заголовок ELF от Apple.

Совет:
если вы хотите стать лучше в анализе файлов, начните использовать популярные инструменты анализа, которые доступны в настоящее время.

просто любопытно. Это, очевидно, не очень хорошее решение для фактического программирования, но, скажем, я хотел сделать исполняемый файл в Bless (hex editor).

моя архитектура x86. Какую очень простую программу я могу сделать? Привет миру? Бесконечная петля? Похожие на этой вопрос, но в Linux.

Как упоминалось в моем комментарии, вы по существу будете писать свой собственный ELF-заголовок для исполняемого файла, устраняя ненужные разделы. Есть еще несколько необходимых разделов. Документация по адресу Muppetlabs-TinyPrograms делает справедливую работу, объясняя этот процесс. Для удовольствия, вот несколько примеров:

эквивалент /bin / true (45 байт):

классический 'Привет, Мир!'(160 байт):

Не забудьте сделать их исполняемыми.

Декомпилируйте NASM hello world и поймите каждый байт в нем

стандарты

ELF указывается LSB:

LSB в основном ссылается на другие стандарты с незначительными расширениями, в частности:

generic (оба по SCO):

удобное резюме можно найти по адресу:

его структура может быть рассмотрена читаемым человеком способом с помощью утилит, таких как readelf и objdump .

создать пример

давайте сломаем минимальный запускаемый Linux x86-64 пример:

NASM 2.10.09
Binutils версии 2.24 (содержит ld )
Ubuntu 14.04

мы не используем программу на C, так как это усложнит анализ, это будет Уровень 2 :-)

Hexdumps

глобальный файл структура

файл ELF содержит следующие части:

заголовок ELF. Указывает на положение таблицы заголовка раздела и таблицы заголовка программы.

таблица заголовка раздела (необязательно для исполняемого файла). У каждого есть e_shnum заголовки разделов, каждый из которых указывает на положение раздела.

N секций, с N <= e_shnum (необязательный на исполняемый файл)

таблица заголовка программы (только для исполняемого файла). У каждого есть e_phnum заголовки программ, каждый из которых указывает на положение сегмента.

N сегментов, с N <= e_phnum (необязательно для исполняемого файла)

порядок этих частей составляет не исправлено: единственная исправленная вещь-заголовок ELF, который должен быть первым в файле: Generic docs say:

эльф заголовок

самый простой способ наблюдать за заголовком:

байт в объектном файле:

0 0: EI_MAG = 7f 45 4c 46 = 0x7f 'E', 'L', 'F' : эльф магия номер

0 4: EI_CLASS = 02 = ELFCLASS64 : 64 бит elf

0 5: EI_DATA = 01 = ELFDATA2LSB : big endian data

0 6: EI_VERSION = 01 : версия формата

0 7: EI_OSABI (только в обновлении 2003) = 00 = ELFOSABI_NONE : никаких расширений.

0 8: EI_PAD = 8x 00 : зарезервировано байт. Должно быть установлено в 0.

1 0: e_type = 01 00 = 1 (обратный порядок байтов) = ET_REl : формат перемещаемых

на исполняемом файле это 02 00 на ET_EXEC .

1 2: e_machine = 3e 00 = 62 = EM_X86_64 : архитектура AMD64

1 4: e_version = 01 00 00 00 : должно быть 1

1 8: e_entry = 8x 00 : точка входа адреса выполнения или 0, если нет применимо как для объектного файла, так как нет точки входа.

на исполняемом файле это b0 00 40 00 00 00 00 00 . TODO: на что еще мы можем это установить? Ядро, похоже, помещает IP непосредственно в это значение, оно не жестко закодировано.

2 0: e_phoff = 8x 00 : смещение таблицы заголовка программы, 0 если нет.

40 00 00 00 на исполняемом файле, т. е. он запускается сразу после заголовка ELF.

2 8: e_shoff = 40 7x 00 = 0x40 : смещение файла таблицы заголовка раздела, 0 если нет.

3 0: e_flags = 00 00 00 00 TODO. Arch specific.

3 4: e_ehsize = 40 00 : размер этого заголовка elf. TODO почему это поле? Как она может меняться?

3 6: e_phentsize = 00 00 : размер каждого заголовка программы, 0 если нет.

38 00 on исполняемый файл: это 56 байт

3 8: e_phnum = 00 00 : количество записей заголовка программы, 0 если нет.

02 00 на исполняемом файле: есть 2 записи.

3 A: e_shentsize и e_shnum = 40 00 07 00 : размер заголовка раздела и количество записей

3 E: e_shstrndx ( Section Header STRing iNDeX ) = 03 00 : индекс .

заголовок раздела таблица

массив Elf64_Shdr структуры.

каждая запись содержит метаданные о данном разделе.

e_shoff заголовка ELF дает начальную позицию, 0x40 здесь.

e_shentsize и e_shnum из заголовка ELF говорят, что у нас есть 7 записей, каждая 0x40 байт.

таким образом, таблица принимает байты от 0x40 до 0x40 + 7 + 0x40 - 1 = 0x1FF.

readelf -S hello_world.o :

struct в лице каждой записи:

разделы

90 0: sh_addr = 8x 00 : в каком виртуальном адресе будет размещен раздел во время выполнения, 0 если не помещено

90 8: sh_offset = 00 02 00 00 00 00 00 00 = 0x200 : число байт от начала программы до первого байта в этом разделе

a0 0: sh_size = 0d 00 00 00 00 00 00 00

если мы возьмем 0xD байта, начиная с sh_offset 200, видим:

АХА! Так наши "Hello world!" строка находится в разделе данных, как мы сказали, чтобы быть на NASM.

как только мы закончим hd , мы будет выглядеть так:

также обратите внимание, что это был плохой выбор раздела: хороший компилятор C поместил бы строку в .rodata вместо этого, потому что он доступен только для чтения, и это позволит для дальнейшей ОС процессы оптимизации.

b0 0: sh_addralign = 04 = TODO: почему это выравнивание необходимо? Это только для sh_addr , или также для символов внутри sh_addr ?

b0 8: sh_entsize = 00 = раздел не содержать таблицу. Если != 0, это означает, что раздел содержит таблицу записей фиксированного размера. В этом файле мы видим из readelf выведите, что это относится к .symtab и .rela.text разделы.

.текстовый раздел

теперь, когда мы сделали один раздел вручную, давайте закончим и используем readelf -S других разделов.

.text является исполняемым, но не записываемым: если мы попытаемся написать на него Linux с падениями. Давайте посмотрим, действительно ли у нас есть какой-то код:

если мы grep b8 01 00 00 на hd , мы видим, что это происходит только в 00000210 , что и говорится в разделе. И размер 27, который также совпадает. Поэтому мы должны говорить о правильном разделе.

это выглядит как правильный код: write затем exit .

самая интересная часть-line a что делает:

для передачи адреса строки в системный вызов. В настоящее время 0x0 - это просто заполнитель. После связывания происходит, он будет изменен, чтобы содержать:

это изменение возможно из-за данных .

sht_strtab и атрибут

разделы sh_type == SHT_STRTAB называют строка таблицы.

они содержат null разделенный массив веревка.

такие разделы используются другими разделами при использовании имен строк. В разделе using говорится:

какую таблицу строк они используют
что такое индекс в целевой таблице строк, где начинается строка

например, у нас может быть таблица строк, содержащая: TODO: она должна начинаться с ?

и если другой раздел хочет использовать строку d e f , они должны указывать на index 5 этого раздела (письмо d ).

примечательные разделы таблицы строк:

.shstrtab

тип раздела: sh_type == SHT_STRTAB .

общее имя: таблица строк заголовка раздела.

название раздела .shstrtab зарезервирован. Стандарт гласит:

этот раздел содержит имена разделов.

на этот раздел указывает e_shstrnd поле самого заголовка ELF.

строковые индексы этого раздела указывают на sh_name поле заголовков разделов, которые обозначают строки.

в этом разделе нет SHF_ALLOC отмечен, поэтому он не будет отображаться в исполняющей программе.

если мы посмотрим на названия других разделов, мы увидим, что все они содержат номера, например номером 7 .

затем каждая строка заканчивается, когда найден первый символ NUL, например, символ 12 is сразу после .text .

.symtab

тип раздела : sh_type == SHT_SYMTAB .

общее имя: таблица символов.

Сначала отметим, что:

на SHT_SYMTAB разделы, эти цифры означают, что:

строки, которые дают имена символов, находятся в разделе 5, .strtab
данные переселение в разделе 6, .rela.text

хороший инструмент высокого уровня для разборки этого раздела:

это, однако, вид высокого уровня, который опускает некоторые типы символов и в которых типы символов . Более подробную разборку можно получить с помощью:

как и в таблице разделов, первая запись является магической и имеет фиксированные бессмысленные значения.

запись 1 имеет ELF64_R_TYPE == STT_FILE . ELF64_R_TYPE продолжение внутри st_info .

10 8: st_name = 01000000 = символ 1 в .strtab , который до делает hello_world.asm

этот информационный файл может использоваться компоновщиком для решения, к какому сегменту идти.

10 12: st_info = 04

биты 0-3 = ELF64_R_TYPE = Type = 4 = STT_FILE : основная цель этой записи-использовать st_name to Укажите имя файла, который сгенерировал этот объектный файл.

биты 4-7 = ELF64_ST_BIND = обязательного = 0 = STB_LOCAL . Требуемое значение для STT_FILE .

10 13: st_shndx = индекс заголовка раздела таблицы символов = f1ff = SHN_ABS . Требуется для STT_FILE .

20 0: st_value = 8x 00 : требуется для значения для STT_FILE

20 8: st_size = 8x 00 : не выделены размере

теперь из readelf , мы быстро интерпретируем остальные.

есть две такие записи, одна из которых указывает на .data , а другой .text (индексы разделе 1 и 2 ).

TODO какова их цель?

затем идут самые важные символы:

hello_world строка в (индекс 1). Это значение равно 0: оно указывает на первый байт этого раздела.

_start обозначен GLOBAL видимость, так как мы написали:

в NASM. Это необходимо, поскольку она должна рассматриваться как точка входа. В отличие от C, по умолчанию метки NASM являются локальными.

hello_world_len указывает на специальные st_shndx == SHN_ABS == 0xF1FF .

0xF1FF выбирается так, чтобы не конфликтовать с другими разделами.

st_value == 0xD == 13 какое значение мы сохранили там в сборке: длина строки Hello World! .

это означает, что перемещение не повлияет на это значение: это константа.

это небольшая оптимизация, которую наш ассемблер делает для нас и которая имеет поддержку ELF.

если бы мы использовали адрес hello_world_len в любом месте ассемблер не смог бы отметить его как SHN_ABS , и компоновщик будет иметь дополнительную работу по перемещению на нем позже.

Раздел sht_symtab на исполняемый

по умолчанию NASM помещает .symtab на исполняемом файле, а также.

это используется только для отладки. Без символов мы полностью слепы и должны все перестроить.

вы можете снять его с objcopy , и исполняемый файл, все равно будет работать. Таких программ называется лишен исполняемые файлы.

.strtab

содержит строки для символа таблица.

в этом разделе sh_type == SHT_STRTAB .

он указал sh_link == 5 на .

это означает, что это ограничение уровня ELF, что глобальные переменные не могут содержать символы NUL.

.Рела.текст

тип раздела: sh_type == SHT_RELA .

общее имя: раздел переезд.

.rela.text держит данные перемещения, которые говорят, как адрес должен быть изменен, когда окончательный исполняемый файл связан. Это указывает на байты текстовой области, которые должны быть изменены при связывании происходит указать на правильные места памяти.

в основном, он переводит текст объекта, содержащий адрес заполнителя 0x0:

к фактическому исполняемому коду, содержащему окончательный 0x6000d8:

на него указал sh_info = 6 of the .

readelf -r hello_world.o выдает:

раздел не существует в исполняемом файле.

на struct является:

370 0: r_offset = 0xC: адрес в .text чей адрес это перемещение изменит

370 8: r_info = 0x200000001. Содержит 2 поля:

ELF64_R_TYPE = 0x1: значение зависит от точной архитектуры.
ELF64_R_SYM = 0x2: индекс раздела, на который указывает адрес, так что .data который находится в индексе 2.

amd64 ABI говорит, что тип 1 называется R_X86_64_64 и что он представляет собой операцию S + A где:

S : значение символа в объектном файле, здесь 0 потому что мы указываем на 00 00 00 00 00 00 00 00 of movabs x0,%rsi
A : добавление, присутствует в поле r_added

этот адрес добавляется в раздел, на котором выполняется перемещение.

эта операция перемещения действует в общей сложности 8 байт.

380 0: r_addend = 0

Итак, в нашем примере мы заключаем, что новый адрес будет: S + A = .data + 0 , и таким образом первый вещь в разделе данных.

таблица заголовка программы

отображается только в исполняемом файле.

содержит информацию о том, как исполняемый файл должен быть помещен в виртуальную память процесса.

исполняемый файл создается компоновщиком из объектных файлов. Основные задания, которые выполняет компоновщик:

определите, какие разделы объектных файлов будут входить в какие сегменты выполнимый.

в Binutils это сводится к разбору скрипта компоновщика и работе с кучей значений по умолчанию.

вы можете получить сценарий компоновщика, используемый с ld --verbose , и установите пользовательский с ld -T .

сделать перемещение по тексту разделов. Это зависит от того, как несколько разделов помещаются в память.

readelf -l hello_world.out выдает:

на заголовке ELF, e_phoff , e_phnum и e_phentsize сказал нам, что есть 2 заголовка программы, которые начинаются с 0x40 и 0x38 байт длиной каждый, поэтому они:

Читайте также: