flat assembler
Message board for the users of flat assembler.

Index > Windows > Create a reloctable without using PE

Author
Thread Post new topic Reply to topic
MUFOS



Joined: 17 Apr 2016
Posts: 47
MUFOS
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
Post 07 Aug 2016, 11:58
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
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.
Code:
call @f
@@: pop ebx ;EBX has the EIP value of the label @@    
Post 07 Aug 2016, 12:24
View user's profile Send private message Visit poster's website Reply with quote
MUFOS



Joined: 17 Apr 2016
Posts: 47
MUFOS
revolution wrote:
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.
Code:
call @f
@@: pop ebx ;EBX has the EIP value of the label @@    


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
Post 07 Aug 2016, 13:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
You access variables by offset from the EIP value using EBX (or whichever register you chose) based addressing.
Code:
 call .offset
.offset:
  pop ebx
  ;some more code
  mov eax,[ebx - .offset + .label]
.label:
  dd 0x12345678    
Post 07 Aug 2016, 14:14
View user's profile Send private message Visit poster's website Reply with quote
MUFOS



Joined: 17 Apr 2016
Posts: 47
MUFOS
revolution wrote:
You access variables by offset from the EIP value using EBX (or whichever register you chose) based addressing.
Code:
 call .offset
.offset:
  pop ebx
  ;some more code
  mov eax,[ebx - .offset + .label]
.label:
  dd 0x12345678    


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?
Post 07 Aug 2016, 14:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
No need to relocate, call is already relative. The same with jmp and jcc.
Post 07 Aug 2016, 16:09
View user's profile Send private message Visit poster's website Reply with quote
MUFOS



Joined: 17 Apr 2016
Posts: 47
MUFOS
revolution wrote:
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!
Post 07 Aug 2016, 16:56
View user's profile Send private message Reply with quote
MUFOS



Joined: 17 Apr 2016
Posts: 47
MUFOS
One question though: How come referencing variables isn't relative? It's not "far" away from the code.
Post 07 Aug 2016, 17:00
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
MUFOS wrote:
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.
Post 07 Aug 2016, 17:12
View user's profile Send private message Visit poster's website Reply with quote
MUFOS



Joined: 17 Apr 2016
Posts: 47
MUFOS
revolution wrote:
MUFOS wrote:
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.
Post 07 Aug 2016, 17:17
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
MUFOS
Quote:
How come referencing variables isn't relative? It's not "far" away from the code

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.

_________________
Faith is a superposition of knowledge and fallacy
Post 07 Aug 2016, 17:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
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.
Post 07 Aug 2016, 18:06
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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.

Quote:
In the same way as SP using SS by default, it 'could' have been IP using CS.

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.

_________________
Faith is a superposition of knowledge and fallacy
Post 07 Aug 2016, 21:51
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.