Исполнимый файл программы может иметь расширение

Аннотация: Управление памятью в Windows. Обзор структуры исполняемых файлов в формате Portable Executable (PE). Пример генерации PE-файла.

Формат исполняемых файлов

Исполняемый файл ( executable file ) — это файл , который может быть загружен в память загрузчиком операционной системы и затем исполнен. В операционной системе Windows исполняемые файлы, как правило, имеют расширения «.exe» и «.dll». Расширение «.exe» имеют программы, которые могут быть непосредственно запущены пользователем. Расширение «.dll» имеют так называемые динамически связываемые библиотеки ( dynamic link libraries). Эти библиотеки экспортируют функции, используемые другими программами.

Для того чтобы загрузчик операционной системы мог правильно загрузить исполняемый файл в память , содержимое этого файла должно соответствовать принятому в данной операционной системе формату исполняемых файлов. В разных операционных системах в разное время существовало и до сих пор существует множество различных форматов. В этой главе мы рассмотрим формат Portable Executable (PE). Формат PE — это основной формат для хранения исполняемых файлов в операционной системе Windows . Сборки . NET тоже хранятся в этом формате.

ВСЁ о расширениях файлов в Windows 7, 8.1, 10, 11 | Экспорт / Импорт расширений

Кроме того, формат PE может использоваться для представления объектных файлов . Объектные файлы служат для организации раздельной компиляции программы. Смысл раздельной компиляции заключается в том, что части программы (модули) компилируются независимо в объектные файлы , которые затем связываются компоновщиком в один исполняемый файл .

А теперь — немного истории. Формат PE был создан разработчиками Windows NT. До этого в операционной системе Windows использовались форматы New Executable (NE) и Linear Executable (LE) для представления исполняемых файлов, а для хранения объектных файлов использовался Object Module Format (OMF). Формат NE предназначался для 16-разрядных приложений Windows , а формат LE, изначально разработанный для OS/2 , был уже 32-разрядным.

Возникает вопрос: почему разработчики Windows NT решили отказаться от существующих форматов? Ответ становится очевидным, если обратить внимание на то, что большая часть команды, работавшей над созданием Windows NT, ранее работала в Digital Equipment Corporation. Они занимались в DEC разработкой инструментария для операционной системы VAX / VMS , и у них уже были навыки и готовый код для работы с исполняемыми файлами, представленными в формате Common Object File Format ( COFF ). Соответственно, формат COFF в слегка модифицированном виде был перенесен в Windows NT и получил название PE.

В «. NET Framework Glossary » сказано, что PE — это реализация Microsoft формата COFF . В то же время в [5] утверждается, что PE — это формат исполняемых файлов, а COFF — это формат объектных файлов . Вообще, мы можем наблюдать путаницу в документации Microsoft относительно названия формата. В некоторых местах они называют его COFF , а в некоторых — PE.

35 — Как маскируют расширение файла .exe на любое другое (pdf, png и т.д.)

Правда, можно заметить, что в новых текстах название COFF используется все меньше и меньше. Более того, формат PE постоянно эволюционирует. Например, несколько лет назад в Microsoft отказались от хранения отладочной информации внутри исполняемого файла, и поэтому теперь многие поля в структурах формата COFF просто не используются. Кроме того, формат COFF — 32-разрядный, а последняя редакция формата PE (она называется PE32+) может использоваться на 64-разрядных аппаратных платформах. Поэтому, видимо, дело идет к тому, что название COFF вообще перестанут использовать.

Интересно отметить, что исполняемые файлы в устаревших форматах NE и LE до сих пор поддерживаются Windows . Исполняемые файлы в формате NE можно запускать под управлением NTVDM (NT Virtual DOS Machine), а формат LE используется для виртуальных драйверов устройств ( VxD ).

