前面博文 Linux下入门级导出函数截获-使用LD_PRELOAD环境变量 中说道用LD_PRELOAD的方法截获动态库中的函数，有人问我不能截获printf，我就在此文中回答这个问题吧。
首先看下他写的用于拦截的代码和测试代码
拦截代码
#include <unistd.h>
extern void printf(const char *format,...);
void printf(const char *format,...)
{
write(0,"abc",4);
return;
}
编译及连接命令
gcc -g3 -O0 -shared -fPIC -o fake.so fake.c
测试代码
#include <stdio.h>
#include <unistd.h>
int main()
{
printf("123\n");
while(1)
sleep(1);
return 0;
}
gcc -g3 -O0 -o test test.c
结果程序输出为：
[root@localhost Desktop]# export LD_PRELOAD=/root/Desktop/fake.so [root@localhost Desktop]# ./test 123果然不尽人意，跟没有拦截似得。
出现这种情况，可以猜测有以下几种情况：
1).动态库导出的函数名和被调用的函数名不一致，比如用g++编译生成的动态库就可能出现这种情况。但是这里并非如此，用nm查看一下动态库导出的函数名：
[root@localhost Desktop]# nm -Do fake.so fake.so: w _Jv_RegisterClasses fake.so:00000000002008a0 A __bss_start fake.so: w __cxa_finalize fake.so: w __gmon_start__ fake.so:00000000002008a0 A _edata fake.so:00000000002008b0 A _end fake.so:0000000000000648 T _fini fake.so:0000000000000460 T _init fake.so:000000000000057c T printf fake.so: U write好吧，看似没问题，看看是不是其他情况
2).动态库没有注入到进程空间。linux下可以通过/proc文件系统查看进程加载的动态库，如下：
[root@localhost ~]# ps x|grep test 3879 pts/12 S+ 0:00 ./test 3895 pts/13 S+ 0:00 grep test [root@localhost ~]# cat /proc/3879/maps 00400000-00401000 r-xp 00000000 fd:00 132597 /root/Desktop/test 00600000-00601000 rw-p 00000000 fd:00 132597 /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 7f0465071000-7f0465074000 rw-p 00000000 00:00 0 7f0465081000-7f0465082000 rw-p 00000000 00:00 0 7f0465082000-7f0465083000 r-xp 00000000 fd:00 131339 /root/Desktop/fake.so 7f0465083000-7f0465282000 ---p 00001000 fd:00 131339 /root/Desktop/fake.so 7f0465282000-7f0465283000 rw-p 00000000 fd:00 131339 /root/Desktop/fake.so 7f0465283000-7f0465284000 rw-p 00000000 00:00 0 7fff2c239000-7fff2c24e000 rw-p 00000000 00:00 0 [stack] 7fff2c34b000-7fff2c34c000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]从此处可以看到fake.so在目标进程的地址空间中，换句话说就是成功的注入了。那会是什么情况？
3).目标进程没有调用目标接口，即printf。来看一下test的符号信息:
root@localhost Desktop]# nm -Do test test: w __gmon_start__ test: U __libc_start_main test: U puts test: U sleeptest并没有调用printf，但从输出结果看，test调用了puts~什么情况？
其实，这是gcc干的好事，用内建函数puts代替printf。这是一种优化。那怎么解决这个问题？
有2种解决办法：
1)禁止gcc使用内建函数，或者指定gcc连接指定函数，方法如下：
gcc -g3 -O0 -o nbi_test nbi_test.c -fno-builtin-printf这样生成的nbi_test其printf不会被puts代替，因此能有正确的执行结果：
[root@localhost Desktop]# nm -Do nbi_test nbi_test: w __gmon_start__ nbi_test: U __libc_start_main nbi_test: U printf nbi_test: U sleep [root@localhost Desktop]# export LD_PRELOAD=/root/Desktop/fake.so [root@localhost Desktop]# ./nbi_test abc2)截获puts接口(未验证)
原文地址：http://blog.csdn.net/lixiangminghate/article/details/46391099
