Re: [DynInst_API:] Call Redirection to a Library Function

[Bill Williams <bill@xxxxxxxxxxx>]

On 04/28/2014 03:34 PM, Sergej Proskurin wrote:
> Dear Bill,
>
> First of all, thank you very much for the fast reply. I really
> appreciate your help.
>
> > There are many things that could go wrong with code modification in
> > general, but this is also functionality that's supported through
> > Dyninst's BPatch layer directly. There are function replacement (all
> > calls to foo now call bar), function wrapping (all calls to foo call
> > bar, which then calls foo), and callsite replacement (this call to foo
> > now calls bar) primitives available, and one of those is likely to be
> > easier to work with than PatchAPI code modification for a simple
> > function-level graft.
> I am familiar with Dyninst's Bpatch function replacement functionality.
> Unfortunately, I believe that I am not able to use its functionality
> within my implementation, since my case is probably somewhat unusual:
>
> What I am trying to achieve is a modification of the function's prologue
> and epilogue. Therefore, my implementation looks for the associated
> parts of the affected function(s) and inserts the associated code
> (currently in form of raw data) into these points. I am working on the
> PatchAPI level, since I didn't find a solution how implement
> modifications of the function's pro- and epilogue on the BPatch level.
> If you tell me that it is possible to perform such fine grained
> modifications on the higher abstraction layer of BPatchAPI, I will
> definitely give it a try.
Hrm. I'm presuming that you mean, quite precisely, modifying the 
pro/epilogue blocks' contents, not augmenting them? Otherwise function 
wrapping would do the trick quite nicely, as would various normal 
snippet-based approaches--parameter, return, and local variable snippets 
should provide most of the access to existing abstractions you'd need. 
In fact, unless your problem is specifically concerned with modifying 
the stack/heap/registers as actual locations, rather than modifying the 
variables etc that are stored in them, I would be quite surprised if you 
can't recast a problem of "modification of prologue and epilogue" as 
instrumentation and not modification.
> So, the presented call redirection code within the initial issue
> description affects the epilogue of the function. Within the epilog to
> be modified, I would like to include a call to a function (included
> within the mentined library), which is performed after a certain
> condition is met; Otherwise simply proceed operation. As already
> mentioned, I have already injected raw binary data into the epilogue,
> which can be seen in the following simplified assembly code snippet:
>
> ---
> ...
> cmp    %ebx, %eax
> jz     _pseudo_jump_to_be_redirected
> call   _peudo_call_to_be_redirected
> ---
>
> Because of the fact that I am calling a "pseudo function" from the
> assembly code (from the raw data), I believe that it is not possible to
> track this function down on the BPatch level - am I right? But as
> already said, if you tell me that it is possible to perform such fine
> grained modifications on the prolog and epilog of a function, I would
> rather use the higher abstraction layer of BPatchAPI.
You're of course right that if the call target is a binary blob without 
an associated ST_FUNCTION (or if the library containing it is not in the 
current address space), the function won't exist at the BPatch level. If 
the library is present and you've shoved a public symbol in, it doesn't 
matter whether the function in question is assembly or a high-level 
language; it should be accessible at the BPatch layer and inserting a 
call snippet should work.

> Thanks again.
>
> Best regards,
> Sergej

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx