Вы когда-нибудь задумывались, что происходит внутри Linux после того, как вы вводите ./program в терминале и нажимаете Enter?

Что именно происходит дальше? Как ядро находит файл? Как загружает его в память? Кто вызывает main? И как на всё это посмотреть вживую?

Разберемся на примере пустой программы empty_sleep. Она ничего не делает, просто запускается и завершается через 30 секунд. В ней нет лишнего кода, поэтому все внимание будет сосредоточено на процессе загрузки. Всё, что увидим, относится к большинству динамически скомпилированных программ в Linux.

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

Что такое системные вызовы и при чём здесь strace

В Linux есть два режима работы: пользовательский и режим ядра. Обычные программы (включая подозрительные экземпляры) работают в пользовательском режиме. Они могут попросить ядро что-то сделать только через системные вызовы. Например: открыть файл, выделить память или завершиться.

strace – это инструмент, который перехватывает и показывает все системные вызовы программы. Мы будем использовать его, чтобы увидеть каждый шаг загрузки.

Пустая программа для эксперимента (почти пустая)

Исходный код программы empty_sleep:

#include <unistd.h>
int main() {
    sleep(30);
    return 0;
}

Она ничего не делает. Просто ждёт 30 секунд. Этого достаточно, чтобы заглянуть в её память, но об этом позднее. Сейчас проследим за процессом загрузки программы в память.

Запускаем strace и видим первый системный вызов

Запускаем strace:

strace ./empty_sleep

Первый системный вызов, который мы видим – execve:

execve("./empty_sleep", ["./empty_sleep"], 0x7fffffffe220 /* 35 vars */) = 0

Что здесь произошло?

Оболочка (bash) создала свою копию и вызвала системный вызов execve(), который заменяет текущий процесс новой программой. Ядро начинает загрузку ELF-файла. Вызов execve вернёт управление только в случае ошибки. Если всё нормально, управление будет передано динамическому компоновщику.

Внутри execve() ядро:

• читает ELF-заголовок,

• читает Program Headers (сегменты программы),

• для каждого LOAD-сегмента вызывает mmap,

• загружает интерпретатор (он же динамический компоновщик) из секции .interp,

• передаёт управление динамическому компоновщику.

Все эти вызовы mmap происходят внутри execve, поэтому не видим их по отдельности. Мы видим только сам факт успешного вызова.

Что такое динамический компоновщик

Динамический компоновщик (ld-linux.so) – это специальная программа, которую ядро загружает вместе с вашей динамически скомпилированной программой. Она подготавливает окружение: загружает нужные библиотеки, настраивает память, связывает вызовы функций (выполняет релокации).

Вы можете увидеть путь к динамическому компоновщику в ELF-файле с помощью readelf:

readelf -l empty_sleep | grep INTERP

INTERP         0x000350 0x0000000000000350 0x0000000000000350 0x00001c 0x00001c R   0x1
      [Запрашиваемый интерпретатор программы: /lib64/ld-linux-x86-64.so.2]

Файл /lib64/ld-linux-x86-64.so.2 и есть динамический компоновщик (далее по тексту – просто компоновщик).

Что делает динамический компоновщик

Сразу после execve управление переходит к компоновщику. Посмотрим, что он делает, через strace.

Настройка памяти

Первым делом компоновщик настраивает память для себя. Он получает текущий адрес конца кучи и выделяет анонимную память (8 КБ) для своих нужд:

brk(NULL)                               = 0x555555559000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7fbf000

Что такое куча? Это область для динамического выделения памяти во время выполнения программы. Куча растёт вверх (к большим адресам). Когда программе нужно больше памяти, она использует системный вызов brk(). В выводе выше, вызов brk(NULL) не выделяет память, а лишь запрашивает текущий адрес конца кучи. Так компоновщик узнаёт, где куча заканчивается, чтобы потом при необходимости её расширять.

Поиск библиотек

Компоновщик проверяет, нет ли библиотек для предзагрузки (используются для отладки):

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (Нет такого файла или каталога)

Обычно этого файла нет.

Затем компоновщик открывает кэш системных библиотек /etc/ld.so.cache, смотрит информацию о файле, отображает его в память и закрывает дескриптор:

openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=94483, ...}) = 0
mmap(NULL, 94483, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fa7000
close(3)                                = 0

Что делает компоновщик:

1. Открывает файл кэша.

2. Получает его размер (st_size=94483).

3. Отображает его в память через mmap.

4. Закрывает файловый дескриптор (память остаётся).

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

Какие библиотеки нужны программе

Посмотрим, какие библиотеки нужны программе empty_sleep:

readelf -d empty_sleep | grep NEEDED

0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libc.so.6]

