Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
While reverse engineering an executable, I came across specific strings of interest which where in the .rdata section:
How are these constant strings used by the underlying assembly code? Are offsets to the relevant strings dynamically calculated during run time (because of ASLR) and used?
The standard scheme for 32-bit x86 under Windows is that the compiler/linker inserts virtual addresses right into the code, which are calculated based on the preferred load address of the executable (usually 0x400000 for EXEn, and something like 0x10000000 for DLLs).
If the executable can be loaded at its preferred address then everything can remain as is and the relocation tables do not get used; otherwise relocations are applied to all address values embedded in code and data (e.g. when there are address conflicts and under ASLR).
However, when you are analysing an executable with a disassembler like IDA then the binary will usually get loaded at its preferred address, so that you can jump directly to (or through) the offsets contained in tables, and you can also search for the raw address bytes to find references that IDA might have missed.
IDA also allows specifying a different load address, so that you can match an ASLR-based rip without further ado. For hacking an ASLR-loaded image you'd need to do the rebasing (relocation) yourself, after finding the actual load address.
Of course, capable compilers like MS VC++ and Watcom allow all kinds of different addressing schemes to be used from high-level languages, like relative (based) offset addressing and so on. So the above is only a rough guideline.
Table-based references pose an additional difficulty during analysis: IDA will usually be able to find a string's reference in the data (i.e. the table itself) but often it is not easy to find the code that references the table. Most of the individual table entries seem to hang un-referenced in the air. Often you can use the regular structure of such tables to scry their beginning, and usually you can find that the first entry is referenced from somewhere in the code.
The address embedded in a table entry need not be the first item in an entry, though, so that the reference to the base of the table may be slightly off compared to the embedded address you're looking at. With optimising compilers it can get even trickier - the address embedded in the code might refer to the first address after the table, or in the middle of some record, or even several miles outside of the table.
In any case IDA should be able to help you once you have determined the extent of the table and declared it as an array (usually by formatting the first entry as a record and then setting the record count). Once you have done that, IDA knows that all references to addresses covered by the table actually belong to that table in some way or other, and usually you can already see a nice xref link for you to click. If not then you can call up the cross references manually.
Note: the setting under
Options | General... [Cross-references] Cross-reference depth
influences IDA's ability to spot xrefs that go somewhere inside data items instead of pointing at their beginning. Sometimes I increase the value to 1000, when I'm working with big structures...