Почему в названии формата PE присутствует слово » portable » («переносимый»)? Дело в том, что Windows NT была реализована не только для платформы Intel x86 , но и для платформ MIPS R4000, DEC Alpha и PowerPC . И во всех реализациях для хранения исполняемых файлов использовался формат PE. При этом речь не шла о достижении двоичной совместимости между этими платформами, то есть exe- файл , предназначенный для выполнения на платформе Intel x86 , нельзя было запустить на PowerPC . Важно понимать, что переносимость формата еще не означает переносимость исполняемых файлов, записанных в этом формате. Формат PE переносим в том смысле, что он слабо зависит от типа процессора и поэтому подходит для разных платформ (в том числе и для платформы . NET ).

Далее в этой главе мы не будем затрагивать 64-разрядный вариант формата PE, потому что в настоящее время сборки . NET хранятся в прежнем 32-разрядном формате. Однако отметим, что 64-разрядный PE очень слабо отличается от 32-разрядного. Основное отличие касается разрядности полей структур PE-файла.

Источник: intuit.ru

Исполняемые файлы имеют расширение какого типа? Наиболее распространенные

Многие пользователи компьютерных систем наверняка в той или иной степени сталкивались с понятием исполняемого файла программы. Исполняемые файлы не всегда, но довольно часто имеют расширение EXE, которое является общепринятым для операционных систем семейства Windows. Чтобы немного прояснить вопрос, связанный с расширениями, мы рассмотрим общую информацию об этих объектах, а также рассмотрим некоторые типы основных расширений.

Чем исполняемые файлы отличаются от других объектов

Исполняемые файлы: структура

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

Принцип работы

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

Исполняемые файлы программ: какое расширение они имеют?

Теперь перейдем к рассмотрению вопроса, связанного с расширениями. Разумеется, совершенно все типы рассмотреть не получится, это займет очень много времени. Мы отметим только наиболее распространенные и популярные варианты. Итак, расширение задается в зависимости от типа содержимого.

Так, например, в операционной системе типа Windows наиболее распространенные исполняемые файлы обладают расширением EXE. Это относится ко всем программам, которые рассчитаны на работу в среде данных операционных систем. Такие объекты содержат в себе машинные коды. Файлы BIN являются очень похожими. Пакетные файлы типа CMD, BAT и COM являются еще одним типом исполняемых файлов.

Первый тип в данном случае является пакетным файлом Windows. Файлы второго и третьего типа относятся к операционным системам семейства DOS. Многие из вас вероятно уже встречали файлы типа MSI иMSU. Это может быть установщик обновлений системы, или родной инсталлятор операционной системы Windows. Отдельную категорию файлов составляют макросы и скрипты.

Это файлы с расширениями JSE, JS, SCR,VBE, VBS, VB. Часто также встречаются файлы JAD иJAR, которые предназначены для установки приложений в мобильные устройства или использование в среде JAVA. В своем содержании такие объекты имеют уже не машинные коды, а коды виртуальных машин.

Какое расширение имеют исполняемые файлы в различных ОС?

Если внимательно посмотреть, то можно заметить, что в некоторых ОС встречаются довольно специфичные компоненты. Так, например, в операционной системе Windows имеется специальная категория исполняемых файлов. Вообще, в любой операционной системе можно найти как стандартные, так и специальные компоненты. Однако имеются и некоторые общие форматы, например, HTA, исполняемый документ HTML.

Они работают практически везде вне зависимости от используемого типа операционной системы. Что же касается других типов систем, то, например, в «маках» исполняемые файлы обладают расширением APP для программ и PKG для дистрибутивов. В операционных системах семейства Linux дело обстоит немного иначе.

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

Впрочем, в любой операционной системе даже на мобильных устройствах можно найти огромное число объектов данного типа. Не нужно далеко ходить. В той же операционной системе семейства Android исполняемый файл установщика имеет расширение APK. В яблочных устройствах исполняемые файлы имеют расширение IPA.

Заключение

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

Похожие статьи:

1. MiniTool Partition Wizard. Скачать бесплатно
2. Подключение телефонов через Nokia Suite
3. MathType. Скачать бесплатно
4. Секреты установки сторонних программ на Windows 7: отключение антивируса
5. GIGABYTE OC Guru 2 — программа для разгона видеокарт

