Question

我最近在Linux上尝试使用共享库注入，并决定编写自己的程序（而不是使用GDB来注入库）。

我的程序使用pthread用汇编代码覆盖加载的程序程序的第一个0x25字节（0x40000-0x400025），以便为文件名分配空间并调用dlopen。完成所有这些后，它将恢复程序状态并从中分离。

这是集会：

global inject_library
global nullsub

section .data
section .text

inject_library:
; rdi -> Pointer to malloc()
; rsi -> Pointer to free()
; rdx -> Pointer to dlopen()
; rcx -> Size of the path to the .so to load

; Create a new stack frame
push rbp

; Save rbx because we're using it as scratch space
push rbx
; Save addresses of free & dlopen on the stack
push rsi
push rdx

; Move the pointer to malloc into rbx
mov rbx, rdi
; Move the size of the path as the first argument to malloc
mov rdi, rcx
; Call malloc(so_path_size)
call rbx
; Stop so that we can see what's happening from the injector process
int 0x3

; Move the pointer to dlopen into rbx
pop rbx
; Move the malloc'd space (now containing the path) to rdi for the first argument
mov rdi, rax
; Push rax because it'll be overwritten
push rax
; Second argument to dlopen (RTLD_NOW)
mov rsi, 0x2
; Call dlopen(path_to_library, RTLD_NOW)
call rbx
; Pass control to the injector
int 0x3

; Finally, begin free-ing the malloc'd area
pop rdi
; Get the address of free into rbx
pop rbx
; Call free(path_to_library)
call rbx

; Restore rbx
pop rbx

; Destory the stack frame
pop rbp

; We're done
int 0x3
retn

nullsub:
retn

还有一个C程序调用此程序集例程并使用pthread来处理这些断点。

此设置适用于小型单线程程序，如下所示。

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char* argv) {
    pid_t my_pid = getpid();
    printf("PID: %ld\n", my_pid);
    getchar();
    return 0;
}

我使用了一个简单的共享库，它在构造函数中只执行了puts("Hi");。如上所述，这里的一切都很完美。

然而，当我尝试将相同的库注入更大的（外部，闭源程序）时，我遇到了一个段错误。

这是回溯：

#0  0x00007f6a7985d64d in _dl_relocate_object (scope=0x21fbc08, reloc_mode=reloc_mode@entry=0, consider_profiling=consider_profiling@entry=0)
    at dl-reloc.c:259
#1  0x00007f6a79865723 in dl_open_worker (a=a@entry=0x7fff82d7cbf8) at dl-open.c:424
#2  0x00007f6a793cf5d4 in __GI__dl_catch_error (objname=objname@entry=0x7fff82d7cbe8, errstring=errstring@entry=0x7fff82d7cbf0, 
    mallocedp=mallocedp@entry=0x7fff82d7cbe7, operate=operate@entry=0x7f6a798654c0 <dl_open_worker>, args=args@entry=0x7fff82d7cbf8)
    at dl-error-skeleton.c:198
#3  0x00007f6a79865069 in _dl_open (file=0x21fb830 "/home/umang/code/insertion/test_library.so", mode=-2147483646, caller_dlopen=0x40001a, nsid=-2, 
    argc=<optimized out>, argv=<optimized out>, env=0x7fff82d7cfe8) at dl-open.c:649
#4  0x00007f6a7964ef96 in dlopen_doit (a=a@entry=0x7fff82d7ce08) at dlopen.c:66
#5  0x00007f6a793cf5d4 in __GI__dl_catch_error (objname=objname@entry=0x7f6a798510f0 <last_result+16>, 
    errstring=errstring@entry=0x7f6a798510f8 <last_result+24>, mallocedp=mallocedp@entry=0x7f6a798510e8 <last_result+8>, 
    operate=operate@entry=0x7f6a7964ef40 <dlopen_doit>, args=args@entry=0x7fff82d7ce08) at dl-error-skeleton.c:198
