This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: About hacking libc
- From: Xinyang Ge <xxg113 at cse dot psu dot edu>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, libc-help at sourceware dot org
- Date: Wed, 24 Apr 2013 08:52:38 -0400
- 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> <20130424052055 dot GA4733 at domone dot kolej dot mff dot cuni dot cz>
Thanks for your detailed elaboration. Is init() called when open.so is
first loaded?
On Wed, Apr 24, 2013 at 1:20 AM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> 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
>
--
Xinyang GE
Department of Computer Science & Engineering
The Pennsylvania State University
Homepage: http://www.cse.psu.edu/~xxg113/
Twitter: @aegiryy