Источник: computerologia.ru

Анатомия эльфов. Разбираемся с внутренним устройством ELF-файлов

Ес­ли в мире Windows исполня­емые фай­лы пред­став­лены в фор­мате Portable Executable (PE), то в Linux эта роль отве­дена фай­лам в фор­мате Executable and Linkable Format (ELF). Сегод­ня мы заг­лянем внутрь таких фай­лов, нем­ного поис­сле­дуем их струк­туру и узна­ем, как они устро­ены.

Сра­зу отме­чу, что в отли­чие от Windows в Linux от рас­ширения фай­ла не зависит прак­тичес­ки ничего (за сов­сем неболь­шим исклю­чени­ем). Тип и фор­мат фай­ла опре­деля­ется его внут­ренним содер­жимым и наличи­ем тех или иных атри­бутов, поэто­му фай­лы в фор­мате Executable and Linkable Format могут иметь любое рас­ширение.

Что нам понадобится

Во­обще, мож­но позави­довать людям, оби­тающим в мире Linux, — как пра­вило, в сис­теме «из короб­ки» идет боль­шое чис­ло ути­лит и прог­рамм, которые в Windows необ­ходимо где‑то искать и уста­нав­ливать допол­нитель­но, да еще и не всег­да бес­плат­но. В нашем слу­чае для ана­лиза ELF-фай­лов в Linux при­сутс­тву­ет впол­не сос­тоятель­ный арсе­нал встро­енных средств и ути­лит:

• readelf — с помощью этой ути­литы мож­но прак­тичес­ки пол­ностью прос­матри­вать все пота­енные мес­та ELF-фай­лов в удо­бочи­таемом виде;
• hexdump — прос­той прос­мот­рщик фай­лов в шес­тнад­цатерич­ном пред­став­лении (конеч­но, до hiew из мира Windows ему далеко, но, во‑пер­вых, он при­сутс­тву­ет в сис­теме по умол­чанию, а во‑вто­рых, дела­ет это совер­шенно бес­плат­но);
• strings — с помощью этой извес­тной ути­литы мож­но уви­деть име­на всех импорти­руемых (или экспор­тиру­емых) фун­кций, а так­же биб­лиотек, из которых эти фун­кции импорти­рова­ны, наз­вания сек­ций и еще мно­го чего инте­рес­ного;
• ldd — поз­воля­ет выводить име­на раз­деля­емых биб­лиотек, из которых импорти­руют­ся те или иные фун­кции, исполь­зуемые иссле­дуемой прог­раммой;
• nm — может показы­вать таб­лицу имен из сос­тава отла­доч­ной информа­ции, которая добав­ляет­ся в ELF-фай­лы при их ком­пиляции (эта отла­доч­ная информа­ция с помощью коман­ды strip может быть уда­лена из фай­ла, и в этом слу­чае ути­лита nm ничем не поможет);
• objdump — спо­соб­на вывес­ти информа­цию и содер­жимое всех эле­мен­тов иссле­дуемо­го фай­ла, в том чис­ле и в дизас­сем­бли­рован­ном виде.

Часть перечис­ленно­го (кро­ме hexdump и ldd) вхо­дит в сос­тав пакета GNU Binutils. Если это­го пакета в тво­ей сис­теме нет, его лег­ко уста­новить. К при­меру, в Ubuntu это выг­лядит сле­дующим обра­зом:

sudo apt install binutils

В прин­ципе, имея все перечис­ленное, мож­но уже прис­тупать к ана­лизу и иссле­дова­нию ELF-фай­лов без прив­лечения допол­нитель­ных средств. Для боль­шего удобс­тва и наг­ляднос­ти мож­но добавить к нашему инс­тру­мен­тарию извес­тный в кру­гах реверс‑инже­неров дизас­сем­блер IDA в вер­сии Freeware (этой вер­сии для наших целей будет более чем дос­таточ­но, хотя ник­то не зап­реща­ет вос­поль­зовать­ся вер­сиями Home или Pro, если есть воз­можность за них зап­латить).

