Binary PowerPC64导入重命名

使用powerpc64 linux gnu gcc编译.c文件将生成以下二进制文件：

.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\u00000017.plt\u call.memcpy\uu GLIBC\u 2.3

是从哪里来的，为什么它被重命名为

memcpy

给出此结果的代码示例：

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

---

这个

GLIBC_2.3

东西是在链接过程中引入的（编译器对您的GLIBC版本一无所知）。清单中的

.rename

注释是一个IDA工件。（IDA文档中是否有关于它们的信息？）

您看到的

@

符号表示，

@

指定此符号的外部（本例中为Glibc）引用绑定到的默认版本

使用ELF时，链接器支持符号版本。符号版本为 仅在使用共享库时有用。动态链接器可以使用 symbol versions可在函数运行时选择其特定版本 一种可能与早期版本的 共享库

因此，在加载时，

ld.So

通常会决定程序中的引用将绑定到哪个符号。也许这就是

.rename

的意思

---

使用GNU工具链，绑定决策实际上可以延迟到运行时。在我的平台（x86_64-linux-gnu）上，memcpy是一个。您可以查看glibc的符号，如下面的

readelf-s/lib/libc.so.6 | grep IFUNC.*.memcpy

，检查您的情况是否如此。但是，理论上，如果不运行代码，IDA就不知道最终的目的地，因此IFUNC在这里可能无关紧要。为了更简洁的实验，您可以测试其他不是IFUNC的libc函数。

从您标记此问题的标记中，我假设这是从

ida

获得的反汇编？有了源代码，为什么还要使用反汇编程序？您能否提供一个源C程序的最小示例（在使用powerpc64 linux gnu gcc-S编译

时演示此行为）？是的，它确实是从IDA反汇编的。我的问题的背景是我尝试进行的自动化二进制分析过程。我添加了一个
.c
代码的示例，尽管c代码本身并不重要-只要使用
memcpy
或任何其他库函数都会得到相同的结果。