On 22/09/22 09:31, Godmar Back via Libc-help wrote:
> Hi,
>
> I have a question. Say I wanted to override the `write()` system call in an
> application so that when I compile and link it, my version of `write()` is
> called by both the application program as well as by GNU libc, for
> instance, from puts or printf. To what extent is this supported?
>
> I'm aware of the following options:
> - (a) link statically. In this case, if I provide a strong definition of
> `write()`, the application will pick it up. GNU libc, otoh, uses
> `__write()` Overriding `__write` with a strong definition works and gets
> libc to call my __write.
>
> - (b) link dynamically and use `LD_PRELOAD`. In this case, I can get the
> application to call my `write`, but libc will continue to call `__write`; I
> believe; I haven't tried if I can provide a __write and have libc pick up
> on it since (I thought) that libc resolves these symbols internally or from
> a dynamic library on its link chain.
Unfortunately this is done intentionally and although the usual double underscore
is used on mot symbol, some also uses different internal nomenclature (for
instance __libc_sigaction). For internal libc usage, we explicit avoid PLT usage
so you will need to either use a dynamic runtime tool to rewrite the text segment
(DynamicRIO, etc.), a probe tools (uprobes, systemtap, etc. which might not fit
the model you are aiming since it might not run in the process namespace), or
recompile glibc to remove the hidden_def definition on the symbol (so PLT are
generated for internal calls and LD_PRELOAD can override it).
>
> In any event, my question is: is there a sanctioned or semi-sanctioned way
> to override system calls for both the static and dynamic linking process?
>
> - Godmar