Нужна только одна библиотека – стандартная libc.so.6. Именно её компоновщик сейчас будет загружать.

Загрузка библиотеки libc.so.6 в память

Сначала компоновщик открывает файл библиотеки и читает её ELF-заголовок – первые 832 байта:

openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\241\2\0\0\0\0\0"..., 832) = 832

Из заголовка компоновщик узнаёт:

• магическое число (\177ELF),

• тип файла,

• архитектуру,

• количество заголовков программ (Program Headers).

Затем компоновщик читает заголовки программ. Для libc.so.6 их 15, каждый размером 56 байт. Итого 840 байт начиная со смещения 64:

pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 840, 64) = 840

В этих 840 байтах хранится информация о сегментах типа LOAD, которые необходимо загрузить в память.

Сегменты VS секции

Не путайте сегменты и секции – это разные вещи.

Секции – логическая организация файла для статического компоновщика и отладчика: .text (код), .data (переменные), .rodata (константы).

Сегменты – физическая организация для загрузчика (части ядра). Загрузчику не важно, где в программе код, а где константы. Его интересует, какие данные нужно загрузить в память и какие права доступа у этих данных (чтение, запись, исполнение). Поэтому сегменты объединяют несколько секций с одинаковыми правами.

Отображение библиотеки в память

Компоновщик теперь знает всё о libc.so.6. Он получает информацию о файле (размер, права доступа) и начинает серию вызовов mmap:

