Re: [DynInst_API:] Binary Rewriting using wrapFunction

[Josh Stone <jistone@xxxxxxxxxx>]

On 12/15/2014 03:19 PM, Sergej Proskurin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
>> On 15.12.2014 19:38, Josh Stone wrote:
> 
>> Note that GCC may use builtin versions of some libc functions, and
>> make transformations for efficiency.  For instance, if you didn't
>> compile with -fno-builtin-printf, a call like printf("%s\n", str)
>> might be translated to puts(str).
> 
> I know about this but this should not present any troubles, thanks :)
> 
>> How about: 3) Use an LD_PRELOAD approach to insert your custom
>> function, and dlsym RTLD_NEXT if that still needs to call the
>> original.  You'd have to write your code in its own library, of
>> course.  Then you can either use LD_PRELOAD directly, or use
>> dyninst loadLibrary -- although I'm not sure if that lets you
>> ensure the order of loading.  And this approach will only work with
>> dynamic functions, not statically linked.
> 
> The LD_PRELOAD approach should work quite well for dynamically linked
> library functions. And if it is possible to determine whether a
> function in question is statically or dynamically linked, the program
> could be designed in such a way that it wraps statically linked
> library functions with help of the mentioned BPatch_wrapFunction(...).
> 
> Regarding the function "BPatch::loadLibrary(...)":
> I have been using it to load my own library filled with predefined
> wrappers for shared libraries into the address space of the mutatee.
> However, that led to the behaviour, described above: Wrappers to
> dynamic function calls are not preserved, when the binary is
> statically rewritten (however it works when the process is
> instrumented at runtime). Or did I miss something?
> 
> I thought (hoped) that Dyninst BPatch::loadLibrary(...) internally
> modifies the dynamic symbol tables of the ELF file so that the wrapped
> calls will be preserved after binary rewriting :)

ELF symbol tables don't lock in which library it comes from, which is
why I hedged about loading order above.  If your wrapper function is
named the same as the original symbol, then you'll only win if your
library is loaded first.  If you give your functions unique names, then
I'd think (hope) it should work.  :)