Как анализировать файлы и бинарники в Linux: file, ELF, objdump и другие инструменты

Быстрая навигация

• Идентификация типов файлов
• Команда file
• file с бинарными файлами
• Почему исполняемый файл может быть большим
• Заголовок ELF
• objdump — детальный разбор
• Компиляция и линковка
• Ограничения и когда методы не работают
• Альтернативные инструменты
• Чек-листы и playbook для анализа
• Краткое руководство по командам (шпаргалка)

Определение задач статьи

Цель — дать системный набор приёмов для быстрого и углублённого анализа файлов в Linux. Подход применим как к документам и медиа, так и к бинарным объектам, исполняемым файлам и библиотекам.

Важно: здесь рассматриваются инструменты командной строки, доступные в большинстве современных дистрибутивов Linux.

Идентификация типов файлов

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

Опоры для определения типа файла:

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

Пример: PNG всегда начинается с набора байтов, по которым однозначно определяется формат. Windows полагается на расширение; Linux проверяет содержимое.

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

Команда file — просмотр типа файла

Команда file читает «магические» заголовки и внутреннюю структуру, затем выдаёт наиболее вероятный тип и дополнительную информацию.

Примерный рабочий процесс:

ls -hl

Вывод покажет содержимое каталога и размеры файлов в удобочитаемом виде.

Запросы к file:

file build_instructions.odt
file build_instructions.pdf
file COBOL_Report_Apr60.djvu

file часто указывает на версию формата (например, PDF 1.5). Даже если переименовать файл и дать расширение .xyz, file всё равно увидит реальный формат.

file полезен для медиафайлов — он сообщает кодек, разрешение, битрейт и т. п.:

file screenshot.png
file screenshot.jpg
file Pachelbel_Canon_In_D.mp3

Даже текстовые файлы не судят по расширению. Файл с расширением .c не станет автоматически источником на C, если в нём просто произвольный текст:

file function+headers.h
file makefile
file hello.c

file и бинарные файлы

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

Пример набора файлов в директории: исполняемые файлы “hello” и “wd”, объектный файл “wd.o” и перекомпилированный Windows-исполняемый “watch.exe”.

file wd
file wd.o
file hello
file watch.exe

Интерпретация вывода:

• watch.exe — PE32+ (Windows, 64‑бит, консольная программа). PE = Portable Executable.
• wd, hello — ELF (Executable and Linkable Format) файлы.
• wd.o — ELF relocatable (объектный файл).

Object-файлы — relocatable. Это означает, что код внутри не привязан к определённому адресу в памяти. Линкер собирает объектные файлы и выдаёт исполняемый файл. В некоторых случаях исполняемый файл помечается как динамический (ET_DYN), чтобы поддерживать релокацию и рандомизацию адресного пространства.

Термины:

• Executable and Linkable Format (ELF) — формат исполняемых файлов и библиотек в Unix‑подобных ОС.
• Relocatable — объектный файл, подразумевающий возможность загрузки по разным адресам.
• PIE — Position Independent Executable, исполняемый файл без фиксированного адреса загрузки.
• ASLR — Address Space Layout Randomization, техника безопасности для рандомизации адресов в памяти.

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

gcc -o hello -no-pie hello.c

После этого file покажет тип ET_EXEC (обычный исполняемый файл). Размер может не измениться, но поведение загрузки изменится — программа загружается по фиксированному адресу и теряет преимущества ASLR.

Почему исполняемый файл может быть большим

Пример: исходник hello.c — ~120 байт, а полученный бинарник — 17 КБ. Что добавляет массу?

Основные причины роста размера исполняемого файла:

• Заголовки ELF и таблицы секций.
• Служебные строки и символы (если не strip). Используется для отладки и указания зависимостей.
• Статическая линковка библиотек (если она применяется).
• Включённые данные времени выполнения (инициализация, таблицы переходов, константы).
• Данные от динамического загрузчика и символы импорта/экспорта.

Быстрое исследование содержимого бинарника можно сделать через команду strings и ldd.

strings hello | less
ldd hello

ldd показывает зависимости от общих библиотек. Пример вывода (с пояснениями):

• linux-vdso.so. — VDSO (Virtual Dynamic Shared Object) — механизм ядра для предоставления быстрого доступа к некоторым функциям ядра без системного вызова.
• libc.so.6 — GNU C Library.
• /lib64/ld-linux-x86-64.so.2 — динамический загрузчик, который разрешает и связывает зависимости во время запуска.

VDSO и динамический загрузчик взаимодействуют с ASLR: динамический загрузчик и библиотеки могут быть загружены по произвольным адресам для повышения безопасности.

Заголовок ELF: что внутри и как читать

ELF-файл начинается с магической последовательности: 0x7F ‘E’ ‘L’ ‘F’. Далее идут параметры формата:

• Class (1=32, 2=64) — битность.
• Data — порядок байтов (endianness).
• Version — версия формата.
• OS/ABI и ABI Version — интерфейс прикладного двоичного уровня.
• Type — тип ELF (ET_REL, ET_EXEC, ET_DYN).
• Machine — архитектура (например, x86-64).
• Entry Point Address — адрес старта выполнения.

Команда для чтения заголовка:

readelf -h hello

Для быстрого просмотра первых байтов используйте hexdump:

hexdump -C -n 8 hello

Это покажет первые 8 байтов и ASCII‑представление, где будет «7f 45 4c 46» (“.ELF”).

Что ещё смотреть в ELF

• Таблица программных заголовков (Program Headers) — описывает сегменты для загрузчика.
• Таблица секций (Section Headers) — содержит секции .text, .data, .bss, .rodata, .symtab и др.
• Символы и таблицы релокаций — важны для анализа зависимостей и отладки.

Команды для этих задач:

readelf -l hello     # program headers
readelf -S hello     # section headers
readelf -s hello     # symbol table

objdump и подробный дизассемблированный вид

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

objdump -d hello | less

• -d — дизассемблирует исполняемые секции.
• Можно применять фильтры, указывать конкретные секции или адреса.

Вывод содержит адреса, машинный код в шестнадцатеричном формате и ассемблерную расшифровку.

Дизассемблирование полезно для:

• Аудита безопасности и поиска уязвимостей.
• Понимания поведения бинарника без исходников.
• Реверс-инжиниринга и отладки.

Компиляция и линковка — что влияет на содержимое бинарника

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

• Опции компилятора (optimizations: -O0, -O2, -Os и т. п.).
• Включение отладочной информации (-g).
• Статическая или динамическая линковка библиотек (-static).
• Поддержка PIE и позиционной релокации (-fPIE, -no-pie).
• Стриппинг символов (strip) для уменьшения размера.

Примеры:

gcc -O2 -fPIE -pie -o myapp main.c
strip myapp

Если статически линковать крупные библиотеки, размер исполняемого резко вырастет. Если динамически — размер меньше, но нужна совместимая среда выполнения.

Ограничения и случаи, когда методы не работают

Важно понимать границы применимости описанных инструментов:

• file иногда ошибочно классифицирует сильно модифицированные или зашифрованные форматы.
• Стрипы и обфускация усложняют чтение символов и дизассемблирование.
• Пакованные бинарники (upx, custom packers) скрывают реальное содержимое; сначала их нужно распаковать.
• Файлы с нестандартной магической строкой (приватные форматы) не будут корректно распознаны.

Контрпример: зашифрованный или упакованный исполняемый файл может выглядеть как “data” по file и не раскрываться readelf/objdump до распаковки.

Альтернативы и дополняющие инструменты

• hexdump, xxd — для побайтового просмотра.
• readelf — ELF‑специфичный анализ.
• objdump — дизассемблирование и просмотр секций.
• strings — поиск читаемых ASCII/UTF‑8 строк.
• ldd — показ зависимостей динамических библиотек.
• ltrace/strace — трейс системных/библиотечных вызовов при выполнении.
• file(1) с расширенными базами сигнатур — можно обновлять magic-базы.
• upx — распаковка упакованных бинарников.

Ментальные модели и heuristics

• Расширение — подсказка, но не истина. Всегда проверяйте магию внутри.
• «Большой» бинарник = либо много данных, либо статическая линковка, либо отладочная информация.
• Если file говорит ET_DYN, а вы не собирали под shared, думайте о PIE/ASLR.
• Если ldd показывает /lib64/ld-*, значит нужен динамический загрузчик и запускаемая среда.

Чек-лист для анализа бинарника (роль: инженеры безопасности / разработчики)

1. Проверка основ:
   • file <файл>
   • ls -hl <файл>
   • hexdump -C -n 16 <файл>
2. ELF‑инспекция:
   • readelf -h <файл>
   • readelf -l <файл>
   • readelf -S <файл>
3. Символы и зависимости:
   • readelf -s <файл>
   • ldd <файл> (если динамический)
4. Контент и строки:
   • strings <файл> | less
5. Дизассемблирование:
   • objdump -d <файл> | less
6. Поведение при запуске (в песочнице):
   • strace -f -o trace.txt <./файл>
   • ltrace <./файл>
7. Если файл упакован:
   • upx -d <файл> (или соответствующий unpacker)
8. Итог и отчёт:
   • сформировать краткий отчёт: тип, зависимости, уязвимости, рекомендации

Плейбук: шаги для быстрого анализа неизвестного файла

1. Сохраняйте оригинал в read-only копии.
2. Запустите базовые проверки: file, ls, hexdump.
3. Если это ELF: readelf -h, -l, -S.
4. Проверьте зависимости: ldd.
5. Поиск текстов: strings.
6. Дизассемблирование при необходимости: objdump -d.
7. Запуск в контролируемой среде (контейнер, chroot, VM) с трассировкой.
8. Если упакован или зашифрован — попытка распаковки.
9. Сформируйте отчёт с рекомендациями по безопасности и совместимости.

