Зачем исполняемому файлу нужны секции: простое объяснение с примерами

Исполняемый файл устроен не как сплошной массив байтов, а как набор участков с разными правами и назначением — секций. Секции нужны потому, что процессор и операционная система требуют разделять код, который можно только выполнять, данные, которые можно читать и менять, и служебную информацию, по которой программа вообще запускается. Если бы всё лежало в одном неразделённом куске памяти, система не смогла бы запретить запись в код, защитить константы от изменения или лениво подгружать файл с диска.

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

Что такое секция исполняемого файла

Секция — это непрерывный участок внутри файла (а затем и в адресном пространстве процесса), объединённый общим назначением и общими правами доступа. В терминах формата PE, используемого в Windows, такие участки называются sections, в ELF-формате Linux есть близкое понятие segments — сегментов программы, которые описываются программным заголовком. Названия различаются, идея одна: файл размечен на области, каждая из которых имеет свой смысл и свои атрибуты.

У каждой секции обычно указаны:

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

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

Основные секции и их назначение

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

Категория	Типичные имена	Права	Зачем нужна
Машинный код	.text (ELF), .text (PE)	чтение + исполнение	Инструкции процессора; запись запрещена ради защиты от модификации кода
Инициализированные данные	.data	чтение + запись	Глобальные и статические переменные с начальным значением
Неинициализированные данные	.bss	чтение + запись	Переменные без начального значения; места в файле не занимают
Константы и ресурсы только для чтения	.rodata (ELF), .rdata (PE)	только чтение	Строковые литералы, таблицы переходов, константы
Релокации и импорт/экспорт	.idata, .edata, .reloc (PE); .dynsym, .rela.* (ELF)	зависит от формата	Связывание с библиотеками и подстройка адресов при загрузке
Отладочная и метаинформация	.debug_*, .symtab, .comment	обычно не загружается в память	Символы для отладчика, сведения о сборке

Отдельно стоит пояснить секцию .bss: она экономит размер файла. Если у вас есть массив на десять мегабайт, заполненный нулями, хранить десять мегабайт нулей на диске бессмысленно. Достаточно записать «здесь будет 10 МБ нулей», а нужную память загрузчик выделит при старте процесса. Поэтому два исполняемых файла с одинаковым объёмом данных могут заметно отличаться по размеру именно за счёт этой оптимизации.

Чем секция отличается от сегмента

В ELF-файлах есть два параллельных взгляда на разметку. Секции (section headers) — это детальное деление для компоновщика и отладчика: там лежат таблицы символов, отладочная информация, отдельные мелкие области. Сегменты (program headers) — это то, что реально загружает ядро: один сегмент может объединять несколько секций с одинаковыми правами. На практике важно одно: защита памяти работает на уровне страниц и сегментов, а не отдельных секций, поэтому соседние секции с одинаковыми атрибутами часто оказываются в одной области памяти.

В PE-формате Windows разделение проще: таблица секций одновременно служит и для компоновщика, и для загрузчика, а права доступа задаются комбинацией характеристик секции.

Как загрузчик использует секции при запуске программы

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

1. Операционная система читает заголовок файла и убеждается, что формат ей понятен, а целевая архитектура совпадает с текущей.
2. Загрузчик создаёт адресное пространство нового процесса и отображает в него сегменты файла с учётом указанных виртуальных адресов и прав доступа.
3. Если файл зависит от динамических библиотек, подключается системный загрузчик библиотек: он резервирует место под импортируемые функции и заполняет таблицы связывания.
4. Применяются релокации — корректировка адресов, если модуль загрузился не по предпочитаемому адресу.
5. Выполняется стартовый код среды исполнения, инициализируются глобальные переменные, после чего управление передаётся точке входа программы.

Благодаря тому, что каждый участок размечен заранее, загрузчику не нужно анализировать содержимое файла «по смыслу». Он просто копирует (точнее, отображает через механизм страничной памяти) готовые блоки по готовым адресам. Это ещё одна практическая выгода секций: запуск становится быстрым, а страницы с кодом могут подгружаться с диска лениво, по мере обращения, и разделяться между несколькими процессами, использующими одну программу или библиотеку.

