Better ways to handle sp-based vars

[thestr4ng3r]

Consider the following example: Both pushes use the same offset from rsp, but they will end up reading from different addresses. r2 assigns the same var to both, which is wrong.

My idea to solve this by "converting" sp-based vars to bp-based ones (since bp in practice usually doesn't change inside a function) would be the following: Do a complete trace through the whole graph of the function from the beginning to the end and save the value of bp-sp (size of the stackframe) as metadata for each instruction. RAnalOp.stackptr gives the difference by which sp changes when the instruction is executed. Then, for each sp + x, an equivalent bp + y can be calculated, which will identify our vars.

This has some downsides/pitfalls:

• There might be no bp in the arch
• Depends on RAnalOp.stackptr to be always correct. If it is not for a single instruction, the analysis for the whole function might be wrong.
• What if there is something like sub esp, eax?
• It is theoretically possible to have different possible values for bp-sp at a point depending on the control flow executed before
• ...

Thus, as a fallback if the above method fails, it would be possible to just create a new variable for each instruction that accesses any sp + ? (or perhaps for a sequence of instruction where we know that sp doesn't change?).

[thestr4ng3r]

Quick and dirty implementation of the sp tracing in r2pipe: https://gist.github.com/thestr4ng3r/403fecffc081a899618b1500ba6d1156 It fails pretty hard on callee cleanup calls if the arguments of the callee are not known.

[radare]

i think we should have a codeshare-style repository to hold all those r2pipe snippets. maybe managed via r2pm and having a database of gist urls?

[thestr4ng3r]

@radare What do you think about adding an analysis hint that contains the stackframe size for an instruction? This could be easily filled from different kinds of analysis and then used later.

[radare]

Sgtm

On 22 May 2019, at 13:55, Florian Märkl notifications@github.com wrote:

@radare What do you think about adding an analysis hint that contains the stackframe size for an instruction? This could be easily filled from different kinds of analysis and then used later.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[thestr4ng3r]

Now that ahF is there, here is an example how to import an x64dbg trace to annotate sp-based vars with a bp offset: https://gist.github.com/thestr4ng3r/24a7b93a8b936019316d6fff46becf33 This produces: