Add command to rebase analysis information

[radare]

We need a command that takes this as arguments:

• initiial address of current data (for a specific module)
• end address of current data (for a specific module)
• new base address

The command will walk all the comments, hints, breakpoints, functions, basic blocks, types bindings, xrefs... and rebase all of them that are poiniting in the specified range.

Example propsal:

aR 0x8000 0xa000 @ 0x6000
aR 0x6000 0x8000 0xa000

When this command (and api) is ready, we can use it to solve the problem of ood in aslr by rebasing all the debugmaps comparing them to the new ones and calling aR.

[XVilka]

Isn't this a duplicate of #6495 ?

[XVilka]

Also related #5905

[radare]

yes it is. we can close the old one, because it's better described/explained in here

[radare]

im thinking that this wont work unless i provide the full mapping translations of all the regions at once. otherwise we can recursively rebase things that fall on other used areas and result in a broken state

[radare]

maybe do this with two different RCore instances like radiff works?

[Hamled]

This is also related to #13390.

One question to ask, I think, is what are the use cases for the analysis rebasing command? The most obvious one to me is when switching into and out of debugging mode (in particular ASLR scenarios as you've mentioned).

If that's the only meaningful use case, we might have some less-general solutions that still work vs. needing to generally support rebasing an RAnal instance.

For example, maybe have two RAnal instances referenced from RCore:

• One for static analysis, written/read when using analysis commands while not debug mode.
• One for current dynamic analysis, written/read when using analysis commands while debugging.

The rebasing operation could be contained entirely within the processing of oo[d], for the case where there is existing analysis data when you reopen a file in debug mode.

This might simplify:

• needing to have all loaded maps at once, so everything can be rebased atomically
• code changes, if we switch the RCore.anal pointer as needed, and store the above two instances in separate members.
• switching out of debug mode, no need to "un-rebase"

There's obviously other complications, in particular synchronizing the analysis data as it is modified in either mode. My guess is that would be simpler to implement than rewriting RAnal to include an address translation piece, given how complex that code is and how frequently address fields are directly referenced.

[Hamled]

As happens so often, just as I was drifting off to sleep I had an idea that might result in both fewer changes to the existing analysis code base while also being more flexible than what I suggested yesterday.

Rather than keep multiple copies of RCore or RAnal, or update all accesses to analysis objects' addresses to go through a translation layer, we could maintain a separate "address table" with entries for all analysis objects which are reachable from RCore.anal.

Each entry in the table would include, in addition to a reference to the address field on a specific object, whatever information was needed to support rebasing the address.

Rebasing for debugging would mean walking the entire table and rebasing the address through each reference, according to the current maps (or lack thereof). Rebasing with the aR command would just be the same process, but filtered to a entries where the current addresses were within the specified range. Or, perhaps more in the r2 style, entering/exiting debugging state could be implemented as a series of aR commands (at a slight performance hit).

Any address-based indexes (RAnal.fcn_tree and RAnal.fcn_addr_tree at least) would need to be re-built after each rebase, but I guess that's true for any implementation.

I'm also not clear enough yet on how analysis data is persisted with r2, so I'm not sure how or if that would need to be updated.

The clear benefits I see to this approach over the other choices mentioned above:

• There's no indirection when reading addresses from analysis objects, which is almost certainly the dominating behavior with that data.
• The code that does rebasing doesn't need to know how to walk through all parts of RAnal to find each address, making it hopefully much simpler.

I'm very new to the radare2 codebase, so please let me know if I'm missing something major with this idea.

[radare]

aren't we closer to this after eadbbaf ?

cc @yossizap can you add a command to use this api?

[yossizap]

Will look into it, need to finish rebase based on debug maps instead of sections first.

[radare]

On static should keep using sections

…

On 17 Jan 2020, at 12:51, yossizap ***@***.***> wrote:  Will look into it, need to finish rebase based on debug maps instead of sections first. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

[yossizap]

Too much work left, maybe tomorrow morning.