如何在二进制执行期间挂钩所有linux系统调用

–wrap symbol

Use a wrapper function for symbol. Any undefined reference to symbol will be resolved to __wrap_symbol. Any undefined reference to __real_symbol will be resolved to symbol. This can be used to provide a wrapper for a system function. The wrapper function should be called __wrap_symbol. If it wishes to call the system function,it should call __real_symbol.

它也适用于系统调用.这是readlink的一个例子：

#include <stdio.h>
#include <string.h>
#include <unistd.h>

ssize_t __real_readlink(const char *path,char *buf,size_t bufsiz);

ssize_t __wrap_readlink(const char *path,size_t bufsiz) {
    puts("Hello from the wrapped readlink :з");
    __real_readlink(path,buf,bufsiz);
}

int main(void) {
    const char testLink[] = "/usr/bin/gnome-www-browser";
    char buf[256];
    memset(buf,sizeof(buf));
    readlink(testLink,sizeof(buf)-1);
    puts(buf);
}

要从编译器将选项传递给链接器,请使用-Wl选项：

$gcc test.c -o a -Wl,--wrap=readlink
$./a
Hello from the wrapped readlink :з
/etc/alternatives/gnome-www-browser

这个想法是__wrap_func是你的函数包装器. __real_func链接器将链接到实际函数func.并且每次对代码中的func的调用都将替换为__wrap_func.

UPD：有人可能会注意到,静态编译的二进制文件会调用另一个未被截获的readlink.要理解原因,只需做一点实验 – 将代码编译到目标文件,并列出符号,如：

$gcc test.c -c -o a.o -Wl,--wrap=readlink
$nm a.o
0000000000000037 T main
                 U memset
                 U puts
                 U readlink
                 U __real_readlink
                 U __stack_chk_fail
0000000000000000 T __wrap_readlink

这里有趣的是,你不会看到在进入main函数之前对strace一起看到的一堆函数的引用 – 例如uname(),brk(),access()等等.这是因为main函数不是二进制文件中调用的第一个代码. bit of research with objdump将向您显示第一个名为_start的函数.

现在,让我们再做一个例子 – 覆盖_start函数：

$cat test2.c
#include <stdio.h>
#include <unistd.h>

void _start() {
        puts("Hello");
        _exit(0);
}
$gcc test2.c -o a -nostartfiles
$strace ./a
execve("./a",["./a"],[/* 69 vars */]) = 0
brk(0)                                  = 0x150c000
access("/etc/ld.so.nohwcap",F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL,8192,0) = 0x7f3ece55d000
access("/etc/ld.so.preload",R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3
fstat(3,{st_mode=S_IFREG|0644,st_size=177964,177964,PROT_READ,MAP_PRIVATE,3,0) = 0x7f3ece531000
close(3)                                = 0
access("/etc/ld.so.nohwcap",F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6",O_RDONLY|O_CLOEXEC) = 3
read(3,"177ELF2113>1320372"...,832) = 832
fstat(3,{st_mode=S_IFREG|0755,st_size=1840928,3949248,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_DENYWRITE,0) = 0x7f3ecdf78000
mprotect(0x7f3ece133000,2093056,PROT_NONE) = 0
mmap(0x7f3ece332000,24576,MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,0x1ba000) = 0x7f3ece332000
mmap(0x7f3ece338000,17088,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,0) = 0x7f3ece338000
close(3)                                = 0
mmap(NULL,0) = 0x7f3ece530000
mmap(NULL,0) = 0x7f3ece52e000
arch_prctl(ARCH_SET_FS,0x7f3ece52e740) = 0
mprotect(0x7f3ece332000,16384,PROT_READ) = 0
mprotect(0x600000,PROT_READ)     = 0
mprotect(0x7f3ece55f000,PROT_READ) = 0
munmap(0x7f3ece531000,177964)          = 0
fstat(1,{st_mode=S_IFCHR|0600,10),0) = 0x7f3ece55c000
write(1,"Hellon",6Hello
)                  = 6
exit_group(0)                           = ?
+++ exited with 0 +++
$

它以前如何？！我们只是重写了二进制文件中的第一个函数,仍然看到系统调用 – 为什么？

实际上,这是因为调用不是由应用程序执行的,而是在应用程序加载到内存之前由内核执行,并允许运行.

UPD：正如我们之前看到的,您的应用程序不会调用这些函数.老实说,在shell调用execve为你的应用程序后,我找不到为静态二进制文件做的事情,但是从列表中看起来你看到的每个调用都是由内核本身完成的 – 没有任何辅助应用程序,比如动态链接器不需要静态二进制文件(因为有像brk这样的函数可以处理数据段).

无论如何,你肯定无法轻易修改这种行为,你需要一些黑客攻击.因为如果您可以轻松覆盖在二进制运行之前执行的代码的函数 – 即来自其他二进制文件 – 它将是安全性中的一个大黑洞,想象一下：一旦您需要root权限,您可以覆盖函数用一个来执行你的代码,并等待一些具有root权限的守护进程执行一个脚本,从而触发你的代码.