Почему нельзя обойтись одной общей областью

Гипотетический файл без секций означал бы одну область памяти с правами «чтение, запись, исполнение» сразу. Это ломает сразу несколько вещей:

• Безопасность. Если код можно перезаписывать, любая ошибка работы с памятью превращается в возможность внедрить и выполнить произвольный код. Разделение W^X («либо запись, либо исполнение, но не вместе») считается базовой защитой уже много лет.
• Совместное использование памяти. Страницы с кодом идентичны для всех процессов, запустивших одну программу, поэтому система держит их в физической памяти в одном экземпляре. Смесь кода и изменяемых данных такое разделение сделала бы невозможным.
• Экономия ресурсов. Без секции .bss нулевые массивы пришлось бы хранить в файле; без разделения на «только чтение» нельзя было бы защитить константы от случайной порчи.
• Отладка и анализ. Отладчик, профилировщик и антивирус опираются на разметку, чтобы понять, где код, где данные и какие символы чему соответствуют.

Практические следствия для разработчика

Выравнивание и размер файла

Секции выравниваются по границам, кратным размеру страницы памяти (обычно 4 КБ). Из-за этого даже маленькая программа занимает больше места, чем сумма её кода и данных: каждая секция округляется вверх до границы. Чрезмерное дробление на множество мелких секций раздувает файл и фрагментирует память, поэтому компиляторы по умолчанию объединяют похожие данные, а тонкая настройка секций применяется осознанно.

Атрибуты секций и классы ошибок

Неправильные атрибуты дают характерные сбои:

• запись в область «только чтение» вызывает аппаратное исключение — в Linux это сигнал SIGSEGV, в Windows — нарушение доступа;
• исполнение данных при запрещённом бите исполнения даёт тот же результат, но уже из-за политики NX/DEP;
• отсутствие релокаций у библиотеки, загруженной не по ожидаемому адресу, приводит к ошибке загрузки или некорректным вызовам.

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

Кастомные секции

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

Секции и безопасность

Разметка на секции — фундамент нескольких механизмов защиты, которые работают незаметно для обычного пользователя:

• NX/DEP — запрет исполнения областей данных; реализуется через отсутствие флага исполнения у соответствующих сегментов.
• ASLR — рандомизация базовых адресов; возможна благодаря релокациям, которые описаны в отдельных секциях файла.
• Защита от перезаписи кода — страницы .text доступны только на чтение и исполнение, поэтому переполнение буфера в данных не позволяет изменить инструкции.
• Control Flow Guard и подобные механизмы — используют таблицы целей переходов, размещённые в защищённых областях.

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

Как посмотреть секции самостоятельно

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

1. В Linux используйте утилиту чтения заголовков ELF (например, readelf с ключом вывода секций) для любого бинарника из системы: вы увидите список секций, их размеры, адреса и флаги.
2. В Windows подойдёт утилита дампа PE-заголовков из набора инструментов разработчика либо сторонние просмотрщики форматов: они покажут таблицу секций с виртуальными размерами и характеристиками.
3. Сравните два файла: небольшой консольный пример и крупную программу. Обратите внимание, как растут .text и .data, сколько места занимают отладочные секции в сборке с символами и насколько меньше файл без них.

Такой взгляд снимает ощущение «магии»: становится видно, что исполняемый файл — это структурированный документ с оглавлением, а не монолитный blob.

Частые вопросы

Можно ли изменить содержимое секции в готовом файле?

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

Почему секций так много в отладочной сборке?

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

Влияет ли количество секций на производительность?

Прямое влияние минимально: загрузчик обрабатывает заголовки один раз при старте. Косвенное влияние есть через выравнивание (больше секций — больше неиспользуемых промежутков) и через организацию памяти: удачно сгруппированный «горячий» код в компактной области лучше ложится в кэш инструкций.

Что запомнить

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