This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: About hacking libc
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Xinyang Ge <xxg113 at cse dot psu dot edu>
- Cc: Carlos O'Donell <carlos at systemhalted dot org>, libc-help at sourceware dot org
- Date: Wed, 24 Apr 2013 07:20:55 +0200
- Subject: Re: About hacking libc
- References: <CACY857JO7HoMRQyX1sb1gqR0DzK0PksBy0OPd7awCVbBSVKCPQ at mail dot gmail dot com> <CAE2sS1hv8CU45snKVOSzqYv-J9f4GcVp6v8GyAEg93cSQ=NWow at mail dot gmail dot com> <CACY857+73GzZ3H3H5h81NFynH0=E49NKSEpGdgYcchMcHEA3ng at mail dot gmail dot com>
On Tue, Apr 23, 2013 at 05:53:05PM -0400, Xinyang Ge wrote:
> Thank you, Carlos.
>
> I think the preload way is cleaner and doesn't require recompilation
> of glibc. However, will there be any symbol conflict between my
> library and glibc since both have the open() function? How do dynamic
> linked library avoid symbol conflict? I am really newbie in this
> field, could you recommend some reading materials to me if possible?
>
On conflict resolution symbol that is loaded first wins. LD_PRELOAD is
loaded first so it always wins. You use need to use dlsym to get libc
symbol version. I use this pattern, so following mostly works.
Compile following with -fPIC -shared -ldl -o open.so
then LD_PRELOAD=./open.so bash
#include <dlfcn.h>
int (*libc_open)(const char *pathname, int flags, int mode);
void __attribute((constructor)) init(){
void *libc_handle=dlopen("libc.so.6",RTLD_NOW);
libc_open=dlsym(libc_handle,"open");
}
int open(const char *pathname, int flags, int mode){
printf ("opened %s\n",pathname);
return libc_open(pathname, flags, mode);
}
> Thanks,
> Xinyang
>
> On Tue, Apr 23, 2013 at 4:35 PM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
> > On Tue, Apr 23, 2013 at 2:37 PM, Xinyang Ge <xxg113@cse.psu.edu> wrote:
> >> I am a graduate student at Penn State and currently doing some experiments
> >> on glibc and hoping to put some hooks inside open() library call. However,
> >> as I examined the source code, I noticed these system call wrappers are
> >> dynamically generated at compile time from syscall-template.S. I renamed the
> >> wrapper's name (e.g., from open() to _open()) in syscalls.list and add
> >> another layer of wrapper to add code beyond _open().
> >
> > That sounds reasonable.
> >
> >> Does anyone know some more elegant way in doing the same thing? Thanks a
> >> lot!
> >
> > Write a library, preload it, and within your open function dlopen libc
> > and call the
> > real open?
> >
> > Use systemtap to instrument the syscall on the kernel side?
> >
> > Cheers,
> > Carlos.
>
>
>
> --
> Xinyang GE
> Department of Computer Science & Engineering
> The Pennsylvania State University
> Homepage: http://www.cse.psu.edu/~xxg113/
> Twitter: @aegiryy