Executable linking/loading workflow

20 views Asked by At

I'm having a bad time understanding how multiple concepts work simultaneously for achieving linking/loading correctly an executable: the first two objects of those are

From the very beginning loading/linking is basically the art of putting another layer of abstraction over concrete memory addresses to achieve using the same piece of code over multiple executables (could be a shared lib linked to multiple binaries, an external library statically added in your code or even the same instance of a program under different memory assumptions like virtual memory|overlays and so on).

See Relocation wikipedia article, it explicitly states Relocation is the process of assigning load addresses for position-dependent code while Linkers & Loaders states Relocation is the process of assigning load addresses to the various parts of the program, adjusting the code and data in the program to reflect the assigned addresses. Question is my common sense says to me that relocation should not be tied to position dependent/independent code since always you need to attach concrete addresses to a program formed by multiple subprograms (let's say libraries), isn't it?. Also relocation is tied (as my current undestanding is) to linking while position independent(ness?) should be a loader concept since the idea is using a program regardless where the OS put it on RAM. Now second question is, how does position independent code works along virtual memory because for me seems like virtual memory solves the problem of loading stuff wherever you want (maybe not security issues though).

Let's keep going, while watching ASLR it shows Program possible load scenarios as a way to randomize how stuff is put on the RAM at runtime. Multiple questions arise from here

  • The usual understanding of the heap/stack is broken, isn't the stack should be in decreasing order and the heap in increasing order (to avoid collisions between them)?. How is this handled now and how does it affect paging? (I imagine that a random layout would inevitable lead to ask pages to the OS quicker than the old classical layout, maybe I'm wrong)

  • This seems to need another relocation step(s?) here in order to fulfill loading a program which previously was statically understood (talking about layout without counting shared stuff) but in the fly was loaded totally different. How does this relates to position independent code?

There is a great resource on virtual memory, see Architecture and operating system support for virtual memory, but I might be not fully understanding how this play around with linking/loading (and the concepts above PIC/ASLR) in the big picture on a per process basis. I need help here because I'm a little bit lost (just began with malware analysis stuff that's why I'm interested in this low level stuff), if someone is able to help would be really appreciated.

0

There are 0 answers