Hey there.

I want to create a reloctable upon assembling my binary file in order to relocate the absolute addresses during runtime.

I am not sure what the best way to do it is. I was thinking og listing the offset of all instructions at the end of the file and relocate the instructions using memory addresses.

I would appreciate your suggestionsm

You can always write code that doesn't need relocation, i.e Position Independent Code (PIC).

In 64-bit code use RIP relative addressing.

In 32-bit code, it is more tricky, but you can sacrifice one register to hold the EIP value.

Will this work if I have declared variables?
Basically I want to inject the code into the same process. (VirtualAlloc)
How do I retrieve data/variables on PIC?
And if I do call @f, wouldnt I need to relocate that pointer?

Edit: Wording

You access variables by offset from the EIP value using EBX (or whichever register you chose) based addressing.

The thing is though. This code is going to be injected into a process.
If I am calling .offset, this is an address which may not work when the base address is any given address by VirtualAlloc. I would need to relocate the call to .offset, correct?

No need to relocate, call is already relative. The same with jmp and jcc.

I gotchu. Thanks a lot.
I hope people appreciate the amount of help u provide to this forum. You are helping so many ppl out. Thanks dude!

One question though: How come referencing variables isn't relative? It's not "far" away from the code.

That is a question for Intel to answer. It stems all the way back to the very first 8086. It's always been that way. But then along came AMD and put RIP relative addressing in the 64-bit extensions.

All right! Once again; thank you for all the help.

MUFOS

It is actually. Data is normally located in a different segment, so are rather "far", even though the segment selector part is always implicitly derived from a segment register, and not encoded into the instruction as with far pointers in control transfer instructions.

For that reason the rip-relative addressing of data introduced in 64-bit mode is tightly coupled to the way segments are handled in the 64-bit mode.

Rather than the existence of segmentation as the reason, I more suspect it is the lack of explicit IP register. In the same way as SP using SS by default, it 'could' have been IP using CS. Or it 'could' have used absolute offsets for call near and jmp near; the existence of segments wouldn't affect that. However it makes no difference what is the actual reason, we have what we have and no amount of speculation will change it.

revolution
This is not about speculation or attempts to change anything. It's about understanding motivation behind technical decisions, and your understanding is unfortunately poor. I can't see any reasoning behind the assumption regarding the "explicit IP register" (I guess you mean, IP as a general purpose register). Neither x64, nor aarch64 have this, but it doesn't prevent these from providing ip-relative data accesses.


It did and it does. Relative control transfer instructions use the ip-relative addressing with the implicit cs. The point is that accessing data in an ip-relative manner did not make much sense, because the data was supposed to be located in a different segment (which in turn also had well-founded argumentation) that could have had any distance (in terms of linear addresses) relative to the currently executing code.
ip-relative addressing makes only sense if both code and data are anticipated to be relocated as a single blob, which is not the case for a model with data and code located in different segments. Why would you be willing to forcefully involve an additional adder into every single data access, if you can directly use absolute addresses instead. This is obviously different to ip-relative addressing of code (see above), where you have an adder to increment the ip anyway. If you look at aarch64, ARM abandoned not only pc as a gpr, but also pc-relative stores, because they mostly anticipate only read-only data (in the usual form of constant pools put directly after functions) to be put in combined chunks with the code.