Dynamic linking with LD_PRELOAD - get it compiled - Linux

This is a discussion on Dynamic linking with LD_PRELOAD - get it compiled - Linux ; Hello group, I'm currently working on a tool which generates code that can be compiled with gcc to form a shared object. This shared object then can be preloaded with the LD_PRELOAD variable and shadows other library functions (read, write, ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 62

Thread: Dynamic linking with LD_PRELOAD - get it compiled

  1. Dynamic linking with LD_PRELOAD - get it compiled

    Hello group,

    I'm currently working on a tool which generates code that can be
    compiled with gcc to form a shared object. This shared object then can
    be preloaded with the LD_PRELOAD variable and shadows other library
    functions (read, write, printf and such).

    The intercepted functions do a dlsym with the RTLD_NEXT parameter on the
    name of the actual function - then they are called. This gives me the
    possibilty to hook code in before and after library calls and maybe
    change the return value of those.

    Anyways, it's working nicely with open(), close(), read(), write() and
    such, but then I tried select() - suddenly the compiler complains:


    $ gcc -O2 -Wall -fPIC -shared -ldl -o libtrapper.so libtrapper.c Custom.o
    libtrapper.c:155: error: conflicting types for ‘select’
    /usr/include/gentoo-multilib/amd64/sys/select.h:112: error: previous
    declaration of ‘select’ was here
    make: *** [libtrapper.so] Error 1

    Well, of course I redefine it - however with different parameters. I
    always use void* in my declaration. I know it is not 100% correct, but
    it works (at least on x86_64) - but how do I convince gcc to compile the
    code anyways?

    Regards,
    Johannes

    --
    "PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  2. Re: Dynamic linking with LD_PRELOAD - get it compiled

    Johannes Bauer wrote:

    > Well, of course I redefine it - however with different parameters. I
    > always use void* in my declaration. I know it is not 100% correct, but
    > it works (at least on x86_64) - but how do I convince gcc to compile the
    > code anyways?
    >


    why don't you use the correct parameters?

    --
    SF

    Games are very educational. Scrabble teaches us vocabulary, Monopoly teaches
    us cash-flow management, and Dungeons & Dragons teaches us to loot dead bodies.

  3. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 8, 7:44 pm, Johannes Bauer wrote:

    > Well, of course I redefine it - however with different parameters.


    This it not legal. C does not permit two functions to have the same
    name, nor does it permit a single function to have inconsistent
    parameters.

    > I
    > always use void* in my declaration. I know it is not 100% correct, but
    > it works (at least on x86_64) - but how do I convince gcc to compile the
    > code anyways?


    You can't. The code is simply not sensible. Why do you say "it works"
    when it generates a compiler error? It doesn't work at all.

    DS

  4. Re: Dynamic linking with LD_PRELOAD - get it compiled

    Dildo Bogumil di Boscopelo schrieb:

    > why don't you use the correct parameters?


    Because then the code generator needs to know the exact prototype -
    which it doesn't. It doesn't need to look into the data, just pass on
    the pointer. The function handling the data then might include the
    headers and interpret the pointer correctly.

    Greetings,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  5. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz schrieb:
    > On Mar 8, 7:44 pm, Johannes Bauer wrote:
    >
    >> Well, of course I redefine it - however with different parameters.

    >
    > This it not legal. C does not permit two functions to have the same
    > name, nor does it permit a single function to have inconsistent
    > parameters.


    I know it is not correct C. However I also know that at least on x86_64
    compiled with gcc all pointers (including function pointers) have the
    same length (64 bits) which is exactly the length of a void*. It
    shouldn't matter for the prototype.

    >> I
    >> always use void* in my declaration. I know it is not 100% correct, but
    >> it works (at least on x86_64) - but how do I convince gcc to compile the
    >> code anyways?

    >
    > You can't. The code is simply not sensible. Why do you say "it works"
    > when it generates a compiler error? It doesn't work at all.


    It only generates a compiler error if I include the appropriate header
    files - which I usually don't. For some functions, however, I need to
    include them. Apart from you thinking the code is sensible or not - how
    do I force the compiler to compile it anyways? Is there no way to
    undefine a prototype?

    Regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  6. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 10, 11:58 am, Johannes Bauer wrote:

    > It only generates a compiler error if I include the appropriate header
    > files - which I usually don't. For some functions, however, I need to
    > include them. Apart from you thinking the code is sensible or not - how
    > do I force the compiler to compile it anyways? Is there no way to
    > undefine a prototype?



    Although I don't recommend it, you can do things like:

    #define select(a,b,c,d,e) select(void *)
    #include
    #undef select

    Now, it's as if unistd.h made the declaration:
    extern int select( void *);



  7. Re: Dynamic linking with LD_PRELOAD - get it compiled

    Johannes Bauer writes:
    > David Schwartz schrieb:
    >> On Mar 8, 7:44 pm, Johannes Bauer wrote:


    [...]

    >>> I
    >>> always use void* in my declaration. I know it is not 100% correct, but
    >>> it works (at least on x86_64) - but how do I convince gcc to compile the
    >>> code anyways?

    >> You can't. The code is simply not sensible. Why do you say "it works"
    >> when it generates a compiler error? It doesn't work at all.

    >
    > It only generates a compiler error if I include the appropriate header
    > files - which I usually don't. For some functions, however, I need to
    > include them.


    "It only generates a compiler error if I want to compile incorrect
    code" ...

    > Apart from you thinking the code is sensible or not -
    > how do I force the compiler to compile it anyways?


    .... "and how can I force the compiler to compile the incorrect code"?
    The answer is 'not at all': Because the code is incorrect, no compiler
    can possibly compile it to anything, because it has no defined
    meaning. If you want to "fix" this, you have to change the
    compiler. The usual course of action would be to fix the code the
    compiler doesn't compile, for obvious reasons.

    C still supports the possibility to declare a function with an
    unspecified parameter list (actually, an emtpy 'identifier list'), eg

    int select();

    and any call to such a function will, in absence of other
    informations, result in performing the 'default argument promotions'
    on the actual parameters (any integer smaller than int is either
    converted to int or unsigned, depending on representability of the
    value, floats are converted to doubles) and then just invoke the
    subroutine with them

  8. Re: Dynamic linking with LD_PRELOAD - get it compiled

    William Pursell schrieb:

    > Although I don't recommend it, you can do things like:
    >
    > #define select(a,b,c,d,e) select(void *)
    > #include
    > #undef select


    Ah! Thank you. That's the solution I was looking for.

    Kind regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  9. Re: Dynamic linking with LD_PRELOAD - get it compiled

    Rainer Weikusat schrieb:

    >> Apart from you thinking the code is sensible or not -
    >> how do I force the compiler to compile it anyways?

    >
    > ... "and how can I force the compiler to compile the incorrect code"?
    > The answer is 'not at all': Because the code is incorrect, no compiler
    > can possibly compile it to anything, because it has no defined
    > meaning. If you want to "fix" this, you have to change the
    > compiler. The usual course of action would be to fix the code the
    > compiler doesn't compile, for obvious reasons.


    *sigh*

    Actually, I had here a paragraph about what I need and do not need to
    do. About what gcc assumes about pointer types (which I happen to know).
    I deleted it. It's pretty pointless.

    Williams hack does what I want to be done. Period.

    > C still supports the possibility to declare a function with an
    > unspecified parameter list (actually, an emtpy 'identifier list'), eg
    >
    > int select();
    >
    > and any call to such a function will, in absence of other
    > informations, result in performing the 'default argument promotions'
    > on the actual parameters (any integer smaller than int is either
    > converted to int or unsigned, depending on representability of the
    > value, floats are converted to doubles) and then just invoke the
    > subroutine with them


    This doesn't help me, however, as I need to access the parameters within
    the function, not just make the call possible.

    Regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  10. Re: Dynamic linking with LD_PRELOAD - get it compiled

    Johannes Bauer writes:
    > Rainer Weikusat schrieb:
    >
    >>> Apart from you thinking the code is sensible or not -
    >>> how do I force the compiler to compile it anyways?

    >> ... "and how can I force the compiler to compile the incorrect code"?
    >> The answer is 'not at all': Because the code is incorrect, no compiler
    >> can possibly compile it to anything, because it has no defined
    >> meaning. If you want to "fix" this, you have to change the
    >> compiler. The usual course of action would be to fix the code the
    >> compiler doesn't compile, for obvious reasons.

    >
    > *sigh*
    >
    > Actually, I had here a paragraph about what I need and do not need to
    > do.


    You believe that you need a language which is not C to express
    something you would like a computer to do, but you want to use a
    C-compiler to compile code written in this language. This doesn't make
    sense, and that you don't understand why it doesn't make sense does
    not cause it to make more sense.

    [...]

    > Williams hack does what I want to be done. Period.


    And this 'hack' does exactly what I had written above: It uses the
    preprocessor to modify a specific declaration in the incorrect code
    you would like to feed into a C-compiler for some unknown reason such
    that the code is again correct, assuming that this particular textual
    substitution does not cause any other issues (which would need to be
    checked by examining all headers in its 'scope').

    In other words: As soon as you fix your incorrect code, it magically
    compiles, which is what you want.


    >> C still supports the possibility to declare a function with an
    >> unspecified parameter list (actually, an emtpy 'identifier list'), eg
    >> int select();
    >> and any call to such a function will, in absence of other
    >> informations, result in performing the 'default argument promotions'
    >> on the actual parameters (any integer smaller than int is either
    >> converted to int or unsigned, depending on representability of the
    >> value, floats are converted to doubles) and then just invoke the
    >> subroutine with them

    >
    > This doesn't help me, however, as I need to access the parameters
    > within the function, not just make the call possible.


    Dear imbecile. a function declaration cannot 'access parameters'
    because it is a declaration and not a definition.

  11. Re: Dynamic linking with LD_PRELOAD - get it compiled

    Rainer Weikusat schrieb:

    > In other words: As soon as you fix your incorrect code, it magically
    > compiles, which is what you want.


    There might as well have been a switch for gcc to ignore inconsistent
    prototypes. This might qualify as broken code, yet the resulting
    assembly would in no way be different. Pointers do not have a type at
    machine level (at least on x86_64 they don't).

    >>> C still supports the possibility to declare a function with an
    >>> unspecified parameter list (actually, an emtpy 'identifier list'), eg
    >>> int select();
    >>> and any call to such a function will, in absence of other
    >>> informations, result in performing the 'default argument promotions'
    >>> on the actual parameters (any integer smaller than int is either
    >>> converted to int or unsigned, depending on representability of the
    >>> value, floats are converted to doubles) and then just invoke the
    >>> subroutine with them

    >> This doesn't help me, however, as I need to access the parameters
    >> within the function, not just make the call possible.

    >
    > Dear imbecile. a function declaration cannot 'access parameters'
    > because it is a declaration and not a definition.


    Your "solution" is not helpful, as it does not change the need to use
    preprocessor magic. I was talking about the function definition, not the
    declaration.

    I also might note that your derogatory style of writing and your
    oh-so-whitty comments are sickening. You might notice that not all
    people besides you are morons some day. Your postings would be of much
    more easy reading when you could suppress that kind of insulting drivel.

    Regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  12. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 10, 4:58 am, Johannes Bauer wrote:

    > I know it is not correct C. However I also know that at least on x86_64
    > compiled with gcc all pointers (including function pointers) have the
    > same length (64 bits) which is exactly the length of a void*. It
    > shouldn't matter for the prototype.


    It is almost always a mistake to take "magic platform knowledge" and
    try to write C code based on it. The length of pointers is not the
    only possible way this can go wrong. What happens, if with the next
    version of the C compiler, the total size of all parameters becomes
    part of the calling convention when it is known?

    DS

  13. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz schrieb:
    > On Mar 10, 4:58 am, Johannes Bauer wrote:
    >
    >> I know it is not correct C. However I also know that at least on x86_64
    >> compiled with gcc all pointers (including function pointers) have the
    >> same length (64 bits) which is exactly the length of a void*. It
    >> shouldn't matter for the prototype.

    >
    > It is almost always a mistake to take "magic platform knowledge" and
    > try to write C code based on it. The length of pointers is not the
    > only possible way this can go wrong. What happens, if with the next
    > version of the C compiler, the total size of all parameters becomes
    > part of the calling convention when it is known?


    You're right, of course.

    But the application is not intended to be portable. Not across different
    platforms - not even across different versions of gcc or any of the
    libraries it links my application against. Its a quick hack which I use
    to reverse engineer some internals of a libusb-driver (no, ltrace is not
    sufficient, it doesn't do what I need it to do).

    I need to hack it once, get the data, never use it again. So, it is nice
    if it is portable and well-written C - but it's definitely not a
    requirement for this purpose. Broken, ugly C code is fully sufficient to
    get the job done.

    Kind regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  14. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mon, 10 Mar 2008 15:45:07 +0100 Johannes Bauer wrote:
    | William Pursell schrieb:
    |
    |> Although I don't recommend it, you can do things like:
    |>
    |> #define select(a,b,c,d,e) select(void *)
    |> #include
    |> #undef select
    |
    | Ah! Thank you. That's the solution I was looking for.

    OK, so that works. It's a hack. What I'm curious about is why you could
    not just define select to match the library declaration? Are you trying
    to make this an intercept function that just passes on the arguments AND
    can work no matter which way the function is declared/defined by libc?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-11-2039@ipal.net |
    |------------------------------------/-------------------------------------|

  15. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mon, 10 Mar 2008 16:41:12 +0100 Johannes Bauer wrote:
    | Rainer Weikusat schrieb:
    |
    |> In other words: As soon as you fix your incorrect code, it magically
    |> compiles, which is what you want.
    |
    | There might as well have been a switch for gcc to ignore inconsistent
    | prototypes. This might qualify as broken code, yet the resulting
    | assembly would in no way be different. Pointers do not have a type at
    | machine level (at least on x86_64 they don't).

    Generally pointers would generate code the same way on the same machine.
    But the C compiler is doing more than that. It is making sure that you
    don't link up code that would use the pointer in different ways that are
    not consistent with each other. C++ is worse.

    I'm curious exactly what you are doing. If your code is open source or
    otherwise not restricted, can you show it?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-11-2041@ipal.net |
    |------------------------------------/-------------------------------------|

  16. Re: Dynamic linking with LD_PRELOAD - get it compiled

    phil-news-nospam@ipal.net schrieb:

    > OK, so that works. It's a hack. What I'm curious about is why you could
    > not just define select to match the library declaration? Are you trying
    > to make this an intercept function that just passes on the arguments AND
    > can work no matter which way the function is declared/defined by libc?


    Exactly. It's a code generator which just passes on pointers in the
    gerneated code. It links together with user code which has knowledge
    about the pointers (so it casts appropriately).

    I've not thought about licensing the code itself, but if you want to see
    it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
    generates C code (that builds a shared lib which can be used to
    LD_PRELOAD and reverse engineer certain other libraries/programs). Is
    your mail valid? I'd send it to you then.

    Regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  17. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 12, 7:53 am, Johannes Bauer wrote:

    It's funny, you say this:

    > I've not thought about licensing the code itself, but if you want to see
    > it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
    > generates C code (that builds a shared lib which can be used to
    > LD_PRELOAD and reverse engineer certain other libraries/programs). Is
    > your mail valid? I'd send it to you then.


    Yet you say this:

    > But the application is not intended to be portable. Not across different
    > platforms - not even across different versions of gcc or any of the
    > libraries it links my application against. Its a quick hack ...


    So, you're going to GPL this for all the other people using the same
    platform, same version of GCC, and the same libraries your application
    links against?!

    The moral is, never believe someone who says "it's not intended to be
    portable", "it's a quick hack" or "nobody else will ever use this".
    They're usually just lazy.

    DS

  18. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz schrieb:
    > On Mar 12, 7:53 am, Johannes Bauer wrote:
    >
    > It's funny, you say this:
    >
    >> I've not thought about licensing the code itself, but if you want to see
    >> it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
    >> generates C code (that builds a shared lib which can be used to
    >> LD_PRELOAD and reverse engineer certain other libraries/programs). Is
    >> your mail valid? I'd send it to you then.

    >
    > Yet you say this:
    >
    >> But the application is not intended to be portable. Not across different
    >> platforms - not even across different versions of gcc or any of the
    >> libraries it links my application against. Its a quick hack ...

    >
    > So, you're going to GPL this for all the other people using the same
    > platform, same version of GCC, and the same libraries your application
    > links against?!


    Hey, someone asked for the code and I'm giving it away - what's wrong
    with that? I do need the application for myself only, but will give it
    away for free. Just because I choose the GPL for my code does not imply
    that I'm distributing it (and I won't!)

    > The moral is, never believe someone who says "it's not intended to be
    > portable", "it's a quick hack" or "nobody else will ever use this".
    > They're usually just lazy.


    Nope, you're wrong. I never ever intended to give the app away in the
    first place - if someone asks, however, that's fine with me.

    Regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

  19. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 12, 12:06 pm, Johannes Bauer wrote:

    > Nope, you're wrong. I never ever intended to give the app away in the
    > first place - if someone asks, however, that's fine with me.


    You never intended to, but code has a way of being used outside the
    designer's intentions.

    The first thought is, "it's only ever going to be used on this
    platform with this compiler, so there's no reason to make it
    portable". The next thought is, "hey, maybe it works on this other
    platform". Then, "hey, it seems to work, so let's use it". The next
    thing you know, it breaks.

    The best place to stop this chain is at the very first link. You
    should need a damn good reason to do it wrong, not a good reason to do
    it right.

    DS

  20. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz schrieb:
    > The first thought is, "it's only ever going to be used on this
    > platform with this compiler, so there's no reason to make it
    > portable". The next thought is, "hey, maybe it works on this other
    > platform". Then, "hey, it seems to work, so let's use it". The next
    > thing you know, it breaks.
    >
    > The best place to stop this chain is at the very first link. You
    > should need a damn good reason to do it wrong, not a good reason to do
    > it right.


    So essentialy what you're saying is that I should respond with "My code
    is poorly written, I'm not giving it out" rather then "My code is poorly
    written, do whatever you want with it" (as I did)?

    I think when it is explicitly stated that the code is of poor quality,
    full of ridiculous hacks and induces undefined behavior as of the
    C-standard - what else would anyone expect who tried to use it other
    than the code breaking? And why do you blame me for this?

    Actually I do not think anyone seriously wants to use the code - maybe
    take a peek, that's it. With the discussion here, all warnings are
    pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
    guess he knows what he's doing).

    Regards,
    Johannes

    --
    "PS: Ein Realname wre nett. Ich selbst nutze nur keinen, weil mich die
    meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
    Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
    Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast