Виконані файли проти спільних об'єктів

Я щось помітив, роблячи find /bin -exec file {} \;:

fileкоманда повідомляє деякі записи в /binце shared objects, в той час як інші , як executables. Наприклад,

/ bin / ntfsck:
64-розрядний об'єкт спільного LSB ELF , x86-64, версія 1 (SYSV),
динамічно пов'язаний (використовує спільні libs), для GNU / Linux 2.6.24, BuildID [sha1] = 312d93fd0d8653e7236a61db2e67b93c63225a00, позбавлений

Той самий звіт для gawk

/ usr / bin / gawk:
64-розрядний об'єкт спільного використання LSB , x86-64, версія 1 (SYSV),
динамічно пов'язаний (використовує спільні lib), для GNU / Linux 2.6.24,
BuildID [sha1] = 76bb13aac7e212164bd6e0d7b8a5d92db44543c9, позбавлений

На відміну fileвід /bin/echo:

/ bin / echo:
64-розрядний виконуваний файл LSB ELF , x86-64, версія 1 (SYSV),
динамічно пов'язаний (використовує спільні lib), для GNU / Linux 2.6.24,
BuildID [sha1] = 193e75fc13e9c4599e772b8d79125a5934cf601c, позбавлений

По суті, я хочу знати, яка різниця між executableфайлами та shared objectфайлами.

Тл; д-р

Немає різниці, окрім того, що компільований виконуваний файл може бути пов’язаний із спільним об’єктом, а не проти виконуваного файлу.

Загалом, є два способи складання ¹ виконуваного файлу:

• Використовуючи статичне посилання: компілюються зовнішні бібліотеки, що входять до вихідного коду, і складена бібліотека (або об'єкт з точки зору зв’язку) додається до самого виконуваного файлу;
• Використовуючи динамічне посилання: зовнішні бібліотеки, включені до вихідного коду, компілюються, але посилання на компільовану бібліотеку (або об'єкт з точки зору лінкера) додається у виконуваний файл (а складені бібліотеки / об'єкти завантажуються лінкером під час виконання, якщо потрібні);

Є переваги / недоліки у використанні кожного з цих методів, але це не суть питання;

• /bin/ntfsckі /usr/bin/gawkє спільними об'єктами: це означає, що виконуваний файл може бути складений і потім пов'язаний з ними для використання їх функціональних можливостей;
• /bin/echoє виконуваним файлом: це означає, що виконуваний файл може бути не зібраний, а потім пов'язаний з ним для використання його функціональних можливостей;

Так /bin/ntfsckі /usr/bin/gawkтехнічно скомпільовані бібліотеки (або об'єкти в перспективі компоновщика), але, як один може бути forsaw, ніщо не заважає загальний об'єкт від того , як запустити виконуваний файл.

На бічній записці також зауважте, що fileзвіти (для кожного з них):

динамічно пов'язаний (використовує спільні лібри)

Це означає, що кожен з них динамічно пов'язаний (і, ймовірно, використовує) й інші спільні об'єкти.

_{1. "Компілювати", призначений для його більш широкого прийняття, що включає попередню обробку, компіляцію та зв'язування.}

Інша відмінність полягає в тому, що виконувані файли мають визначене зміщення адреси вхідної точки, тобто 0x08048000 для i386, 0x00400000 для x86 та 0x00010000 для arm.

Файл спільного використання об'єкта може бути бібліотекою, але також виконуваним файлом. Будучи виконуваним, такого компенсації не існує. Виконавчим спільним об'єктом , так би мовити, є позиційний незалежний виконуваний файл (PIE), що використовує рандомізацію макетів адресного простору (ASLR). Таким чином, переглядаючи файл / proc / pid / maps, ви помітите, що розташування завантажених сегментів відрізняється в кожному виконанні на відміну від стандартних виконуваних файлів.

Ідея цієї функції полягає в додаванні безпеки виконуваним файлам, заважаючи зловмисникам виконувати атаки програмування, орієнтовані на повернення. Багато обслуговуючого персоналу вирішили створити пакети з включеною PIE як типова, наприклад, з Fedora 23 або з Ubuntu 17.10.