【问题标题】:LD_PRELOAD can not intercept syscalls, but only libcalls?LD_PRELOAD 不能拦截系统调用,只能拦截 libcalls?
【发布时间】:2015-10-04 23:36:03
【问题描述】:

我的代码适用于malloc,但不适用于mmap。代码如下:

main.c

#include <stdio.h>
#include <stdlib.h>

int main(){
  int * p = (int*) malloc(sizeof(int));
  printf("in main(): value p = %d\n", *p);
  free(p);
}

preload.c

#define _GNU_SOURCE
#include <time.h>
#include <dlfcn.h>
#include <stdio.h>
#include <sys/types.h>

void *(*orig_malloc)(size_t size);
void *malloc(size_t size){
  printf("  Hooked(preload)! malloc:size:%lu\n", size);
  return orig_malloc(size);
}

void * (*orig_mmap)(void *start, size_t length, int prot, int flags, int fd, off_t offset);
void * mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset){
  printf("  Hooked(preload)! mmap:start:%p, length:%lu, prot:%d, flags:%p, fd:%p, offset:%d\n", start, length, prot, flags, fd, offset);
  return orig_mmap(start, length, prot, flags, fd, offset);
}

void
_init(void)
{
  printf("Loading hack.\n");
  orig_malloc = (void* (*)(size_t)) dlsym(RTLD_NEXT, "malloc");
  orig_mmap = (void* (*)(void*, size_t, int, int, int, off_t)) dlsym(RTLD_NEXT, "mmap");
}

编译

gcc -Wall -fPIC -DPIC -c preload.c
ld -shared -o preload.so preload.o -ldl
gcc main.c

使用LD_PRELOAD 运行它

LD_PRELOAD=./preload.so ./a.out

用 strace 运行它

strace ./a.out 2>&1 | view -

来自LD_PRELOAD 的打印输出不会挂钩对mmap 的调用,而只会调用对malloc 的调用。同时,当使用strace 运行时,打印输出确实显示mmap 被多次调用。

这个结果让我很困惑;假设mmap确实被main.c调用(我猜是通过malloc),为什么preload.c不能拦截mmap

PS:我的平台是 Ubuntu 14.04 和 Linux 内核 3.13

PS2:系统调用是指 libc 中的系统调用包装器(但不确定这是否会对问题产生影响)..

【问题讨论】:

  • 对于寻找如何在系统调用中注入失败或假成功的人:寻找strace-e inject选项

标签: c system-calls ld-preload systrace


【解决方案1】:

strace 打印的 mmap 调用是 glibc 内部的。 用LD_PRELOAD 拦截glibc 内部对mmap 的调用是不可能的:

mmap 不在/lib64/libc.so.6.plt 部分,而是直接从glibc 调用,因此LD_PRELOAD 无法拦截glibc 对mmap 的调用。

$ objdump -j .plt -d /lib64/libc.so.6 

/lib64/libc.so.6:     file format elf64-x86-64


Disassembly of section .plt:

000000000001f400 <*ABS*+0x8e3fb@plt-0x10>:
   1f400:   ff 35 02 ac 39 00       pushq  0x39ac02(%rip)        # 3ba008 <_GLOBAL_OFFSET_TABLE_+0x8>
   1f406:   ff 25 04 ac 39 00       jmpq   *0x39ac04(%rip)        # 3ba010 <_GLOBAL_OFFSET_TABLE_+0x10>
   1f40c:   0f 1f 40 00             nopl   0x0(%rax)

000000000001f410 <*ABS*+0x8e3fb@plt>:
   1f410:   ff 25 02 ac 39 00       jmpq   *0x39ac02(%rip)        # 3ba018 <_GLOBAL_OFFSET_TABLE_+0x18>
   1f416:   68 0b 00 00 00          pushq  $0xb
   1f41b:   e9 e0 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f420 <*ABS*+0xb8c10@plt>:
   1f420:   ff 25 fa ab 39 00       jmpq   *0x39abfa(%rip)        # 3ba020 <_GLOBAL_OFFSET_TABLE_+0x20>
   1f426:   68 0a 00 00 00          pushq  $0xa
   1f42b:   e9 d0 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f430 <realloc@plt>:
   1f430:   ff 25 f2 ab 39 00       jmpq   *0x39abf2(%rip)        # 3ba028 <_GLOBAL_OFFSET_TABLE_+0x28>
   1f436:   68 00 00 00 00          pushq  $0x0
   1f43b:   e9 c0 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f440 <malloc@plt>:
   1f440:   ff 25 ea ab 39 00       jmpq   *0x39abea(%rip)        # 3ba030 <_GLOBAL_OFFSET_TABLE_+0x30>
   1f446:   68 01 00 00 00          pushq  $0x1
   1f44b:   e9 b0 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f450 <__tls_get_addr@plt>:
   1f450:   ff 25 e2 ab 39 00       jmpq   *0x39abe2(%rip)        # 3ba038 <_GLOBAL_OFFSET_TABLE_+0x38>
   1f456:   68 02 00 00 00          pushq  $0x2
   1f45b:   e9 a0 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f460 <memalign@plt>:
   1f460:   ff 25 da ab 39 00       jmpq   *0x39abda(%rip)        # 3ba040 <_GLOBAL_OFFSET_TABLE_+0x40>
   1f466:   68 03 00 00 00          pushq  $0x3
   1f46b:   e9 90 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f470 <*ABS*+0x90f60@plt>:
   1f470:   ff 25 d2 ab 39 00       jmpq   *0x39abd2(%rip)        # 3ba048 <_GLOBAL_OFFSET_TABLE_+0x48>
   1f476:   68 09 00 00 00          pushq  $0x9
   1f47b:   e9 80 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f480 <_dl_find_dso_for_object@plt>:
   1f480:   ff 25 ca ab 39 00       jmpq   *0x39abca(%rip)        # 3ba050 <_GLOBAL_OFFSET_TABLE_+0x50>
   1f486:   68 04 00 00 00          pushq  $0x4
   1f48b:   e9 70 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f490 <calloc@plt>:
   1f490:   ff 25 c2 ab 39 00       jmpq   *0x39abc2(%rip)        # 3ba058 <_GLOBAL_OFFSET_TABLE_+0x58>
   1f496:   68 05 00 00 00          pushq  $0x5
   1f49b:   e9 60 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f4a0 <free@plt>:
   1f4a0:   ff 25 ba ab 39 00       jmpq   *0x39abba(%rip)        # 3ba060 <_GLOBAL_OFFSET_TABLE_+0x60>
   1f4a6:   68 06 00 00 00          pushq  $0x6
   1f4ab:   e9 50 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f4b0 <*ABS*+0xb8bc0@plt>:
   1f4b0:   ff 25 b2 ab 39 00       jmpq   *0x39abb2(%rip)        # 3ba068 <_GLOBAL_OFFSET_TABLE_+0x68>
   1f4b6:   68 08 00 00 00          pushq  $0x8
   1f4bb:   e9 40 ff ff ff          jmpq   1f400 <data.8467+0x1f390>

000000000001f4c0 <*ABS*+0x8ec70@plt>:
   1f4c0:   ff 25 aa ab 39 00       jmpq   *0x39abaa(%rip)        # 3ba070 <_GLOBAL_OFFSET_TABLE_+0x70>
   1f4c6:   68 07 00 00 00          pushq  $0x7
   1f4cb:   e9 30 ff ff ff          jmpq   1f400 <data.8467+0x1f390>
[m@localhost ~]$ 

在 glibc 中对 mmap 的调用不会通过 .plt 条目调用它,而是直接拦截这些调用是不可能的:

$ objdump -d /lib64/libc.so.6 | grep mmap
[...]
   81628:   e8 83 ad 07 00          callq  fc3b0 <mmap>
   8177c:   e8 2f ac 07 00          callq  fc3b0 <mmap>
00000000000fc3b0 <mmap>:
   fc3c0:   73 01                   jae    fc3c3 <mmap+0x13>
  13a267:   e8 44 21 fc ff          callq  fc3b0 <mmap>
$ 

00000000000fc3b0 <mmap>:
   fc3b0:   49 89 ca                mov    %rcx,%r10
   fc3b3:   b8 09 00 00 00          mov    $0x9,%eax
   fc3b8:   0f 05                   syscall 
   fc3ba:   48 3d 01 f0 ff ff       cmp    $0xfffffffffffff001,%rax
   fc3c0:   73 01                   jae    fc3c3 <mmap+0x13>
   fc3c2:   c3                      retq   
   fc3c3:   48 8b 0d 96 da 2b 00    mov    0x2bda96(%rip),%rcx        # 3b9e60 <_DYNAMIC+0x2e0>
   fc3ca:   f7 d8                   neg    %eax
   fc3cc:   64 89 01                mov    %eax,%fs:(%rcx)
   fc3cf:   48 83 c8 ff             or     $0xffffffffffffffff,%rax
   fc3d3:   c3                      retq   
   fc3d4:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
   fc3db:   00 00 00 
   fc3de:   66 90                   xchg   %ax,%ax

【讨论】:

  • 抱歉,但可以确定 libc mmap() 可以这样上钩!只需使用 OP 的代码和一个调用 mmap() 的小测试程序...结果在这里:“Hooked(preload)! mmap:start:(nil), length:20, prot:3, flags:0x22, fd:0xffffffff , 偏移量:0"
  • 是,但不是 glibc 对其mmap@FelixPalmen 的调用
  • 那么什么 lib 定义了它?它肯定被拦截了,LD_PRELOAD“技巧”只能拦截对ld.so链接的库的调用[编辑我认为你指的是库内部调用......对吗?]
  • @FelixPalmen “我认为你指的是图书馆内部的调用......对吗?”是的。
  • LD_PRELOAD 捕获glibc 内部调用mmap 是不可能的,但是它们被strace 捕获......想知道这是怎么做到的?
【解决方案2】:

mmap 是一个系统调用,malloc 不是。

由于系统调用对于程序的运行至关重要,因此它们必须在 ld.so 真正起作用之前工作,它们驻留在一个在其他所有内容之前加载的部分中;它可能是动态链接的,但映射(那个特定的“虚拟”动态对象)是由内核本身完成的。在 ld.so 真正开始工作之前很长一段时间。

【讨论】:

  • 我所说的系统调用实际上是 libc 中的系统调用包装器。从这个意义上说,LD_PRELOAD 可以捕获系统调用包装器吗? (我想系统调用包装器是在 ld.so 之后调用的)
  • @Richard:不,libc 中的系统调用包装器很早就绑定到 PLT 存根。太早了,LD_PRELOAD 无法生效。
  • @Richard:请参阅这篇文章,了解整个 PLT/GOT 的工作原理:technovelty.org/linux/…
  • 你在这里包装的不是自动链接的微型系统调用包装器(它甚至不存在于实际文件中),而是你的 libc 中的 mmap() 函数。
  • “不,libc 中的系统调用包装器很早就绑定到 PLT 存根”——这是错误的。内部 libc mmap 调用不是通过 PLT 完成的,这就是它们无法被拦截的原因。相反,其他库和可执行文件中的 mmap 调用是通过 PLT 完成的,并且可以像任何其他 API 一样插入。 “动态链接是由内核自己执行的” - 也错了,内核自己不做任何动态链接。
【解决方案3】:

问题的标题实际上就是答案。

假设 mmap 确实由 main.c 调用(我猜是通过 malloc)

所以你的 main.c 没有调用 库函数 mmap()?当然你不能以这种方式拦截系统调用,你会怎么做?有些架构有syscall CPU 指令,有些使用特殊的中断......有很多方法,但无论如何它与C调用约定完全不同。内核不会以某种方式链接到您的二进制文件,而是在您的用户空间进程执行某些操作时(借助一些硬件辅助)进行控制……“特殊”。

如果您想知道如何拦截系统调用,这当然是非常特定于平台的,但我建议您只需查看strace 实用程序的源代码即可。你永远不会在 strace 中看到 malloc(),因为这不是系统调用,malloc() 使用 mmap 系统调用。

另一方面,如果您将 lib 预加载到实际调用 libc mmap() 函数的二进制文件中,它将按预期工作。

简而言之:libc mmap() 是一个用户友好的 mmap 系统调用包装器,主要功能如下:

#include <sys/mman.h>

int main()
{
    void *test = mmap(0, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
        -1, 0);
    return 0;
}

结果是:

加载黑客。
上钩(预载)! mmap:start:(nil), length:20, prot:3, flags:0x22,
fd:0xffffffff, 偏移量:0

【讨论】:

  • 我只针对x86_64;似乎使用了syscall 指令方案。想知道是否可以通过简单地挂钩二进制文件中的所有syscall 指令来完成系统调用拦截...
  • 我不这么认为...syscall 一方面是 CPU 指令(您不能挂钩这些指令),另一方面是 glibc 中允许程序的最小包装器使用 C 调用约定调用任何系统调用。后者可以使用 LD_PRELOAD 连接。
  • 我相信通过二进制重写技术是可行的
  • 嗯,是的,理想情况下,如果syscall 指令可以用相同长度的指令替换,只需调用一些自己的子程序.. 但我猜这是一个不带数据的单字指令?啊,好吧,我从来没有学过 x86 指令集,所以我出去了;)
  • 我不确定这如何回答这个问题。作者明确指出他对 syscall wrapper 感兴趣,而不是 syscall 本身。
猜你喜欢
  • 1970-01-01
  • 2010-09-09
  • 2022-07-07
  • 2013-03-14
  • 2021-07-06
  • 1970-01-01
  • 1970-01-01
  • 2012-02-27
  • 2015-11-22
相关资源
最近更新 更多