Hello,
I have noticed that after a binary has been statically rewritten with
help of Dyninst, its stack is marked as executable. Even after
modification of the PT_GNU_STACK program header (RW), the stack remains
executable -- (this may be observed e.g. by means of 'pmap' on Linux).
The mentioned
On 16.12.2014 22:33, Bill Williams wrote:
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
Dear Bill,
On 29.04.2014 17:44, Bill Williams wrote:
Should still work (that's the point of loadLibrary). Everything that
falls under a single BPatch_binaryEdit is fair game to use.
I am still trying to redirect a call from a binary blob exit edge of the
type EdgeTypeEnum::CALL to a
Dear Bill,
This seems unusual, and suggests that there's some memory corruption
going on somewhere. Any chance you can run this under valgrind and
send me the results?
sure, the following provides the valgrind --leak-check=full dump of the
following code snippet:
---
...
Dear Bill,
Functionally equivalent (at least re: what we do/don't allow); you're
trying to allocate space specifically on the stack. There are quite a
few ways to go about this, but none of them are through the BPatch
interface as it currently exists. You may find it easier to extend the
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
Dear Bill,
When you say this crashes with a segfault at the point of insertion,
do you mean the mutator crashes when inserting the code, or the
mutatee crashes when executing it? In either case, a stack trace will
be helpful; in the latter case if you're running the mutatee under
Dyninst
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
Hello,
Within my current implementation, I am able to split and inject basic
blocks on the basis of PatchAPI. The newly created and injected basic
blocks are currently filled with raw bytes, as stated within the following:
InsertedCode::Ptr icode = PatchModifier::insert(post_block-object(),
Hello,
After first experimentations with the DynsinstAPI, I would like to use
PatchAPI in order to develop a fine-grained binary editing solution.
Unfortunately, at the moment, I have troubles with the extension of the
Snippet class:
For the beginning, I would like to simply include some
10 matches
Mail list logo