Так­же неп­лохо было бы исполь­зовать вмес­то hexdump что‑то поудоб­нее, нап­ример 010 Editor или wxHex Editor. Пер­вый hex-редак­тор — дос­той­ная аль­тер­натива Hiew для Linux (в том чис­ле и бла­года­ря воз­можнос­ти исполь­зовать в нем боль­шое количес­тво шаб­лонов для раз­личных типов фай­лов, сре­ди них и шаб­лон для пар­синга ELF-фай­лов). Одна­ко он небес­плат­ный (сто­имость лицен­зии начина­ется с 49,95 дол­лара, при этом есть 30-днев­ный три­аль­ный пери­од).

Го­воря о допол­нитель­ных инс­тру­мен­тах, которые облегча­ют ана­лиз ELF-фай­лов, нель­зя не упо­мянуть Python-пакет lief. Исполь­зуя этот пакет, мож­но писать Python-скрип­ты для ана­лиза и модифи­кации не толь­ко ELF-фай­лов, но и фай­лов PE и MachO. Ска­чать и уста­новить этот пакет получит­ся тра­дици­онным для Python-пакетов спо­собом:

pip install lief

Подопытные экземпляры

В Linux (да и во мно­гих дру­гих сов­ремен­ных UNIX-подоб­ных опе­раци­онных сис­темах) фор­мат ELF исполь­зует­ся в нес­коль­ких типах фай­лов.

• Ис­полня­емый файл — содер­жит все необ­ходимое для соз­дания сис­темой обра­за про­цес­са и запус­ка это­го про­цес­са. В общем слу­чае это инс­трук­ции и дан­ные. Так­же в фай­ле может при­сутс­тво­вать опи­сание необ­ходимых раз­деля­емых объ­ектных фай­лов, а так­же сим­воль­ная и отла­доч­ная информа­ция. Исполня­емый файл может быть позици­онно зависи­мым (в этом слу­чае он гру­зит­ся всег­да по одно­му и тому же адре­су, для 32-раз­рядных прог­рамм обыч­но это 0x8048000 , для 64-раз­рядных — 0x400000 ) и позици­онно незави­симым исполня­емым фай­лом (PIE — Position Independent Execution или PIC — Position Independent Code). В этом слу­чае адрес заг­рузки фай­ла может менять­ся при каж­дой заг­рузке. При пос­тро­ении позици­онно незави­симо­го исполня­емо­го фай­ла исполь­зуют­ся такие же прин­ципы, как и при пос­тро­ении раз­деля­емых объ­ектных фай­лов.
• Пе­реме­щаемый файл — содер­жит инс­трук­ции и дан­ные, при этом они могут быть ста­тичес­ки свя­заны с дру­гими объ­ектны­ми фай­лами, в резуль­тате чего получа­ется раз­деля­емый объ­ектный или исполня­емый файл. К это­му типу отно­сят­ся объ­ектные фай­лы ста­тичес­ких биб­лиотек (как пра­вило, для ста­тичес­ких биб­лиотек имя начина­ется с lib и при­меня­ется рас­ширение *. a ), одна­ко, как мы уже говори­ли, рас­ширение в Linux прак­тичес­ки ничего не опре­деля­ет. В слу­чае ста­тичес­ких биб­лиотек это прос­то дань тра­диции, а работос­пособ­ность биб­лиоте­ки будет обес­печена с любым име­нем и любым рас­ширени­ем.
• Раз­деля­емый объ­ектный файл — содер­жит инс­трук­ции и дан­ные, может быть свя­зан с дру­гими переме­щаемы­ми фай­лами или раз­деля­емы­ми объ­ектны­ми фай­лами, в резуль­тате чего будет соз­дан новый объ­ектный файл. Такие фай­лы могут выпол­нять фун­кции раз­деля­емых биб­лиотек (по ана­логии с DLL-биб­лиоте­ками Windows). При этом в момент запус­ка прог­раммы на выпол­нение опе­раци­онная сис­тема динами­чес­ки свя­зыва­ет эту раз­деля­емую биб­лиоте­ку с исполня­емым фай­лом прог­раммы, и соз­дает­ся исполня­емый образ при­ложе­ния. Опять же тра­дици­онно раз­деля­емые биб­лиоте­ки име­ют рас­ширение *. so (от англий­ско­го Shared Object).
• Файл дам­па памяти — файл, который содер­жит образ памяти того или ино­го про­цес­са на момент его завер­шения. В опре­делен­ных ситу­ациях ядро может соз­давать файл с обра­зом памяти ава­рий­но завер­шивше­гося про­цес­са. Этот файл так­же соз­дает­ся в фор­мате ELF, одна­ко мы о такого рода фай­лах говорить не будем, пос­коль­ку задача иссле­дова­ния дам­пов и содер­жимого памяти дос­таточ­но объ­емна и тре­бует отдель­ной статьи.

Для наших изыс­каний нам желатель­но иметь все воз­можные вари­анты исполня­емых фай­лов из перечис­ленных выше, чем мы сей­час и зай­мем­ся.

Делаем исполняемые файлы

Не будем выдумы­вать что‑то свер­хориги­наль­ное, а оста­новим­ся на клас­сичес­ком хел­ловор­лде на С:

int main ( int argc , char * argv [] ) <
printf ( «Hello world» ) ;

Ком­пилиро­вать это дело мы будем с помощью GCC. Сов­ремен­ные вер­сии Linux, как пра­вило, 64-раз­рядные, и вхо­дящие в их сос­тав по умол­чанию средс­тва раз­работ­ки (в том чис­ле и ком­пилятор GCC) генери­руют 64-раз­рядные при­ложе­ния. Мы в сво­их иссле­дова­ниях не будем отдель­но вни­кать в 32-раз­рядные ELF-фай­лы (по боль­шому сче­ту отли­чий от 64-раз­рядных ELF-фай­лов в них не очень мно­го) и основные уси­лия сос­редото­чим имен­но на 64-раз­рядных вер­сиях прог­рамм. Если у тебя воз­никнет желание поэк­спе­римен­тировать с 32-раз­рядны­ми фай­лами, то при ком­пиляции в GCC нуж­но добавить опцию -m32 , при этом, воз­можно, пот­ребу­ется уста­новить биб­лиоте­ку gcc-multilib. Сде­лать это мож­но при­мер­но вот так:

sudo apt- get install gcc- multilib

Итак, назовем наш хел­ловорлд example. c (кста­ти, здесь как раз один из нем­ногих слу­чаев, ког­да в Linux рас­ширение име­ет зна­чение) и нач­нем с исполня­емо­го позици­онно зависи­мого кода:

gcc -no-pie example. c -o example_ no_ pie

Как ты уже догадал­ся, опция -no-pie как раз и говорит ком­пилято­ру соб­рать не позици­онно незави­симый код.

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

В целом мож­но выделить четыре эта­па работы GCC:

• преп­роцес­сирова­ние;
• тран­сля­ция в ассем­блер­ный код;
• пре­обра­зова­ние ассем­блер­ного кода в объ­ектный;
• ком­понов­ка объ­ектно­го кода.

Что­бы пос­мотреть на про­межу­точ­ный резуль­тат, к при­меру в виде ассем­блер­ного кода, исполь­зуй в GCC опцию -S :

gcc -S -masm = intel example. c

Об­рати вни­мание на два момен­та. Пер­вый — мы в дан­ном слу­чае не зада­ем имя выход­ного фай­ла с помощью опции -o (GCC сам опре­делит его из исходно­го, добавив рас­ширение *. s , что и озна­чает при­сутс­твие в фай­ле ассем­блер­ного кода). Вто­рой момент — опция -masm=intel , которая говорит о том, что ассем­блер­ный код в выход­ном фай­ле необ­ходимо генери­ровать с исполь­зовани­ем син­такси­са Intel (по умол­чанию будет син­таксис AThttps://xakep.ru/2022/05/11/elf-anatomy/» target=»_blank»]xakep.ru[/mask_link]