Блог

Главная - Вопросы по программированию - PowerPC64 импортирует переименование

PowerPC64 импортирует переименование

#binary #symbols #elf #powerpc #ida

#двоичный #символы #elf #powerpc #ida

Вопрос:

Компиляция файла .c с использованием powerpc64-linux-gnu-gcc выдает следующий двоичный файл:

 .text:00000000100007F4 # .rename _00000017.plt_call.memcpy__GLIBC_2.3, "_00000017.plt_call.memcpy@@GLIBC_2.3"
.text:00000000100007F4
.text:00000000100007F4 # =============== S U B R O U T I N E =======================================
.text:00000000100007F4
.text:00000000100007F4 # void *00000017_plt_call_memcpy__GLIBC_2_3(void *dest, const void *src, size_t n)
.text:00000000100007F4                         _00000017.plt_call.memcpy__GLIBC_2.3:
.text:00000000100007F4 .set arg_28,  0x28
.text:00000000100007F4
.text:00000000100007F4 std       r2, arg_28(r1)
.text:00000000100007F8 ld        r12, (memcpy_plt - 0x10027F00)(r2) # memcpy
.text:00000000100007FC mtctr     r12
.text:0000000010000800 ld        r2, (qword_10020158 - 0x10027F00)(r2)
.text:0000000010000804 bctr
.text:0000000010000804 # End of function _00000017.plt_call.memcpy__GLIBC_2.3

Я не могу понять, откуда .rename _00000017.plt_call.memcpy__GLIBC_2.3 происходит, и почему он переименован из просто быть memcpy ?

Пример к коду, который дает этот результат:

 int main()
{
    char* buf = (char*)calloc(25, sizeof(char));
    char* buf1 = (char*)calloc(25, sizeof(char));
    memcpy(buf, buf1, 25);
}

Комментарии:

1. Из тегов, которыми вы отметили этот вопрос, я предполагаю, что это разборка, полученная из ida ? Зачем использовать дизассемблер, когда у вас есть исходный код? Не могли бы вы предоставить минимальный пример исходной программы C (которая демонстрирует такое поведение при компиляции with powerpc64-linux-gnu-gcc -S )?

2. Да, это действительно дизассемблирование из IDA. Контекст моего вопроса — это процесс автоматизации двоичного анализа, который я пытаюсь выполнить. Я добавил пример .c кода, хотя сам код c не очень важен — просто любое использование memcpy или любой другой библиотечной функции приведет к тому же результату.

Ответ №1:

Этот GLIBC_2.3 материал вводится во время компоновки (компилятор ничего не знает о вашей версии Glibc). И .rename комментарии в списке являются артефактом IDA. (В документации IDA что-нибудь говорится о них?)

@ Знаки, которые вы видите, указывают на версии символов, @@ обозначающие версию по умолчанию, к которой привязаны внешние (в данном случае к Glibc) ссылки на этот символ.

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

Таким образом, решение о том, к какому символу будет привязана ссылка в вашей программе, в конечном итоге принимается во время загрузки ld.so . Возможно, это то, что .rename означает.

С помощью набора инструментов GNU решение о привязке может быть отложено до времени выполнения. На моей платформе (x86_64-linux-gnu) memcpy является IFUNC. Вы можете проверить, так ли это для вас, посмотрев на символы glibc, подобные этому readelf -s /lib/libc.so.6 | grep IFUNC.*memcpy . Теоретически, однако, IDA не будет знать конечный пункт назначения без запуска кода, поэтому ifuncs, вероятно, здесь неуместны. Вы можете протестировать другие функции libc, которые не являются ifuncs, ради более чистого эксперимента.