Firstly, I'm sorry if this post doesn't fit exactly here, or may be fit better in RE. We could move it if necessary.

So, I was reading this writeup about an exploit in vulnserver (for those who don't know it, vulnserver is a program designed with flaws in mind, this is, to practice exploitation techniques)

At at certain point, it says:

In this step we have to check the registers and the stack. We have to find a way to jump to our buffer to execute our code. ESP points to the beginning of the C part of our buffer. We have to find a JMP ESP or CALL ESP instruction. Do not forget, that the address must not contain bad characters!

This makes sense, but; Wouldn't be possible and easier to directly jump into the stack since we control EIP? (We are assuming ASLR and DEP are disabled of course). Mainly because:

  1. How does he know ESP points to his shellcode? Why ESP points exactly there? Shouldn't it point to the end of his shellcode instead?

  2. How is this supposed to work trough reboots or in different computers?


  • He knows ESP points to his shellcode because that's what his debugger told him. At the time of the crash, he examined the registers and determined that ESP points to the beginning of his buffer. The reason he's not jumping directly into the stack (i.e. overwriting EIP with a hardcoded stack address) is presumably because
    – Hello
    Commented Apr 16, 2017 at 20:53
  • 1
    I'm almost certain that he's assuming ASLR is enabled. Jumping to hardcoded addresses is unreliable because they can change. The technique is called ret2reg.
    – Hello
    Commented Apr 16, 2017 at 21:27
  • 3
    The reason why it's ok for the address of the jmp esp to be hardcoded is because the instruction resides in a DLL that doesn't have ASLR enabled. The stack has ASLR, however.
    – Hello
    Commented Apr 16, 2017 at 21:30
  • 1
    That's just where it happened to be pointing to when the application crashed. You won't always get that lucky (i.e. it can be pointing to a location a few bytes before the shellcode or even in the middle of the shellcode, or nowhere near the shellcode).
    – Hello
    Commented Apr 16, 2017 at 21:39
  • 1
    @Hello You probably could have put those comments into an answer.
    – RoraΖ
    Commented Apr 20, 2017 at 18:08

2 Answers 2


Your exploit payload ends up on the stack because you're overflowing a buffer on the stack, and this is how you gain control of the return address as well.

ESP points directly to the start of your payload (after execution of the ret in the function you're attacking) because you put the payload right after the 4 bytes that overwrite the return address on the stack. ret pops 4 (or 8) bytes into EIP, leaving ESP pointing to the payload that directly follows.

But you don't know what value ESP will have at that point, because of stack ASLR and because a different depth of call stack leading up to this point could change the address. So you can't hard-code a correct return address.

But if there are bytes that decode as jmp esp or call esp anywhere at a fixed (non-ASLRed) address in the process's memory, you can hard-code that address as the return address in your exploit. Execution will go there, then to your payload.

This is in fact often the case: Some DLLs don't have ASLR enabled for their code, and the main executable's code may not be ASLRed either.

Code ASLR for all code defeats a jmp esp attack, unless the attacker can cause the target process to leak addresses.

Note that for 64-bit code, you're unlikely to be able to use jmp rsp for string-based buffer overflows, because code addresses will contain some leading 0 bytes.

Thus, jmp esp gives you a much more reliable exploit than repeatedly guessing a return address (with a very large NOP sled).

Repeated guessing will crash the target process every time you're wrong, but a jmp esp can give you a high chance of success on the first try. This will avoid leaving crash logs. It could also defeat an intrusion-detection system that looks for crashing server processes and blocks connections from your IP address, or similar.

Note that the 2-byte instruction you're looking for can appear as part of another instruction when the program executes normally, or as static data (especially read-only data is often in executable pages). So you just need to search for the 2-byte sequence, not for jmp esp in disassembly of the program. Compilers will never use jmp esp, so you won't find one that way.

More generally, any function that ends with a buffer pointer in any register (e.g. from a memcpy or especially strcpy) can allow a ret2reg attack, by looking for a jmp eax instruction.

This can work in 64-bit mode, where addresses have some high zero bytes; if strcpy's trailing zero writes that high address byte for you, the end of your exploit string could be the non-zero address bytes that overwrite the return address on the stack.

In this case, the executable payload would go before the return address, at the spot in the buffer where the function leaves a register pointing. (Typically the beginning of the buffer if there are any useful pointers to the buffer in registers at all).


After a buffer has overrun, ESP has the shellcode. You could verify it in immunity, EIP has to point to ESP. My understanding is before the exploit, the system DLLs, should use ESP, depending on when the DLLs are called.

But after the buffer has been overflown, EIP has no idea where to point at. Note that, the 4 bytes we pass to EIP can be any of the [jmp ESP] addresses.

So it goes like this -

  1. Overflow the buffer exactly till EIP
  2. Pass [jmp ESP] address to EIP
  3. Stored value in ESP gets executed (NOPs + Shellcode)

I wrote an exploit and used variations of address at [jmp ESP] and each time i could exploit the vulnerability.

Here's the exploit.py, note i'm using RPCRT dll. But we can use shell32.dll and other system dlls as well.


I'm using shell bind shellcode with some extra NOPs.

BTW if the OS has some kind of protections or the compiler has added some protections while compiling the original src code. This'll become a treasure hunt to find the location of the shellcode. We'll then need to use several jumps to get to the shellcode.

Hope that helps!

  • I was not exactly asking this but I think I understand everything now. The issue was that I was also missing the exact functionality of the ESP register: (from c-jump.com) The ESP register serves as an indirect memory operand pointing to the top of the stack at any time. As program adds data to the stack, the stack grows downward from high memory to low memory.
    – 78dtat78da
    Commented May 31, 2017 at 15:10
  • So yeah, basically our ESP will always point to the beginning of our shellcode, and a JMP ESP is therefore convenient.
    – 78dtat78da
    Commented May 31, 2017 at 15:29
  • @Sangram Kesari Ray did you change your github handle? The repo link provided gets a 404 now.
    – pmalbu
    Commented Jan 21, 2021 at 23:01

You must log in to answer this question.

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