为什么libc.so符号表中没有main_arena，而glibc2.23的malloc.c中有main_arena? [英] Why there isn't main_arena in libc.so symbol table, while there is one in malloc.c of glibc2.23?

问题描述

我正在研究glibc的堆.

I'm studying the heap of glibc.

libc.so中没有main_arena符号，即使我尝试使用pwntool转储它也是如此.但是，当我调试测试程序时，可以打印main_arena结构.

There's no main_arena symbol in libc.so, even if I try to dump it with pwntool. However, when I debug a test program, I can print the main_arena structure.

gdb-peda$ p main_arena
$1 = {
    mutex = 0x0, 
    flags = 0x0, 
    fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 
    top = 0x0, 
    last_remainder = 0x0, 
    bins = {0x0 <repeats 254 times>}, 
    binmap = {0x0, 0x0, 0x0, 0x0}, 
    next = 0x7ffff7dd1b20 <main_arena>, 
    next_free = 0x0, 
    attached_threads = 0x1, 
    system_mem = 0x0, 
    max_system_mem = 0x0
}

此外，当我使用-m32编译测试程序时，也找不到main_arena.

And besides, when I compile test program with -m32, main_arena can't be found, too.

推荐答案

main_arena 是本地符号，并且未导出.导出符号的列表是通过glibc源代码树中的 Version 文件控制的.通过设计，这是为了防止人们能够链接到glibc在内部使用的随机符号(以便不污染POSIX和其他标准所要求的名称空间).

main_arena is a local symbol and is specifically not exported. the list of exported symbols is controlled via the Version files in the glibc source tree. this is, by design, to keep people from being able to link against random symbols that glibc uses internally (so as to not pollute the namespace as is required by POSIX and other standards).

gdb之所以可以找到它，是因为您有可用的调试符号... C lib没有被剥离，或者您在/usr/lib/debug/中有拆分的调试符号，而gdb正在查找那些.启动gdb时，它将告诉您从/usr/lib/debug/xxxxx 读取符号之类的信息.

gdb can find it because you have debug symbols available ... either the C lib is not stripped, or you have the split debug symbols in /usr/lib/debug/ and gdb is finding those. when you launch gdb, it will tell you things like Reading symbols from /usr/lib/debug/xxxxx.

能够链接符号的唯一方法是从源代码重建glibc并修改导出列表.

the only way to be able to link against the symbol is to rebuild glibc from source and modify the export list.

或者，您可以在应用程序中编写一些代码，使其表现得像gdb.即，打开调试文件，处理其中的ELF/DWARF信息，使用活动的已加载库信息应用重定位(请参见 dl_iterate_phdr )，然后直接开始戳内存.

alternatively, you could write some code in your app to behave like gdb. namely, open the debug file, process the ELF/DWARF information in it, apply relocations using the active loaded library info (see dl_iterate_phdr), and then just start poking memory directly.

如果工作量太大，黑客的解决方案可能是 fork()+popen() gdb 针对您自己的进程并以批处理模式运行它以转储符号信息.

if that's too much work, a hackery solution might be to fork()+popen() gdb against your own process and run it in batch mode to dump symbol info.

char *cmd;
FILE *fp;

asprintf(&cmd, "gdb -q -p %i -batch -ex 'p &main_arena'", getpid());
fp = popen(cmd, "r");
// parse the output of |fp| here looking for the address.

free(cmd);
fclose(fp);

这篇关于为什么libc.so符号表中没有main_arena，而glibc2.23的malloc.c中有main_arena?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！