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: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: libc-help at sourceware dot org
- Date: Tue, 23 Apr 2013 17:53:05 -0400
- Subject: Re: About hacking libc
- References: <CACY857JO7HoMRQyX1sb1gqR0DzK0PksBy0OPd7awCVbBSVKCPQ at mail dot gmail dot com> <CAE2sS1hv8CU45snKVOSzqYv-J9f4GcVp6v8GyAEg93cSQ=NWow at mail dot gmail dot com>
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?
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