Re: [DynInst_API:] Binary Rewriting using wrapFunction

[Josh Stone <jistone@xxxxxxxxxx>]

On 12/15/2014 09:02 AM, Bill Williams wrote:
> On 12/14/2014 04:04 PM, Sergej Proskurin wrote:
>> Hello,
>>
>> currently, I am developing a software that should be able to rewrite
>> binaries (as the name suggests, the process of rewriting should be
>> performed statically). One of the goals I am trying to achieve, is to
>> wrap library function calls with custom implementations.
>>
>> To achieve this, I am using the function:
>> BPatch_addressSpace::wrapFunction(...)
>>
>> This works fine for functions compiled statically into binary objects.
>> However, I have encountered the issue that the wrapping of dynamically
>> loaded functions (such as printf) works only dynamically. This means, if
>> the binary object is opened with BPatch_addressSpace::openBinary(...),
>> it will not create persistent wrappers for dynamic library function
>> calls within the binary object on BPatch_binaryEdit::writeFile(...).

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).

>> Is there any way to manipulate the ELF file by using the tools provided
>> by Dyninst so that the binary will behave as presented? Thank you very
>> much in advance.
>>
> There are at least two approaches here, depending on your precise goals:
> 
> 1) Open the binary, including all of its shared libraries, and rewrite 
> the shared libraries in which you want to wrap functions.
> 2) For calls to functions outside the main executable, wrap the call 
> site with pre-call and post-call instrumentation.

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.

> Obviously there are tradeoffs between keeping a rewritten (e.g.) libc 
> around and performing the instrumentation on a callsite basis. 
> Unfortunately, we can't play the symbol games that we rely on in order 
> to wrap functions without modifying the shared library that they're in...
> 
>> Best regards,
>> Sergej
>> _______________________________________________
>> Dyninst-api mailing list
>> Dyninst-api@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
> 
>