调试LD_PRELOAD注入的代码

LD_PRELOAD提供了平民化的注入方式固然方便,同一时候也有不便:注入库出错后调试比較困难。

我琢磨了几天找到了可行的调试方法,当然未必是最有效的办法。抛出陋文,希望引来美玉~

首先。写一段代码作为普通的动态库,公开接口。供人调用。例如以下:

//true.c
int fake(const char* s1,const char* s2)
{
	return 0;
}

gcc -g3 -O0 -o libtrue.so true.c -fPIC -shared
echo "/root/Desktop">>/etc/ld.so.conf
ldconfig

这差点儿相同是个空函数。

以下是LD_PRELOAD将要注入的代码:

//fake.c
#include <string.h>
#include <stdio.h>

int fake(const char* s1,const char* s2)
{
	printf("s1:%s-s2:%s\n",s1,s2);

	while(1)
			sleep(1);
	return 0;
} 

Makefile
all:
    gcc -g3 -O0 -fPIC -shared -Wa,-adlhn -c fake.c -fno-builtin-strcmp > fake.cod
    gcc -g3 -O0 -fPIC -shared -o fake.so fake.o -Wl,-Map,Sym.map

fake.c除了生成调试信息以外,同一时候生成符号映射文件,why?

先不解释为什么。先来看下Sym.map中有什么:

.init           0x0000000000000498       0x18
 *(.init)
 .init          0x0000000000000498        0x9 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o
                0x0000000000000498                _init
 .init          0x00000000000004a1        0x5 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbeginS.o
 .init          0x00000000000004a6        0x5 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtendS.o
 .init          0x00000000000004ab        0x5 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o

.plt            0x00000000000004b0       0x40
 *(.plt)
 .plt           0x00000000000004b0       0x40 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o
 *(.iplt)

.text           0x00000000000004f0      0x148
 *(.text.unlikely .text.*_unlikely)
 *(.text .stub .text.* .gnu.linkonce.t.*)
 .text          0x00000000000004f0       0x17 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o
 *fill*         0x0000000000000507        0x9 90909090
 .text          0x0000000000000510       0xaa /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbeginS.o
 *fill*         0x00000000000005ba        0x2 90909090
 .text          0x00000000000005bc       0x40 fake.o
                0x00000000000005bc                fake
 *fill*         0x00000000000005fc        0x4 90909090
 .text          0x0000000000000600       0x36 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtendS.o
 *fill*         0x0000000000000636        0x2 90909090
 .text          0x0000000000000638        0x0 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o
 *(.gnu.warning)

.fini           0x0000000000000638        0xe
 *(.fini)
 .fini          0x0000000000000638        0x4 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o
                0x0000000000000638                _fini
 .fini          0x000000000000063c        0x5 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbeginS.o
 .fini          0x0000000000000641        0x5 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o
                0x0000000000000646                PROVIDE (__etext, .)
                0x0000000000000646                PROVIDE (_etext, .)
                0x0000000000000646                PROVIDE (etext, .)

这里仅截取了Sym.map代码段。代码段中有.init节.text节.fini节。每节中又由诺干.o文件组成。如crt执行时库相关的crti.o以及fake.c编译后生成的fake.o。

编译器将源代码编译为.o中间文件后,还须要把全部的中间文件按同样的页面属性连接到一起,并分配链接地址(关于编译连接的具体介绍能够參看<程序猿的自我修养>)。sym.map文件显示了链接时,各个.o文件在整个fake.so文件里的偏移:如fake.o在文件里的偏移是0x5bc

如今说明一下须要sym.map的原因:由于fake.so是动态库,程序执行时,载入到内存中的位置不固定。由于他的不固定性。所以非常难下断点或者反汇编。可是。程序执行起来后,能够通过cat /proc/pidnum/maps查看进程内存载入的情况,并获得fake.so载入的基址。

有了基址,加上偏移,就能够确定fake.c提供的代码在进程空间中的详细地址:

图中显示fake.so被载入到地址7ffff7deb000-7ffff7dee000,当中7ffff7deb000是基址。加上前面sym.map显示的偏移,如今能够预知fake提供的函数在地址7ffff7deb5bc处。

继续往下,有了动态库,还要有測试文件调用动态库接口:

//test.c
#include <string.h>
#include <unistd.h>

extern int fake(const char* s1,const char* s2);

int main()
{
	if(fake("1","2") == 0)
	{
		printf("nothing\n");
	}

	return 0;
}

gcc -o test test.c
strip --strip-all test

为了比較真实的模拟由他人公布的程序的环境,对于test.c不仅不生成调试信息,同一时候还剥离符号表。

以下開始注入并启动调试。

export LD_PRELOAD=/root/Desktop/fake.so
gdb test

因为没有调试信息,gdb找不到main函数,因此无法在main函数下断点,直接导致start后程序跑飞了:

(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load?

(y or [n]) n

Starting program: /root/Desktop/test
s1:1-s2:2

好吧,眼下仅仅能又一次调试它,并尝试找到程序从哪開始的:

[[email protected] Desktop]# gdb test
(gdb) info files
Symbols from "/root/Desktop/test".
Local exec file:
    `/root/Desktop/test‘, file type elf64-x86-64.
    Entry point: 0x400520

这样就得到了程序的入口,并于此下断点然后start执行,程序在0x400520处停下:

(gdb) b *0x400520
Breakpoint 1 at 0x400520
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load?

(y or [n]) n

Starting program: /root/Desktop/test 

Breakpoint 1, 0x0000000000400520 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6_5.3.x86_64
(gdb)

这时。进程的依赖的各个动态库也业已完毕载入,能够查看内存载入情况:

[[email protected] ~]# ps x|grep  test
 4352 pts/8    S+     0:00 gdb test
 4381 pts/8    T      0:00 /root/Desktop/test

[[email protected] ~]# cat /proc/4381/maps
00400000-00401000 r-xp 00000000 fd:00 131451                             /root/Desktop/test
00600000-00601000 rw-p 00000000 fd:00 131451                             /root/Desktop/test
3326400000-3326420000 r-xp 00000000 fd:00 75830                          /lib64/ld-2.12.so
332661f000-3326620000 r--p 0001f000 fd:00 75830                          /lib64/ld-2.12.so
3326620000-3326621000 rw-p 00020000 fd:00 75830                          /lib64/ld-2.12.so
3326621000-3326622000 rw-p 00000000 00:00 0
3326c00000-3326d8b000 r-xp 00000000 fd:00 75831                          /lib64/libc-2.12.so
3326d8b000-3326f8a000 ---p 0018b000 fd:00 75831                          /lib64/libc-2.12.so
3326f8a000-3326f8e000 r--p 0018a000 fd:00 75831                          /lib64/libc-2.12.so
3326f8e000-3326f8f000 rw-p 0018e000 fd:00 75831                          /lib64/libc-2.12.so
3326f8f000-3326f94000 rw-p 00000000 00:00 0
7ffff7bea000-7ffff7bed000 rw-p 00000000 00:00 0
7ffff7bed000-7ffff7bee000 r-xp 00000000 fd:00 136044                     /root/Desktop/libtrue.so
7ffff7bee000-7ffff7ded000 ---p 00001000 fd:00 136044                     /root/Desktop/libtrue.so
7ffff7ded000-7ffff7dee000 rw-p 00000000 fd:00 136044                     /root/Desktop/libtrue.so
7ffff7dfc000-7ffff7dfd000 r-xp 00000000 fd:00 136014                     /root/Desktop/fake.so
7ffff7dfd000-7ffff7ffc000 ---p 00001000 fd:00 136014                     /root/Desktop/fake.so
7ffff7ffc000-7ffff7ffd000 rw-p 00000000 fd:00 136014                     /root/Desktop/fake.so
7ffff7ffd000-7ffff7ffe000 rw-p 00000000 00:00 0
7ffff7ffe000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffea000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

嗯。fake.so在7ffff7dfc000。fake.o应该位于7ffff7dfc5bc处了。

另外也能够看到。被LD_PRELOAD覆盖的libtrue.so被载入到7ffff7bed000处

能够直接在这个位置下断。当然不放心的话,能够用objdump查看test的反汇编:

[[email protected] Desktop]# objdump -d test

Disassembly of section .plt:

00000000004004d8 <[email protected]t-0x10>:
  4004d8:    ff 35 d2 04 20 00        pushq  0x2004d2(%rip)        # 6009b0 <_fini+0x2002a8>
  4004de:    ff 25 d4 04 20 00        jmpq   *0x2004d4(%rip)        # 6009b8 <_fini+0x2002b0>
  4004e4:    0f 1f 40 00              nopl   0x0(%rax)

00000000004004e8 <[email protected]>:
  4004e8:    ff 25 d2 04 20 00        jmpq   *0x2004d2(%rip)        # 6009c0 <_fini+0x2002b8>
  4004ee:    68 00 00 00 00           pushq  $0x0
  4004f3:    e9 e0 ff ff ff           jmpq   4004d8 <_init+0x18>

...
0000000000400520 <.text>:
  400520:    31 ed                    xor    %ebp,%ebp
  400522:    49 89 d1                 mov    %rdx,%r9
  400525:    5e                       pop    %rsi
  400526:    48 89 e2                 mov    %rsp,%rdx
  400529:    48 83 e4 f0              and    $0xfffffffffffffff0,%rsp
  40052d:    50                       push   %rax
  40052e:    54                       push   %rsp
  40052f:    49 c7 c0 30 06 40 00     mov    $0x400630,%r8
  400536:    48 c7 c1 40 06 40 00     mov    $0x400640,%rcx
  40053d:    48 c7 c7 04 06 40 00     mov    $0x400604,%rdi
  400544:    e8 bf ff ff ff           callq  400508 <[email protected]>

当中

00000000004004e8 <[email protected]>:
  4004e8:    ff 25 d2 04 20 00        jmpq   *0x2004d2(%rip)        # 6009c0 <_fini+0x2002b8>
  4004ee:    68 00 00 00 00           pushq  $0x0
  4004f3:    e9 e0 ff ff ff           jmpq   4004d8 <_init+0x18>

是test向fake.so中导出的函数跳转的地址。能够在此处也下个断点。

======================================================================

附注,測试这段代码时。我已经关闭了随机地址载入所以objdump -d输出的连接地址和test载入地址同样,都是0x400520。

关闭随机地址载入的方法例如以下:

[[email protected] ~]# echo 0>/proc/sys/kernel/randomize_va_space 

======================================================================

(gdb) b *0x04004e8
Breakpoint 2 at 0x4004e8
(gdb) b *0x7ffff7dfc5bc
Breakpoint 3 at 0x7ffff7dfc5bc: file fake.c, line 5.
(gdb)

继续执行。程序在0x4004e8出停下后反汇编看看。然后继续执行到fake.so中

(gdb) c
Continuing.

Breakpoint 2, 0x00000000004004e8 in [email protected] ()
(gdb) x /32i $pc
=> 0x4004e8 <[email protected]>:	jmpq   *0x2004d2(%rip)        # 0x6009c0 <[email protected]>
   0x4004ee <[email protected]+6>:	pushq  $0x0
   0x4004f3 <[email protected]+11>:	jmpq   0x4004d8
(gdb) c
Continuing.

Breakpoint 3, fake (s1=0x3326621188 "",
    s2=0x332640e9f0 "UH\211\345AWAVAUATE1\344S1\333H\203\354HH\307E\250")
    at fake.c:5
5	{
(gdb) x /32i $pc
 (gdb) x /32i $pc
=> 0x7ffff7dfc5bc <fake>:    push   %rbp
   0x7ffff7dfc5bd <fake+1>:    mov    %rsp,%rbp
   0x7ffff7dfc5c0 <fake+4>:    sub    $0x10,%rsp
   0x7ffff7dfc5c4 <fake+8>:    mov    %rdi,-0x8(%rbp)
   0x7ffff7dfc5c8 <fake+12>:    mov    %rsi,-0x10(%rbp)
   0x7ffff7dfc5cc <fake+16>:    lea    0x73(%rip),%rax        # 0x7ffff7dfc646
   0x7ffff7dfc5d3 <fake+23>:    mov    -0x10(%rbp),%rdx
   0x7ffff7dfc5d7 <fake+27>:    mov    -0x8(%rbp),%rcx
   0x7ffff7dfc5db <fake+31>:    mov    %rcx,%rsi
   0x7ffff7dfc5de <fake+34>:    mov    %rax,%rdi
   0x7ffff7dfc5e1 <fake+37>:    mov    $0x0,%eax
   0x7ffff7dfc5e6 <fake+42>:    callq  0x7ffff7dfc4c0 <[email protected]>
   0x7ffff7dfc5eb <fake+47>:    mov    $0x1,%edi
   0x7ffff7dfc5f0 <fake+52>:    mov    $0x0,%eax
   0x7ffff7dfc5f5 <fake+57>:    callq  0x7ffff7dfc4e0 <[email protected]>
   0x7ffff7dfc5fa <fake+62>:    jmp    0x7ffff7dfc5eb <fake+47>

在这段反汇编代码中,我们看到了2个函数:printf/sleep,有点像fake.c中的代码了。

因为。fake.so是源代码编译的,能够在此看到源代码,并下断点:

  0x7ffff7dfc604 <__do_global_ctors_aux+4>:	push   %rbx
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) list
1	#include <string.h>
2	#include <stdio.h>
3
4	int fake(const char* s1,const char* s2)
5	{
6		printf("s1:%s-s2:%s\n",s1,s2);
7
8		while(1)
9				sleep(1);
10		return 0;
(gdb) b 8
Breakpoint 4 at 0x7ffff7dfc5eb: file fake.c, line 8.
(gdb)

当然,还支持查看变量:

$2 = 0x40072a "1"
(gdb) p s2
$3 = 0x400728 "2"
(gdb)

至此。调试LD_PRELOAD注入的so文件结束,3q

qq:[email protected]

时间: 2025-01-11 03:38:33

调试LD_PRELOAD注入的代码的相关文章

如何撤销浏览器注入JS代码的执行效果?

如何撤销浏览器注入JS代码的执行效果? 可用的方法: 放弃所有本地修改,整体重新reload当前的URL(这相当于大粒度的savepoint/snapshot,应确保用户数据/视图状态能够按期望恢复) 内核实现immutable的DOM树,对DOM树的每个修改均产生一个新的版本快照,修改可以直接回退,比如提供一个document.revertTo方法 immutable数据结构上实现MVCC事务,事务本身的执行是原子的,但是并没有考虑用户如何手工反转事务 实现细粒度的对应每个业务逻辑层次写操作的

【Android】Android Studio 1.5+ 中混合调试Native和Java代码

[Android]Android Studio 1.5+ 中调试Native和Java代码 Android Studio 1.5+表示Android Studio 1.5版本以及以上. 网上大部分中文或英语教程还是停留在老版本的Android Studio的Debug的设置,要么不全.正好最近工作中要在Android Studio中调试C++代码,就来写一篇咯. Android Studio 1.5+的调试设置与之前有所不同. 而且新版中推出了一个Hybrid的调试:可以混合调试Native代码

Angular.js 学习二---$scope和$rootScope,Angular模块的run方法,依赖注入中代码压缩

一.$scope和$rootScope的区别 一句话总结: $rootScope针对全局的作用域生效 $scope只针对当前的controller作用域生效 二.AngularJS模块的run方法 run方法初始化全局的数据,只对全局作用域起作用 如$rootScope <script type="text/javascript"> var m1 = angular.module('myApp', []); m1.run(['$rootScope', function ($

Angularjs MVC 以及 $scope 作用域 Angularjs 模块 的 run 方法 以及依赖注入中代码压缩问题

Angularjs MVC 以及 $scope 作用域 Angularjs 模块的 run 方法 以及依赖注入中代码压缩问题 1. Angularjs MVCModel:数据模型层View:视图层,负责展示Controller:业务逻辑和控制逻辑优点: 代码模块化 代码逻辑比较清晰.可移值性高,后期维护方便.代码复用,代码规模越来越大的时候,切分职责是大势所趋缺点:运行效率稍微低一些2. Angularjs $scope 作用域1. $scope 多控制器单独作用域<!DOCTYPE html>

读《软件驱魔》调试和优化遗留代码的艺术

读<软件驱魔> 调试和优化遗留代码的艺术 软件维护方法论的书,其间还有作者的感悟,读起来情深意切啊 此书中文版,第一版是2014年5月 内容给人感觉作者早已成书多年了.但软件知识还是有不过时的东西. 软件发展到现在,在我们身边,已经可以发生着许多书中的故事. 如大量的历史代码无人维护或者是开发人员不可寻且没有文档,没有流程图等等. 在这种情况下,作者指点读者去如何做更有益. 用了许多方法,并科学的介绍了不只一种方法. 收益良多. 还介绍了可能会出现的人员交流的问题.这种问题我在工作中也是常遇到

eclipse调试openstack的nova代码

前段时间一直在研究openstack的nova部分的代码.特别想知道,如何用eclipse来调试代码,也在论坛上问了别人,无果,没人回复我.最后还是自己摸索出了出路. 下面写出自己探索之路.我是用devstack搭建的openstack环境.搭建步骤可以参见我另一篇博客文章. 我的nova代码是这段代码里面没有bin目录,这就使得程序没有入口.但是devstack安装的环境中,在/usr/loacl/bin/目录下有nova-api文件. 在你自己的项目下,新建一个bin文件下,将nova-ap

20.Ecshop 2.x/3.x SQL注入/任意代码执行漏洞(附实战exp)

Ecshop 2.x/3.x SQL注入/任意代码执行漏洞 影响版本: Ecshop 2.x Ecshop 3.x-3.6.0 漏洞分析: 该漏洞影响ECShop 2.x和3.x版本,是一个典型的"二次漏洞",通过user.php文件中display()函数的模板变量可控,从而造成SQL注入漏洞,而后又通过SQL注入漏洞将恶意代码注入到危险函数eval中,从而实现了任意代码执行. 值得一提的是攻击者利用的payload只适用于ECShop 2.x版本导致有部分安全分析者认为该漏洞不影响

调试,高级--step into my code ,只调试自己写的代码,shux,各种step操作debug

调试,高级--step into my code ,只调试自己写的代码,shux,各种step操作debug debug调试IDEA step into mycode fram drop 可以扔掉栈帧,从新开始,但是有全局变量观察变化必须重头开始 step out 结束当前方法的调试调到这个方法所在代码行的下一行 step in /force in 可以调试源代码 step over 如果代码片段有方法,跳过方法的执行过程,也就是不调试方法的执行过程 step over 和 step in 联合

使用VS插件在VS2012/2013上编辑和调试Quick-Cocos2d-x的Lua代码

来源网址:http://www.cocoachina.com/bbs/read.php? tid=205043 http://cn.cocos2d-x.org/tutorial/show?id=507 BabeLua简单介绍  BabeLua是一款基于VS2012/2013(简称VS)的免费开源的Lua集成开发环境,在Lua编辑和调试方面,具有例如以下功能和特性: ●Lua语法高亮 ●语法检查 ●自己主动补全 ●一键凝视 ●自己定义代码折叠 ●project管理 ●高速搜索和跳转 ●文件大纲 ●