radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.37k stars 2.97k forks source link

Hooks for arch specific implementation of reg read/write #9242

Open astuder opened 6 years ago

astuder commented 6 years ago

Background:

All CPU registers of the 8051 are also mapped to memory. Many common ops like push reg, pop reg, mov reg, reg are using memory addresses instead of register names.

Support of memory-mapped registers was disabled during refactoring of 8051 ESIL because it broke basic emulation (e.g. ar commands). The original implementation used RAnalEsil.cb.hook_reg_write and hook_reg_read, which are invoked on register access by ESIL, but ignored by other code inside and outside of libr/anal.

Support for memory-mapped registers requires, that all r2 operations which read or write CPU registers invoke arch specific logic to read or write memory.

Proposal:

Add extension points for register read/write access to libr/reg. I propose to add callbacks to the R_Reg structure, which are invoked by r_reg_get_value and r_reg_set_value to replace or augment their native implementation.

As most arch specific code already is in the anal plugins, I propose to set the hooks from there, e.g. as part of get/set_reg_profile, instead of adding arch-specific plugins to libr/reg.

A first implementation will likely ignore register arenas, i.e. not support ara commands for architectures that choose to implement this hook.

This also creates a good extension point to implement other arch specific register behavior that can't be expressed in a reasonable amount of ESIL.

Comments? Thoughts?

XVilka commented 6 years ago

Probably better to put it in .esil_init callback in RAnalPlugin structure. @radare @condret may have their opinions on this.

radare commented 6 years ago

the problem of esil:init and such is what was causing all the problems, because we are asuming that esil is initialized once. but thats not correct, we get several esil instances while disasseblming, to get different contexts and such, and hooking requires a single instance to get events from, that was causing segfaults because the hooking list was getting broken with dead callbacks.

On 26 Jan 2018, at 10:27, Anton Kochkov notifications@github.com wrote:

Probably better to put it in .esil_init callback in RAnalPlugin structure. @radare https://github.com/radare @condret https://github.com/condret may have their opinions on this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/9242#issuecomment-360728618, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lt-5jYM-2nOlLCFdp9uzSYCeUE-Nks5tOZpsgaJpZM4Rtrig.

astuder commented 6 years ago

@courk You mention memory-mapped registers in your recent PIC commit. Is that similar to the 8051 where general purpose registers can also be written/read via data memory addresses?

If so, what are your thoughts for a possible solution to support memory mapped registers in r2?

radare commented 6 years ago

[0x100001200]> e?cmd.esil. cmd.esil.intr: Command to run when an esil interrupt happens cmd.esil.ioer: Command to run when esil fails to IO (invalid read/write) cmd.esil.mdev: Command to run when memory device address is accessed cmd.esil.todo: Command to run when the esil instruction contains TODO cmd.esil.trap: Command to run when an esil trap happens

but you may be also interested in aep:

[0x100001200]> aep? |Usage: aep[-c] [...] | aepc [addr] change program counter for esil | aep-[addr] remove pin | aep [name] @ [addr] set pin | aep list pins [0x100001200]> aep [0x100001200]> aep ?e jiji @ $$+1 [0x100001200]> aes [0x100001200]> aes jiji [0x100001200]> aes [0x100001200]>

On 29 May 2018, at 21:44, Adrian Studer notifications@github.com wrote:

@courk https://github.com/courk You mention memory-mapped registers in your recent PIC commit. Is that similar to the 8051 where general purpose registers can also be written/read via data memory addresses?

If so, what are your thoughts for a possible solution to support memory mapped registers in r2?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/9242#issuecomment-392918254, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lqC31-rPr0PEW0ysBkDDOkmjofWaks5t3aUagaJpZM4Rtrig.

astuder commented 6 years ago

Implementing the logic in esil, if that's what you propose, will be convoluted and slow.

My latest thought is, that I could hook mem_read/write in anal, i.e. read/write from/to registers when certain memory locations are accessed by esil. Unlike reg_read/write that should be compatible with the ar commands. But if a user uses p/w commands, memory content may be different from register value seen in esil and ar commands.

astuder commented 6 years ago

Looking into the code, using anal cb.hook_mem_read/write: Some commands, e.g. aea and debug breakpoints, overwrite these without restoring or chaining existing hooks. I.e. arch dependent hooking will break. An option may be to hook into cb.mem_read/write instead.

radare commented 6 years ago

Yep

On 30 May 2018, at 21:03, Adrian Studer notifications@github.com wrote:

Looking into the code, using anal cb.hook_mem_read/write: Some commands, e.g. aea and debug breakpoints, overwrite these without restoring or chaining existing hooks. I.e. arch dependent hooking will break. An option may be to hook into cb.mem_read/write instead.

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

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of radare2. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.