-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relative calls lifting #4
Comments
Thanks for the report. In fact this is not a bug, the target address computation is based on the concrete address of the instruction itself as you indicated. Do you have any specific reason why RIP should appear in the lifted IR? IMHO, it will complicate the formula anyways. |
Thanks you for the response. 0x0 e8 fb ff ff ff call -0x5
0x5 58 pop rax which is more or less Because of For example, in implementing a DBI we may get several the same basic block at different addresses, a method to accelerate DBI is to optimize this basic block and put the result into a cache. Given the basic block (well, it's not because of 0x0 53 push rbx
0x1 c3 ret
0x2 e8 f4 ff ff ff call -0xc
0x7 58 pop rax
0x8 48 31 d8 xor rax, rbx an optimizer would be able to know that |
From your example above, the call instruction will jump to itself, and it will go infinite loop. So I think you wanted to say something like:
Now, this is effectively the same as We still know that |
Thanks you for the response.
I feel ashamed :(, your example is correct, this is indeed Yes, the optimizer will reduce this snippet into call 0x5
pop rax at different base addresses, then we can not reduce them into a general formula |
Sorry but I am not still sure about "reducing multiple of those call-pop pairs". Suppose we have consecutive call-pop pairs like this:
Now, we can translate this into
Now, with what you have mentioned, we would have:
But this is wrong, because RIP will change as you convert the instruction to |
Thanks you for the response, I really appreciate that. Sorry for my bad explanation, this is not what I mean in saying replace the "call-pop" by the single mov rax, rip
mov rax, rip
mov rax, rip is indeed a very good example to say that it will not work. What I mean is by symbolizing An emulator (using |
Thank you for the explanation. I now see what you mean. I think such a global optimization can definitely benefit, but we may not change our design decision at this point for several reasons:
So all in all, If we see more needs on this, we may resurrect this issue and the PR, but for now, we will not handle this issue. Hope this makes sense to you, and thanks for the fruitful discussion. |
FileInfo.EntryPoint now returns 0UL when there is no entry point. See GitLab #4
Describe the bug
The LowIR of relative calls may not be correct.
To Reproduce
The instruction
at the concrete address
0
is lifted intoExpected behavior
The instruction is a relative call, so the target PC should be relative to the next instruction, i.e.
RIP := RIP - 0x517 + 5
(where5
is the size of the instruction). Moreover, the value being pushed into the stack should be calculated relatively withRIP
, i.e.[RSP] = RIP + 5
.Environment:
Additional context
PR #5 is a dirty fix where B2R2 lifts this instruction to:
Thoughts
B2R2 currently computes directly the target using the current "concrete" address of the instruction and the containing basic block (then there is no need to use a symbolic
PC
).In this
call
instruction, B2R2 pushes the returned "concrete PC" into the stack (e.g.[RSP] := 0x5
) as well as compute the next "concrete PC".The PR #5 makes B2R2 symbolizes the
PC
, then[RSP] := PC + 0x5
. I think it would be a "more expected" behaviour in situations where we need a symboliquePC
(e.g. when we need to formally prove something which should always be true regardless of the value ofPC
).PS. The issue is just a personal point of view and may not a bug but I cannot set the label myself, sorry.
The text was updated successfully, but these errors were encountered: