I don't know off the top of my head if there's an option you can set for that, but that's the type of thing that's utterly trivial to write a Hex-Rays plugin for. I bet that would be less than 25 lines of code. If you can send a link to a binary, I'll write a script to demonstrate. Assuming you're writing IDAPython (the details would only be slightly different in C++), the outline would be:
- Derive a class from
mop_visitor_t
, whose visit_mop
method: requires is_target
to be false; compares the operand against mop_r
; if so, compares the .r
union element against the microregister number for r13
. If found, replace the operand with
your constant (i.e. call mop_t::make_number(0x40000000)
on the operand).
- Derive a class named
R13ReplaceHooks
off of ida_hexrays.Hexrays_Hooks
.
- Override its
microcode
method to call mba_t::for_all_ops
with an instance of the visitor above.
- At the bottom of the script, a bit of glue code to allow easy installation and removal of the hook, as in:
try:
r13replacehooks.unhook()
del r13replacehooks
except NameError as e:
pass
finally:
r13replacehooks = R13ReplaceHooks()
r13replacehooks.hook()
- That's it.
===== EDIT TO ADD =====
After writing the answer above, I had some further thoughts on the matter.
Red/orange variables and warnings about values being undefined is not what I would expect in this situation. Rather, I would expect that you would see a bunch of __usercall
prototypes that had r13
as an argument, and then you would see nasty pointer arithmetic typical of code that needs a structure definition, as in *(QWORD *)((QWORD)x + 20)
. So I guess an alternative answer would be that you could add those arguments to the function prototypes, declare one big structure for the data section in question, and define the r13
__usercall
arguments as being pointers to that structure.
I tend to think that the other answer would be generally easier to work with, but this approach does have one upside: you can use Hex-Rays' "Jump to xref globally" feature to track cross-references to the data members. This won't be the case for the register replacement approach in the other answer, since the references aren't really there in the code; in the other approach, those references will be created on the fly, and not stored in the database in a form that can be browsed through the normal cross-reference machinery. In this approach, the references will be available persistently via the structure cross-references.