Блог

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

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

Это происходит в Linux на базе MIPS с древним ядром.

Я подтвердил это, используя Ghidra для разборки исполняемой/общей библиотеки.

В основном у нас есть двоичный файл и общий объект

 file initApp
initApp: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

file libhyCoreSdk.so
libhyCoreSdk.so: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, stripped

objdump -T libhyCoreSdk.so | grep -i IMP_ISP_Open
00047900      DF *UND*  00000000 IMP_ISP_Open
 

initApp вызывает «coreAvInit» в libhyCoreSdk.so, а затем libhyCoreSdk.so вызывает IMP_ISP_Open() обратно в initApp.

Возможно, вы думаете: «Это не так уж необычно, вы можете сделать это с помощью обратных вызовов, передачи указателей, вызова dlsym и т. Д. и т. Д.». Но это не что-то из этого, это прямой импорт/экспорт символов, именно то, что вы ожидали бы увидеть, если бы Libhycore зависел от другой общей библиотеки.

Все это в стороне, моя настоящая проблема в том, что я пытаюсь выяснить, какие параметры передаются IMP_ISP_Open, и LD_PRELOAD не помогает этому странному/уникальному обстоятельству. У меня есть еще один пример приложения, которое вызывает те же API для версии API с общей библиотекой. Когда я использую LD_PRELOAD (загружаю небольшую программу-перехватчик, которую я написал) против этой версии, она отлично работает. Но когда я использую его против этой версии, которая ссылается на двоичный файл, он не работает.

Я надеюсь, что у кого-то есть идеи о том, как я могу перехватывать эти вызовы API.

Частичное Решение:

Дэниел Кляйнштейн дал мне хорошее начало. Я переименовал целевые функции из IMP_… в XMP_… (например, IMP_ISP_DisableSensor-> XMP_ISP_DisableSensor). Теперь датчик IMP_ISP_DisableSensor из моей LD_PRELOAD правильно выбран. К сожалению, я все еще сталкиваюсь с проблемами. Вызов dlsym(RTLD_DEFAULT, «XMP_ISP_DisableSensor») возвращает значение NULL без очевидной причины… Это означает, что я не могу перенаправить обратно к исходной функции.

Несмотря на то, что objdump показывает это:

 objdump -T initApp_mod | grep -i XMP
0061fb5c g    DF .text  00000338  Base        XMP_FrameSource_CreateChn
00613c6c g    DF .text  00000204  Base        XMP_ISP_DisableSensor
006097f0 g    DF .text  00000eb0  Base        XMP_Encoder_CreateChn
 

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

К сожалению, это также препятствует вашему использованию LD_PRELOAD .

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

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