#6  0x00007f6a7964f665 in _dlerror_run (operate=operate@entry=0x7f6a7964ef40 <dlopen_doit>, args=args@entry=0x7fff82d7ce08) at dlerror.c:163
#7  0x00007f6a7964f021 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#8  0x000000000040001a in ?? ()
#9  0x00000000021fb830 in ?? ()
#10 0x00007f6a79326a90 in ?? () at malloc.c:3071 from /lib64/libc.so.6
#11 0x00007f6a796488a0 in ?? () from /lib64/libc.so.6
#12 0x0000000000000d68 in ?? ()
#13 0x00007f6a7931e938 in _IO_new_file_underflow (fp=0x7f6a7964efe0 <__dlopen>) at fileops.c:600
#14 0x00007f6a7931fa72 in __GI__IO_default_uflow (fp=0x7f6a796488a0 <_IO_2_1_stdin_>) at genops.c:404
#15 0x00007f6a7931a20d in getchar () at getchar.c:37
#16 0x00000000004005d7 in main ()

这个回溯告诉我dlopen电话中出现了一些错误（可怕）错误。具体来说，错误在于glibc dl-reloc.c:259。

这是有问题的glibc代码。

254          l->l_lookup_cache.value = _lr; }))                   \
255      : l)
256 
257 #include "dynamic-link.h"
258 
259     ELF_DYNAMIC_RELOCATE (l, lazy, consider_profiling, skip_ifunc);
260 
261 #ifndef PROF
262     if (__glibc_unlikely (consider_profiling)
263     && l->l_info[DT_PLTRELSZ] != NULL)

ELF_DYNAMIC_RELOCATE是dynamic-link.h中定义的宏，如下所示 -

/* This can't just be an inline function because GCC is too dumb
   to inline functions containing inlines themselves.  */
# define ELF_DYNAMIC_RELOCATE(map, lazy, consider_profile, skip_ifunc) \
  do {                                        \
    int edr_lazy = elf_machine_runtime_setup ((map), (lazy),              \
                          (consider_profile));        \
    ELF_DYNAMIC_DO_REL ((map), edr_lazy, skip_ifunc);                 \
    ELF_DYNAMIC_DO_RELA ((map), edr_lazy, skip_ifunc);                \
  } while (0)

#endif

elf_machine_runtime_setup返回正常，所以我假设问题出在ELF_DYNAMIC_DO_REL上。这是上述宏的source。这里的问题是被调用的方法是内联的，因此GDB只显示宏名称而不是底层源。

在GDB中使用ni，我会在elf_machine_runtime_setup返回后看到以下内容：

ELF_DYNAMIC_RELOCATE (l, lazy, consider_profiling, skip_ifunc);
ELF_DYNAMIC_RELOCATE (l, lazy, consider_profiling, skip_ifunc);
ELF_DYNAMIC_RELOCATE (l, lazy, consider_profiling, skip_ifunc);

逐步执行程序集，在以下指令后发生段错误：movaps %xmm0,-0x70(%rbp)。

info local没有多大帮助：

(gdb) info local
ranges = {{start = 140072440991568, size = 0, nrelative = 0, lazy = 670467104}, {start = 0, size = 140072438891376, nrelative = 140072441065920, 
    lazy = 672664367}}
textrels = 0x0
errstring = 0x0
lazy = <optimized out>
skip_ifunc = 0

有趣的是，当我使用GDB注入共享库时（使用我在网上找到的代码），库可以完美地加载。

sudo gdb -n -q -batch \
  -ex "attach $pid" \
  -ex "set \$dlopen = (void*(*)(char*, int)) dlopen" \
  -ex "call \$dlopen(\"$(pwd)/libexample.so\", 1)" \
  -ex "detach" \
  -ex "quit"
)"

提前致谢！

Answer 1

经过几天的刮挠我的头发，我决定谷歌“MOVAPS段错”。

MOVAPS是SIMD指令（此处，它用于快速清零四字）。这里的some more info大致相同。

仔细观察后，我注意到以下段落：

当源操作数或目标操作数是内存操作数时，操作数必须在16字节边界上对齐，否则会生成一般保护异常（#GP）。

嗯。所以我读了有问题的地址的价值。

(gdb) print $rbp - 0x70
$2 = (void *) 0x7ffecd32e838

有。地址未与16字节边界对齐，因此发生了段错误。

解决这个问题很容易。

; Create a new stack frame
push rbp
sub rsp, 0x8
; Do stuff
; Fix the stack pointer
add rsp, 0x8
; Destroy stack frame, return, etc.

我仍然怀疑这是否是正确的方法，但它确实有效。

哦，GDB一直都是正确的 - 它确保堆栈已经对齐。

共享库注入：_dl_relocate_object段错误

1 个答案: