This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About hacking libc


On Mon, Apr 29, 2013 at 6:40 PM, Ángel González <keisial@gmail.com> wrote:
> On 23/04/13 22:35, Carlos O'Donell 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?
> However, note that a preloaded library will only catch direct calls to
> open().
> So if you replace open(), you will detect when the program calls open() but
> not when it calls fopen() or fstream::open() -even though they call open()
> internally-. That's because the glibc functions don't resolve the open()
> symbol
> but directly call its _open() implementation.
>
>

Thanks all. Does anyone know if there is a unified way to catch up all
open-like library calls?

--
Xinyang GE
Department of Computer Science & Engineering
The Pennsylvania State University
Homepage: http://www.cse.psu.edu/~xxg113/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]