This question is primarily in the context of arbitrary command execution in a buffer (e.g. stack) overflow.

I read somewhere recently that hard-wired (absolute) addresses are not good for shellcode e.g. using /bin/sh for example. The problem is that it means the code isn't position independent.

However, I don't understand why hard-wired addresses wouldn't be preferable to relative ones. Wouldn't hard-wired addresses mean the desired libraries/calls used in the attack are accessible from wherever the code (i.e. it is position independent) where relative addresses mean that the code has to be in the correct place relative to the call?

  • It sounds like you are confusing hardcoded addresses with absolute paths. A hardcoded address is something like 0x77c8a000, whereas an absolute path is like /bin/sh. Calling a shell or another standard executable directly like that is generally not an issue, whereas referencing a hardcoded address is not a good idea because it may change on each invocation.
    – forest
    Commented May 14, 2018 at 1:13

2 Answers 2


There's two types of issues that I think you might be conflating. One is the address of functions called by your shellcode that are provided by the vulnerable application or by libraries loaded, and the other is absolute versus relative jumps within your shellcode.

Library Calls

Let's assume, for a second, that you're attempting a return-to-libc style exploit on a simple binary. So you want the address of system for a lot of such exploits. Let's build a small binary that prints the address of system.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
  printf("system @%p\n", system);
  return 0;

Compile and run this a few times:

% gcc -o getsystem getsystem.c
% ./getsystem
system @0x7fdc54419d40
% ./getsystem
system @0x7fbc15b61d40
% ./getsystem
system @0x7fbeacfb6d40

Notice that each time it is run, the address of system has changed. This is due to a modern security mitigation called ASLR: the C library is loaded at a different base address, so system will be loaded at a different address. Consequently, your shellcode needs to first locate libc, then call system at an address relative to the start of the library. (Called the "base address".)


In more complex shellcode, you may need to make a jmp or call within the payload itself. In such cases, you must have relative jumps and calls, because you do not know the exact address where your shellcode will be loaded. Instead of saying "jump to 0x0804abcd", you should have "jump 5 bytes forward". This is what is meant by "Position-Independent Code": it can operate when loaded at any position, and not just at some fixed starting address.

Because shellcode is usually loaded on the stack or heap, both of which are subject to various manipulations (ASLR, other data using the stack/heap, threading, etc.), it's impossible to predict an absolute address where your shellcode will land.


Relative addresses will always have an upper hand over the hardcoded ones, why? let me explain:

  • Let's say you run the application again after exit or a reboot, it may not get loaded onto the same addresses in memory
  • ASLR - Address space layout randomization- a security feature in OS systems which will never load the executable in the same space... this will mean that the addresses would be different every time, hence hard coded addresses won't work and you will have to change it every time which is really lame and only works.
  • Say, you want to jump to a specific address, instead of jmp [address] it would always be good to be relative to some register such as jmp ecx+8 and this won't change even if the addresses change.
  • Thank you for the answer! I think my confusion is maybe what addresses are being referred to as "hardcoded". In the example I saw, the shellcode simply executed a system call to "/bin/sh" to create a shell. Why would there be a problem there with hardcoded addresses? (That said, perhaps the comment about addresses being general and not just talking about that specific example.)
    – Bea
    Commented May 18, 2017 at 10:44
  • Can you share the shellcode for a better view of things? Commented May 19, 2017 at 8:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .