On 10/05/2015 05:09 AM, Marc Brünink wrote:
Dear Allison,
thanks for the patch. Took me a while to actually test it properly.
There are no issues with simple functions.
However, recursive calls are problematic.
void function_end(int n) {
if (n > 0)
function_end(n-1);
}
void function_parent_recursive(void) {
function_end(1);
}
0000000000400753 <function_end>:
400753: 55 push %rbp
400754: 48 89 e5 mov %rsp,%rbp
400757: 48 83 ec 10 sub $0x10,%rsp
40075b: 89 7d fc mov %edi,-0x4(%rbp)
40075e: 83 7d fc 00 cmpl $0x0,-0x4(%rbp)
400762: 7e 0d jle 400771 <function_end+0x1e>
400764: 8b 45 fc mov -0x4(%rbp),%eax
400767: 83 e8 01 sub $0x1,%eax
40076a: 89 c7 mov %eax,%edi
40076c: e8 e2 ff ff ff callq 400753 <function_end>
400771: c9 leaveq
400772: c3 retq
000000000040079d <function_parent_recursive>:
40079d: 55 push %rbp
40079e: 48 89 e5 mov %rsp,%rbp
4007a1: bf 01 00 00 00 mov $0x1,%edi
4007a6: e8 a8 ff ff ff callq 400753 <function_end>
4007ab: 5d pop %rbp
4007ac: c3 retq
I get:
function_end returns to 0x500006a1
function_end returns to 0x4007ab
At the moment I have no idea where the 0x500006a1 comes from.
Okay, this one is obvious to me, but not entirely trivial to fix: we're
handing back the relocated address where the instrumented version of
function_end called itself. Doing that translation directly in the
snippet is not a good idea; there are use cases where we need to go to
the actual control flow target and not the original address of said target.
Are you doing this instrumentation dynamically or with binary rewriting?
And if you're doing rewriting, can you get away with a post-processing
step on your output? It should be straightforward to expose a relocated
address->original address translation method at the BPatch_addressSpace
level (harder in the binary rewriting case, but should Just Work(tm) in
the process case).
Marc
On 29/09/2015 04:11, Allison Morris wrote:
Hi all,
I apologize for the delay, but I have a patch for 32-bit Windows and
x86_64 Linux.
Marc, I believe you had the proper understanding of how to use the
expression, and it should work now with the attached patch. Let me
know if you run into any more issues.
Best,
Allison
________________________________________
From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of
Allison Morris <amorris@xxxxxxxxxxx>
Sent: Wednesday, September 23, 2015 3:30 PM
To: Marc Brünink; dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] BPatch_dynamicTargetExpr on return
statements
Marc,
I believe this is the first time we have tried using
dynamicTargetExpr on x86_64 Linux. As I mentioned before, this was
created for use in defensive mode, which is only supported on 32-bit
Windows. I have found a bug in our code generation for this
expression, but I haven't tested the 64-bit version yet. It looks
like that will also be a quick fix, and I should be able to produce a
patch soon.
Best,
Allison
________________________________________
From: Marc Brünink <marc@xxxxxxxxx>
Sent: Tuesday, September 22, 2015 8:30 PM
To: Allison Morris; dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] BPatch_dynamicTargetExpr on return
statements
Dear Allison,
I am using the normal mode. At least I never told dyninst to use
defensive mode. I am running on a x86_64. It is a 3.13.0-37-generic
Linux kernel.
Marc
On 22/09/2015 23:07, Allison Morris wrote:
Hi Marc,
The dynamicTargetExpr was added a few years ago to assist in
analyzing malicious binaries. We haven't significantly tested it in
a while, and after I ran a quick test, it appears to be broken in
the latest release. However, proper functionality should let you
obtain the target address of the return.
I'm going to look into this issue to see if we can find a fix. If
you don't mind, can you also tell me which platform you are using
and are you running Dyninst in normal or defensive mode?
Thanks,
Allison
________________________________________
From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of
Marc Brünink <marc@xxxxxxxxx>
Sent: Monday, September 21, 2015 5:28 AM
To: dyninst-api@xxxxxxxxxxx
Subject: [DynInst_API:] BPatch_dynamicTargetExpr on return statements
Dear all,
I am trying to understand BPatch_dynamicTargetExpr. Things I did:
1. Create an empty function.
function (0x4015b9)
Basic Block (4015b9 to 4015bf) (entry: 1) (exit: 1):
4015b9 push RBP, RSP
4015ba mov RBP, RSP
4015bd pop RBP, RSP
4015be ret near [RSP]
2. Find the single exit point of the empty function.
It is 4015be.
3. Insert a snippet to a function that receives a void* and print it.
Pass dynamicTargetExpr() as argument
4. Alternative to 3:
BPatchSnippetHandle* handle = process->insertSnippet(
BPatch_arithExpr(BPatch_assign, *v,
BPatch_dynamicTargetExpr()),
*exit_points,
BPatch_callAfter);
with v being a BPatch_variableExpr that is a static void*.
I expected to get the target of the return.
I got pretty much random values.
Currently I am using the little bit outdated version 5d54538 from 15th
April.
Questions:
1. Can I use dynamicTargetExpr on return statements?
2. If yes, how to use dynamicTargetExpr?
3. What constraints exist regarding the usage of dynamicTargetExpr?
4. Is this a known issue that is fixed in newer version?
Marc
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}