Buffer overflow: Why does the ESP Register change its value after access violation

Question

Background: Currently trying to exploit a BoF vulnerability. After setting up the environment, running a compiled C program that contains the strcpy function, I disassembled the program as it's running in the Immunity Debugger, so the data at the program's stack during the moment of the crash can be analyzed, and exploited.

Problem: Then according to the researched tutorial videos and blog posts, the next step is to find the offset in the corrupted string that contains the data that is overwritten in the values of ESP and EIP registers. This is done so we can find a JMP ESP instruction in the exe and overwrite the return address (EIP value) using the memory location (w/o bad characters) of the said instruction.

Question: All of the above were done to be under the assumption that the stack pointer (ESP) is pointing at the memory block that contains the payload right after the overwritten and the access violation. So tl dr my question is: How can the ESP be pointing at the payload if it's always supposed to be pointing at the top of the stack?

Visuals, please help explain: Sorry for the smaller size picture. But the picture came from the great Professor Vivek of securitytube.net's SPSE class.

Additionally If someone can please help explain what the ESP value was before and after the crash, and why would the value of ESP be changed to be pointing our payload? is it because of the function creation/death of strcpy, and if it is, how does it play a role in the changed ESP value? The source code is set up like such:

#include <stdio.h>
#include <string.h>

void vuln_func(char* inputstring)
{
    char* buf[100];
    strcpy(buf, inputstring)
}
int main()
{
    // gets input_string 
    vuln_func(input_string);
    return 0;
}

Update: The comment by @gameOver within his answer asked about what the 4141 was in the visual given. Here is a better explanation: 41 is hex for the ascii character of A. Which is what the corrupted string contains. And what the corrupted string contains up to the EIP (returned address) offset is completely arbitrary, in this case was a string of "A", then the return address offset is written with the memory location of JMP ESP, and after that the corrupted string contains the payload to be executed. (Which is where the ESP is pointing at during the crash) Hence my question, why was the ESP pointing at the payload when it was supposed to be pointing at the top of the stack?

Answer 1

As you correctly pointed out ESP always points at the top of the stack. Also stack overflows occur due to an overflow of a buffer on the stack (not due to an overflow of lets say a malloc-allocated buffer). So when you do:

char* buf[100];

you are actually allocating some space on the stack for your buffer. To illustrate this:

This buffer's initial state/contents, before it gets overwritten with our input, is unknown and can be observed using a debugger, like gdb. So if you go and overflow that buffer with your input, you will overwrite everything that exists on the stack (check the above image to see in what direction the overflow will occur), so you will overwrite EIP to point to whatever you want it to point to. Now, when a function returns (most of the times using RET instruction) it pops EIP and also performs: add esp, 4. In this way ESP will point to the last parameter pushed on the stack when the function was called, in your example/picture this parameter is Arg 1 (since arguments are pushed on the stack in reverse order). So the picture you posted is correct and shows the state of ESP when the function returns. So if you find an instruction like jmp esp etc... you can directly jump to the location of your payload.

But that is not the only exploitable case. So, its a good practise to use a debugger and observe if any register points to your payload, and if it does search for a jmp reg instruction. For example, in this post, you can see that both ESP and EDI point to the payload.