Пример команд в порядке запуска:

cp suspect /tmp/sandbox/
cd /tmp/sandbox
file suspect
ls -hl suspect
hexdump -C -n 64 suspect
if file says ELF:
  readelf -h suspect
  readelf -S suspect
  ldd suspect || echo "not dynamic"
strings suspect | less
objdump -d suspect | less
# запуск в песочнице
strace -f -o trace.txt ./suspect

Критерии приёмки

1. Файл корректно классифицирован (file + hexdump).
2. Зависимости перечислены и доступны в целевой среде.
3. Отсутствие нежелательных статически вложенных библиотек или секретов в строках.
4. Исполняемый файл соответствует политике безопасности (PIE/ASLR при необходимости).
5. Отчёт содержит рекомендации по уязвимостям и совместимости.

Быстрая шпаргалка команд (Cheat sheet)

• file — определить тип файла
• hexdump -C -n — посмотреть первые N байт с ASCII
• strings — извлечь читаемые строки
• ldd — показать динамические зависимости
• readelf -h/-l/-S/-s — просмотреть заголовки, секции, символы
• objdump -d — дизассемблировать
• strace -f -o trace.txt <./file> — отследить системные вызовы
• ltrace <./file> — отследить вызовы библиотек
• upx -d — распаковать UPX

Факт-бокс: ключевые понятия

• ELF — стандартный формат исполняемых файлов в Unix-системах.
• PE — формат исполняемых файлов Windows.
• PIE — исполняемый файл с поддержкой позиционной релокации.
• ASLR — рандомизация адресного пространства для повышения безопасности.
• VDSO — совместно используемый виртуальный объект ядра для оптимизации некоторых вызовов.

Миграция и совместимость

• Если бинарник предназначен для x86_64, он не запустится на ARM без эмуляции.
• Переезд между дистрибутивами требует совместимости версий libc и динамических библиотек.
• Статическая линковка уменьшает зависимость от среды, но увеличивает размер и усложняет обновления безопасности.

Безопасность и приватность

• Никогда не запускайте подозрительный бинарник на хостовой системе без изоляции (VM/контейнер).
• Проверяйте строки на наличие жёстко зашитых ключей или паролей.
• Статическая линковка может включать старые уязвимые версии библиотек.

Пример: анализ “hello”

1. file hello → ELF 64-bit LSB shared object, констатация PIE/ET_DYN.
2. readelf -h hello → проверить заголовок, Entry Point, Type.
3. ldd hello → показать libc, ld-linux, linux-vdso.
4. strings hello → найти “Hello, Geek world!” и другие служебные строки.
5. objdump -d hello → изучить точки входа и вызовы функций libc.

Edge cases: галерея наиболее хитрых случаев

• Упакованный бинарник: file показывает “data”
• Полностью статически слинкованный исполняемый: большой размер, нет ldd вывода
• Binaries compiled for other OS: file укажет PE или Mach-O
• Скрипт с верхней строкой shebang: file покажет ASCII text и укажет тип скрипта

1‑строчный глоссарий

• Магические байты — маркеры формата в начале файла.
• ELF — формат исполняемых файлов в Unix.
• PE — формат Windows.
• PIE — позиционно-независимый исполняемый.
• ASLR — рандомизация адресов для безопасности.
• VDSO — оптимизация вызовов ядра.

Короткое объявление для команды (100–200 слов)

Эта заметка — практическое руководство по анализу файлов в Linux с помощью file, readelf, objdump и вспомогательных утилит. Мы разъясняем, как быстро определить тип файла, как изучить ELF‑заголовки, как найти зависимости и что делать, если бинарник упакован или предназначен для другой архитектуры. Включён пошаговый плейбук, чек‑лист для инженера и безопасные практики запуска подозрительных исполняемых файлов в изолированной среде. Материал полезен разработчикам, инженерам безопасности и системным администраторам.

Социальный превью (Open Graph suggestions)

OG title: Анализ файлов и бинарников в Linux — file, ELF, objdump OG description: Быстрый и полный набор приёмов для определения типа файла, анализа ELF, поиска зависимостей и безопасного запуска бинарников.

Итог

• file — надёжный первый шаг для определения формата файла.
• readelf, objdump и hexdump дают структурный и байтовый контекст.
• strings и ldd помогают понять зависимости и потенциальные утечки строк.
• Всегда анализируйте бинарники в безопасной среде и используйте приведённый плейбук и чек-листы для повторяемых процессов.

Краткий план действий:

1. file → 2. readelf → 3. ldd → 4. strings → 5. objdump → 6. запуск в песочнице

Если вы хотите, я могу:

• Подготовить шаблон отчёта для анализа бинарников.
• Сгенерировать mermaid‑диаграмму процесса анализа.
• Подготовить готовый скрипт, который автоматизирует вышеуказанную последовательность команд.