mmap(NULL, 2055760, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff7db1000
mmap(0x7ffff7dd9000, 1474560, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7ffff7dd9000
mmap(0x7ffff7f41000, 339968, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x190000) = 0x7ffff7f41000
mmap(0x7ffff7f94000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e3000) = 0x7ffff7f94000
mmap(0x7ffff7f9a000, 52816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff7f9a000

Разберём первый вызов:

mmap(NULL, 2055760, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff7db1000

Он выделяет память для всей библиотеки с правами только на чтение. Размер запрошенной памяти больше, чем размер библиотеки (2055760 > 2014472), потому что размер выравнивается по границе страницы (обычно 4096 байт = 0x1000).

Остальные четыре вызова mmap перекрывают отдельные сегменты с правильными правами: исполняемый сегмент получает PROT_EXEC, сегмент с данными – PROT_WRITE.

После того как библиотека отображена в память, компоновщик закрывает файловый дескриптор:

close(3)                                = 0

Финальная настройка перед передачей управления

После загрузки библиотек компоновщик выполняет последние штрихи.

Настройка локального хранилища потоков (TLS)

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

mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7dae000
arch_prctl(ARCH_SET_FS, 0x7ffff7dae740) = 0

Защита памяти (GNU_RELRO)

Механизм GNU_RELRO делает некоторые области памяти только для чтения после того, как компоновщик выполнил релокации. Это защищает таблицу GOT от перезаписи:

mprotect(0x7ffff7f94000, 16384, PROT_READ) = 0
mprotect(0x555555557000, 4096, PROT_READ) = 0
mprotect(0x7ffff7ffb000, 8192, PROT_READ) = 0

Здесь можно заметить, что от перезаписи защищаются таблицы компоновщика, библиотеки libc.so.6 и, пока только предположительно, программы empty_sleep. По каким адресам загрузилась программа empty_sleep узнаем немного позднее.

Лимит стека и ASLR

Компоновщик задаёт лимит стека – защитный механизм от переполнения:

prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0

А также получает случайные байты для ASLR (рандомизация адресного пространства) – защитный механизм, который усложняет предсказание адресов функций:

getrandom("\xbf\x72\x35\x75\xe1\xd0\xd0\x63", 8, GRND_NONBLOCK) = 8

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

Освобождение временной памяти

Кэш системных библиотек /etc/ld.so.cache больше не нужен, память освобождается:

munmap(0x7ffff7fa7000, 94483)           = 0

Передача управления программе

После всех приготовлений компоновщик передаёт управление на _start – точку входа программы. _start – это не функция main, а служебная точка входа, которую добавляет компилятор. Она подготавливает стек, вызывает конструкторы глобальных объектов и только затем передаёт управление в main.

Посмотрим на точку входа empty_sleep с помощью readelf:

readelf -h empty_sleep

Там найдем строку:

Адрес точки входа:                 0x1040

В дизассемблированном коде можно увидеть, как _start подготавливает аргументы и вызывает _libc_start_main, а уже та – нашу главную функцию main.

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

В Linux есть виртуальная файловая система /proc. Для каждого запущенного процесса существует папка /proc/PID/, а файл maps внутри показывает, как распределена виртуальная память этого процесса.

Запустим empty_sleep в фоне и посмотрим:

./empty_sleep &
PID=$!
cat /proc/$PID/maps

Вывод (сокращённо):

555555554000-555555555000 r--p 00000000 00:3a 6       /mnt/.../empty_sleep
555555555000-555555556000 r-xp 00001000 00:3a 6       /mnt/.../empty_sleep
555555556000-555555557000 r--p 00002000 00:3a 6       /mnt/.../empty_sleep
555555557000-555555558000 r--p 00002000 00:3a 6       /mnt/.../empty_sleep
555555558000-555555559000 rw-p 00003000 00:3a 6       /mnt/.../empty_sleep
7ffff7db1000-7ffff7dd9000 r--p 00000000 08:01 263133  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7dd9000-7ffff7f41000 r-xp 00028000 08:01 263133  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7f41000-7ffff7f94000 r--p 00190000 08:01 263133  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7f94000-7ffff7f98000 r--p 001e3000 08:01 263133  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7f98000-7ffff7f9a000 rw-p 001e7000 08:01 263133  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7f9a000-7ffff7fa7000 rw-p 00000000 00:00 0
7ffff7fc7000-7ffff7fc8000 r--p 00000000 08:01 263130  /usr/.../ld-linux-x86-64.so.2
7ffff7fc8000-7ffff7ff0000 r-xp 00001000 08:01 263130  /usr/.../ld-linux-x86-64.so.2
7ffff7ff0000-7ffff7ffb000 r--p 00029000 08:01 263130  /usr/.../ld-linux-x86-64.so.2
7ffff7ffb000-7ffff7ffd000 r--p 00034000 08:01 263130  /usr/.../ld-linux-x86-64.so.2
7ffff7ffd000-7ffff7ffe000 rw-p 00036000 08:01 263130  /usr/.../ld-linux-x86-64.so.2
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0       [stack]

Каждая строка описывает одну область памяти. Из дампа видно:

• саму программу empty_sleep (адреса 555555554000-555555559000),

• библиотеку libc.so.6 (адреса 7ffff7db1000-7ffff7fa7000),

• динамический компоновщик ld-linux-x86-64.so.2 (адреса 7ffff7fc7000-7ffff7ffe000),

• стек (7ffffffde000-7ffffffff000),

• защищенные от перезаписи таблицы GOT программы, компоновщика и библиотеки libc.so.6 (адреса 555555557000-555555558000, 7ffff7ffb000-7ffff7ffd000, 7ffff7f94000-7ffff7f98000).

Теперь вы можете своими глазами увидеть всё, что мы разбирали в системных вызовах mmap.

Что узнали и чему научились

Мы вместе проследили путь от системного вызова execve до точки входа в программу empty_sleep (функции _start):

1. Ядро загружает программу и динамический компоновщик.

2. Компоновщик настраивает память, ищет библиотеки через /etc/ld.so.cache.

3. Компоновщик открывает, читает и отображает libc.so.6 в память серией вызовов mmap.

4. Компоновщик настраивает TLS, защищает память через GNU_RELRO, задаёт лимит стека и получает случайные байты для ASLR.

5. Компоновщик освобождает временную память и передаёт управление на _start.

6. Функция _start вызывает _libc_start_main, который вызывает main.

А главное – мы научились наблюдать за всем этим в реальном времени с помощью strace и заглядывать в финальную карту памяти через /proc/pid/maps.

Что дальше

Инструмент strace показывает системные вызовы – обращения к ядру. Но он не показывает вызовы обычных библиотечных функций, таких как strcmp, printf, memcpy. Для этого есть другой инструмент – ltrace. Он перехватывает вызовы функций из динамических библиотек и может показать, например, какой пароль ожидает программа.

Но это уже тема отдельной статьи.

P.S.

У меня к вам просьба. Я написал этот материал на основе своего бесплатного курса «Белый хакер: анализ файлов в Linux» для начинающих ИБ-специалистов и студентов технических специальностей. В нем даются базовые навыки анализа: определение типа файла, поиск вшитых файлов и очевидных артефактов, знакомство со структурой ELF-формата и загрузка программы в память. Но мне не хватает взгляда со стороны – от тех, кто уже хорошо разбирается в теме.

Посмотрите на текст критически:

1. Где я упростил до потери смысла?

2. Что важное упустил?

3. Как бы вы объяснили эту тему новичку?

Курс бесплатный, я его постоянно дорабатываю. Любая критика приветствуется. Спасибо, что дочитали.