我的目标是 Hook dlopen 在 linux 上使用的 open 函数。出于某种原因,这段代码没有 Hook dlopen->open,但它确实 Hook 了我的 open main.c->open 版本。 dlopen 不以某种方式使用我的符号吗?

编译过程如下:

  • gcc main.c -ldl -ggdb
  • gcc fake-open.c -o libexample.so -fPIC -shared
  • export LD_PRELOAD="$PWD/libexample.so"

  • 当我运行程序时,一切正常。确保设置了 LD_PRELOAD 变量……等等。

    这就是问题所在,当我尝试 Hook 由 dlopen 直接或间接调用的 open 函数时,不知何故,这个 open 的“版本”没有被我的版本解析/重定向/ Hook 。
    [main.c]
    #include <dlfcn.h>
    #include <stdio.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    int main()
    {
        puts("calling open");
        int fd = open("/tmp/test.so", O_RDONLY|O_CLOEXEC);
    
        puts("calling dlopen");
        int *handle = dlopen("/tmp/test.so", RTLD_LAZY);
    }
    
    
    [fake-open.c]
    #define _GNU_SOURCE
    #include <stdio.h>
    #include <dlfcn.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    //#include <fcntl.h>
    
    int open(const char *pathname, int flags)
    {
        puts("from hooked..");
    
        return 1;
    }
    

    控制台输出:

    叫开

    从上瘾..

    调用 dlopen

    我知道事实上 dlopen 由于 strace 以某种方式调用 open 。
    write(1, "calling open\n", 13calling open
    )          = 13
    write(1, "from hooked..\n", 14from hooked..
    )         = 14
    write(1, "calling dlopen\n", 15calling dlopen
    )        = 15
    brk(0)                                  = 0x804b000
    brk(0x806c000)                          = 0x806c000
    open("/tmp/test.so", O_RDONLY|O_CLOEXEC) = 3
    read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0`\205\4\0104\0\0\0"..., 512) = 512
    

    但是,出于某种原因,当 dlopen 调用 open 时,它没有使用我的 open 版本。这必须是运行时符号解析问题的某种链接,或者 dlopen 可能使用的是 open 的静态版本并且不需要在运行或加载时解析任何符号?

    最佳答案

    首先,与@usr 的回答相反, dlopen 确实 open 库。

    我们可以通过在 GDB 下运行一个简单的测试来确认这一点:

    // main.c
    #include <dlfcn.h>
    int main()
    {
       void *h = dlopen("./foo.so", RTLD_LAZY);
       return 0;
    }
    
    // foo.c; compile with "gcc -fPIC -shared -o foo.so foo.c"
    int foo() { return 0; }
    

    让我们编译并运行它:
    gdb -q ./a.out
    (gdb) start
    Temporary breakpoint 1 at 0x400605: file main.c, line 4.
    Starting program: /tmp/a.out
    
    Temporary breakpoint 1, main () at main.c:4
    4          void *h = dlopen("./foo.so", RTLD_LAZY);
    (gdb) catch syscall open
    Catchpoint 2 (syscall 'open' [2])
    (gdb) c
    Continuing.
    
    Catchpoint 2 (call to syscall open), 0x00007ffff7df3497 in open64 () at ../sysdeps/unix/syscall-template.S:81
    81  ../sysdeps/unix/syscall-template.S: No such file or directory.
    (gdb) bt
    #0  0x00007ffff7df3497 in open64 () at ../sysdeps/unix/syscall-template.S:81
    #1  0x00007ffff7ddf5bd in open_verify (name=0x602010 "./foo.so", fbp=0x7fffffffd568, loader=<optimized out>, whatcode=<optimized out>, found_other_class=0x7fffffffd550, free_name=<optimized out>) at dl-load.c:1930
    #2  0x00007ffff7de2d6f in _dl_map_object (loader=loader@entry=0x7ffff7ffe1c8, name=name@entry=0x4006a4 "./foo.so", type=type@entry=2, trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, nsid=0) at dl-load.c:2543
    #3  0x00007ffff7deea14 in dl_open_worker (a=a@entry=0x7fffffffdae8) at dl-open.c:235
    #4  0x00007ffff7de9fc4 in _dl_catch_error (objname=objname@entry=0x7fffffffdad8, errstring=errstring@entry=0x7fffffffdae0, mallocedp=mallocedp@entry=0x7fffffffdad0, operate=operate@entry=0x7ffff7dee960 <dl_open_worker>, args=args@entry=0x7fffffffdae8) at dl-error.c:187
    #5  0x00007ffff7dee37b in _dl_open (file=0x4006a4 "./foo.so", mode=-2147483647, caller_dlopen=<optimized out>, nsid=-2, argc=1, argv=0x7fffffffde28, env=0x7fffffffde38) at dl-open.c:661
    #6  0x00007ffff7bd702b in dlopen_doit (a=a@entry=0x7fffffffdd00) at dlopen.c:66
    #7  0x00007ffff7de9fc4 in _dl_catch_error (objname=0x7ffff7dd9110 <last_result+16>, errstring=0x7ffff7dd9118 <last_result+24>, mallocedp=0x7ffff7dd9108 <last_result+8>, operate=0x7ffff7bd6fd0 <dlopen_doit>, args=0x7fffffffdd00) at dl-error.c:187
    #8  0x00007ffff7bd762d in _dlerror_run (operate=operate@entry=0x7ffff7bd6fd0 <dlopen_doit>, args=args@entry=0x7fffffffdd00) at dlerror.c:163
    #9  0x00007ffff7bd70c1 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
    #10 0x0000000000400614 in main () at main.c:4
    

    这告诉您,在 64 位系统上, dlopen 调用 open64 而不是 open ,因此您的内插器将无法工作(您需要改为内插 open64 )。

    但是您使用的是 32 位系统(由 0x806c000 打印的 strace 等地址证明),并且堆栈跟踪如下所示:
    #0  0xf7ff3774 in open () at ../sysdeps/unix/syscall-template.S:81
    #1  0xf7fe1211 in open_verify (name=0x804b008 "./foo.so", fbp=fbp@entry=0xffffc93c, loader=0xf7ffd938, whatcode=whatcode@entry=0, found_other_class=found_other_class@entry=0xffffc933, free_name=free_name@entry=true) at dl-load.c:1930
    #2  0xf7fe4114 in _dl_map_object (loader=loader@entry=0xf7ffd938, name=name@entry=0x8048590 "./foo.so", type=type@entry=2, trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, nsid=0) at dl-load.c:2543
    #3  0xf7feec14 in dl_open_worker (a=0xffffccdc) at dl-open.c:235
    #4  0xf7feac06 in _dl_catch_error (objname=objname@entry=0xffffccd4, errstring=errstring@entry=0xffffccd8, mallocedp=mallocedp@entry=0xffffccd3, operate=operate@entry=0xf7feeb50 <dl_open_worker>, args=args@entry=0xffffccdc) at dl-error.c:187
    #5  0xf7fee644 in _dl_open (file=0x8048590 "./foo.so", mode=-2147483647, caller_dlopen=0x80484ea <main+29>, nsid=<optimized out>, argc=1, argv=0xffffcf74, env=0xffffcf7c) at dl-open.c:661
    #6  0xf7fafcbc in dlopen_doit (a=0xffffce90) at dlopen.c:66
    #7  0xf7feac06 in _dl_catch_error (objname=0xf7fb3070 <last_result+12>, errstring=0xf7fb3074 <last_result+16>, mallocedp=0xf7fb306c <last_result+8>, operate=0xf7fafc30 <dlopen_doit>, args=0xffffce90) at dl-error.c:187
    #8  0xf7fb037c in _dlerror_run (operate=operate@entry=0xf7fafc30 <dlopen_doit>, args=args@entry=0xffffce90) at dlerror.c:163
    #9  0xf7fafd71 in __dlopen (file=0x8048590 "./foo.so", mode=1) at dlopen.c:87
    #10 0x080484ea in main () at main.c:4
    

    那么为什么 open_verifyopen 的调用没有重定向到您的 open 中介层?

    首先,让我们看看第 1 帧中的实际调用指令:
    (gdb) fr 1
    #1  0xf7fe1211 in open_verify (name=0x804b008 "./foo.so", fbp=fbp@entry=0xffffc93c, loader=0xf7ffd938, whatcode=whatcode@entry=0, found_other_class=found_other_class@entry=0xffffc933, free_name=free_name@entry=true) at dl-load.c:1930
    1930    dl-load.c: No such file or directory.
    (gdb) x/i $pc-5
       0xf7fe120c <open_verify+60>: call   0xf7ff3760 <open>
    

    将此与第 10 帧中的调用指令进行比较:
    (gdb) fr 10
    #10 0x080484ea in main () at main.c:4
    4          void *h = dlopen("./foo.so", RTLD_LAZY);
    (gdb) x/i $pc-5
       0x80484e5 <main+24>: call   0x80483c0 <dlopen@plt>
    

    注意到什么不同了吗?

    没错:来自 main 的调用通过过程链接表 (PLT),动态加载程序 (ld-linux.so.2) 将其解析为适当的定义。

    但是在第 1 帧中对 open 的调用不通过 PLT(因此不可插入)。

    这是为什么?因为该调用必须在 open 的任何其他定义可用之前工作——它在 libc.so.6 (通常提供 open 的定义)本身被加载(由动态加载器)时使用。

    出于这个原因,动态加载器必须是完全独立的(实际上包含一个静态链接的 libc 子集的副本)。



    由于上述原因,这个目标不能通过 LD_PRELOAD 实现。您将需要使用其他一些 Hook 机制,例如在运行时修补加载程序可执行代码。

    关于c - 具有可能的静态共享库函数的 LD_PRELOAD,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/43429458/

    10-12 20:23