Using Ld_preload to add hooks to glibc library functions

There are many related articles on the Internet, for specific reference:

The basic method of adding hooks is explained by Getuid, printf and other functions:

Http://blog.chinaunix.net/u/9577/showart_1195703.html

If you want to not only replace the original library functions, but also want to eventually pass the function logic to the original system functions, then you may need to use Rtld_next. The system may indicate that Rtld_next is undefined and the solution is given here:

Http://xueruini.spaces.live.com/blog/cns!DF086AB717BC7F6F!517.entry

You may encounter a link error when using Dlsym, prompting you not to find Dlsym. The workaround is to compile with the-LDL compile option:

http://blog.tianya.cn/blogger/post_show.asp?BlogID=78856&PostID=13635493

My process is recorded

FORK.C, finally compiled into fork.so

#include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <stdlib.h> #include < sys/types.h> #include <dlfcn.h>/* Even if you follow the methodology in the reference, define __USE_GNU * or be prompted rtld_next undefined * can only be used in this wretched, non-portable way * experimental purposes, harmless. */# define RTLD_NEXT ((void *) -1l) static pid_t (*real_fork) (void); pid_t fork (void) {printf ("fork is called/n"), if (real_fork = = NULL) {real_fork = (pid_t (*) (void)) Dlsym (Rtld_next, "fo RK "); } return Real_fork (); }

STRLEN.C, and finally compiled into strlen.so. It is necessary to note that the last so did not use, because I encountered a strange thing, see the following text in detail.

#include <stdio.h> size_t strlen (const char *s) {size_t i = 0; printf ("Strlen is called, return x/n") and while (*s) { i++; s++; } return i; }

Test the code. Tested the strlen and fork.

However, I did not add a hook for strlen, because, I found, whether or not hook strlen, this test function is always unresponsive, did not enter into STRLEN.C code. However, when I use Export ld_preload= "./strlen.so", VI, LS and other applications can enter into the STRLEN.C, but my./hello cannot enter STRLEN.C. Weird.

The fork function test is valid.

#include <string.h> #include <stdio.h> #include <sys/types.h> #include <unistd.h> int main (int argc,char** argv) {pid_t m, if (ARGC < 2) exit (0); const char* Hello = argv[1]; printf ("%s length is%d/n", Hello, Strle N (hello)); m = fork (); printf ("pid=%d/n", (pid_t) m); return 0; }

Compilation process (only FORK.C and hello.c are involved)

Gcc-fpic-shared-ldl-o fork.so FORK.C

; Note: If you do not have a home LDL, you are prompted not to find the symbol dlsym, there is no home-fpic, the compiler prompts you to add this option. It's a bit out of line with some information.

Gcc-o Hello hello.c

Export ld_preload= "./fork.so"

./hello ABCD

ABCD length is 4
Fork is called
Pid=0
pid=12828

Export Ld_preload= ""

; Clear preload Path

There is a problem with the Ld_preload method above, which is a persistent global setting that may affect the normal behavior of programs other than./hello. A better way to use it is to do it directly:

Ld_preload= "./fork.so"./hello ABCD

Postscript:

About Dlsym

#include <dlfcn.h> void *dlopen (const char *filename, int flag); Char *dlerror (void); void *dlsym (void *handle, const char *symbol); int dlclose (void *handle);

Ld_preload can easily realize the binary compatibility of the application layer, which is worth popularizing. Also remember that ld_preload can not be abused, otherwise it will interfere with the function of normal system. Generally, you need to empty the contents of ld_preload after use.