Comments 22
А есть в формате ELF аналог виндовских ресурсов и метаданных? А то я смотрю, в Линуксе иконки программ обычно хранятся отдельно, а не внутри исполняемого модуля.
В формате ELF я такого не нашел, очень мало русскоязычной информации, англоязычной тоже не так много. Но судя по всему, нету аналога метаданных для elf-файлов, да я бы и не сказал, что они сильно нужны.
Это мое субъективное мнение.
в википедии (статья “Comparison of executable file formats”) упоминается некая частная инициатива для иконок в elf. Исходники 2011-го года.
Нет, в формате ELF точно нет такой секции. Справедливости ради, непонятно зачем они могли бы пригодиться. Ресурсы для ПО можно разместить и в .data /.rodata, в ОС эти ресурсы особо и не кому использовать, ведь GUI в Linux дело опциональное
Разумеется, хранить ресурсы можно и в виде обычных массивов констант (как в линуксе и делается, в частности в Qt из-за этого все ресурсы компилируются именно в сишный код). Дело в стандартизации (стандартное место для иконки приложения, информации об авторе, компании и т.п.), а также в структуризации (в том числе упрощении декомпиляции, понимаю что авторам проприетарщины это нафиг не нужно, но тем ни менее всякие виртуальные форматы из Java и .NET именно так и устроены, они имеют более высокоуровневую внутреннюю структуру).
В Linux это решается иными средствами, но согласен, что PE в этом смысле удобнее. Совсем удобно сделано, как по мне, в MacOs)
А как в MacOs ?
В MacOs с используется формат исполняемого файла Mach-O. И сам по себе он ресурсов не поддерживает, зато поддерживает возможность впихнуть в него исполняемый код от разных архитектур сразу (x86_64, AArch64, etc), что позволяет не иметь 100500 сборок, а иметь один "универсальный бинарь".
Но! Приложения в MacOS не распространяются как отдельные исполняемые файлы. Приложения распространяются как "бандлы" (читай что-то вроде tar-архива, только с расширением .app). И все ресурсы просто кладутся рядышком в виде файлов. Их можно даже штатным Finder-ом просто взять и посмотреть. Библиотеки, кстати, тоже распространяются таким же образом, только называется это не "бандл", а "фреймворк" и соответственно расширение у файла будет .framework.
В принципе, можно любые бинарные данные встроить в исполняемый файл, но неудобно: https://stackoverflow.com/questions/4158900/embedding-resources-in-executable-using-gcc
один или несколько заголовков программы, которые описывают исполняемые сегменты
не только исполняемые. Как флаги велят, и только для сегментов LOAD.
Сегменты представляют собой смежные фрагменты кода и данных
не обязательно смежные. Например, 1-й сегмент LOAD компоновщик обычно рисует для смещения 0 и он захватывает сегменты PHDR, INTERP, NOTE, ну и elf header заодно.
Типичные сегменты включают в себя: .text .rodata, тип сегмента, смещение …
типичный орган человека включает в себя углерод, водород, латинское наименование, размер … вы смешали в кучу несмешиваемое и ничего не объяснили.
Каждая из этих секций загружается с различными правами доступа
OC плевать на секции, она смотрит только на program headers. Да, вы там позже написали, что секции, типа, только для компоновщика. Но утверждение-то — вот оно, сияет.
Для загрузки в память процесса и выполнения ELF-файлов используется еще одна логическая организация — сегментная, о которой мы поговорим ниже
хоба, а выше тогда о чём было?
Некоторые секции могут быть сгруппированы
зачем это написано?
отсутствие PT_GNU_STACK говорит о том, что содержимое стека может быть исполнено
неверно. это зависит от стапицот условий
Это немного по фактическим ошибкам. В целом статья выглядит хаотичным набором утверждений, непонятно зачем сделанных.
Спасибо за отзыв, в будущем надеюсь получится лучше(
Когда буду писать следующую статью - обязательно учту фактические ошибки.
В свою защиту лишь скажу - что изучение elf сложное, мало русскоязычной информации, и требуется почитать книги.
Вы не пишете статьи – Вы копируете текст из книг, приписываете себе авторство и минимально меняете формулировки отдельных предложений. В данном случае "статья" полностью состоит из украденных первых глав книги Практический анализ двоичных файлов / пер. с англ. А. А. Слинкина. – М.: ДМК Пресс, 2021, которые доступны по адресу https://dmkpress.com/files/PDF/978-5-97060-978-1.pdf
Было бы здорово общий обзор о форматах исполнимых файлов от бинарников, .com, MZ-EXE и т.п. Зачем вообще в них что-то так как есть. Почему вообще придумали разные не совместимые друг с другом форматы. Зачем навыдумывали всякие там MZ-EXE, NE-EXE, LE-EXE, PE-EXE. Зачем нагородили это вот всё, и чем не угодили старые форматы....
Именно с ним мы будем работать в этой книге.
То "я", то "мы". То "статья", то "книга". Откуда уши?
Статистические библиотеки (в Linux они обычно имеют расширение .a или .so) включаются в исполняемый двоичный файл, поэтому ссылки на них можно разрешить окончательно.
??? Статистические библиотеки ???
.so - shared object
Собственно текст честно украден из https://dmkpress.com/files/PDF/978-5-97060-978-1.pdf. А не понимая его содержания, "автор" решил "исправить" "опечатку".
А как elf работает когда я собираю программу с помощью avr-gcc и получаю .elf файл?
Про radare2 есть, а пр rizin нет.
Что такое ELF? Чем он отличается от PE в Windows?
Так чем же ELF принципиально отличается от PE?
В чем плюсы PE? В чем плюсы ELF?
Так и не нашел в статье ничего типа сравнительной таблички.
PE удобнее в смысле метаданных. Что интересно что PE представляет собой модифицированную версию COFF формата unix. У PE есть вариант для 64 битных Windows - PE32+, стандартный pe не поддерживает 64 битный режим. Также цифровая подпись в ELF - расширение, когда как в PE ее нет, а в PE32+ она есть. Фат-бинари в elf также расширение, а в обоих PE это уже встроено. И также с тем, может ли содержать иконку файла в себе.
Подробнее тут
Эльфы и пингвины: что такое ELF и как он работает в Linux?