ldd · readelf · LIEF

Контекст Это связка инструментов бинарного анализа ELF, которая работает с готовым артефактом, а не с исходниками или манифестом. Когда сборочный процесс не отдал метаданных (нет Conan/vcpkg, есть только g++ и системные библиотеки), состав восстанавливают по самому бинарю: какие .so он требует, какие символы импортирует, что зашито в секции. Это «последняя инстанция» инвентаризации C/C++.

Для чего

• ldd — показывает, какие разделяемые библиотеки будут загружены динамическим линковщиком и куда они разрешаются на данной машине.
• readelf — читает структуру ELF напрямую: динамическую секцию, записи DT_NEEDED, RPATH/RUNPATH, таблицу символов — без запуска бинаря.
• LIEF — библиотека (Python/C++) для программного разбора и модификации ELF/PE/Mach‑O; нужна, когда разбор надо встроить в автоматический пайплайн и собрать факты в структуру.

Как применяют

Динамические зависимости из самой ELF‑секции (безопаснее, чем ldd):

readelf -d ./app | grep NEEDED
#  0x0000000000000001 (NEEDED)  Shared library: [libssl.so.3]
#  0x0000000000000001 (NEEDED)  Shared library: [libcrypto.so.3]
ldd ./app                       # разрешение в реальные пути на этой машине

Программный сбор через LIEF (вход для генератора фактов):

import lief
b = lief.parse("./app")
needed = [e.name for e in b.dynamic_entries if e.tag == lief.ELF.DYNAMIC_TAGS.NEEDED]
# ['libssl.so.3', 'libcrypto.so.3', 'libz.so.1']

Дальше libssl.so.3 маппится на DEB‑координаты: dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.3.

Сильные стороны

• Работают с фактом, а не с декларацией: DT_NEEDED — это то, что реально потребуется при загрузке, в отличие от find_package/-lssl.
• Не требуют исходников и сборочного окружения — применимы к чужому или унаследованному бинарю.
• readelf (и LIEF) читают ELF без запуска кода, что безопасно для непроверенного артефакта; LIEF легко встраивается в автоматическую обработку.

Ограничения

• Статическая линковка — слепая зона: вшитый .a не оставляет записи DT_NEEDED, компонент просто исчезает; нужен build‑scan или поиск сигнатур/строк версий.
• ldd фактически запускает загрузчик и отражает разрешение на текущей машине — на другой состав путей и версий будет иным; для непроверенного бинаря ldd не запускают.
• readelf/LIEF дают имя .so (libssl.so.3), но не версию пакета — нужен отдельный шаг маппинга на dpkg/apt; для stripped‑бинарей символьной информации почти нет.

Offline / on-premise

Да. Все три инструмента локальны и не обращаются в сеть: ldd/readelf входят в binutils/glibc, LIEF ставится из колеса Python. Полностью применимы в закрытом контуре; единственное внешнее звено — обновляемая база соответствий .so → пакет, которая берётся из локального зеркала дистрибутива.

Связанные темы

М09 C/C++ legacy · П22. ELF dynamic dependencies · П23. Статическая линковка как слепая зона · П19. C C++ make build inventory · П25. CPE alias worklist · blint · qmake · pkg-config