Intro to Buffer Overflows

Buffer overflows. How fun they can be, but intimidating if you have never fired up a debugger of any sort. Little numbers everywhere in four different boxes, with each box having its own specific purpose. Awesome. Get what you need first so that way you can follow along, and kick some ass!

Let’s do a quick run down on what you’ll hopefully learn:

  1. Basic fuzzing
  2. Debugging
  3. Bad character analysis
  4. Exploit dev


What the world is fuzzing?! Fuzzing is just throwing a whole bunch of craziness to see if you can cause anything to happen out of the norm like sayyyy I don’t know…a crash 🙂 You can test it manually, or you can automate the task. You can also use software that specializes in it, but let’s do a basic one. This case, we can just yell at PCMan and see if we can make it cowerrr!!

So here’s a fuzzer. It’ll start by throwing 200 A’s at the server and won’t stop until it reaches the max of 40 iterations. It’ll keep growing in increments of 200 bytes until it crashes. W00t!

Now, can we crash it?? Cue the maniacal, dark laaaaugh…

Debugging and Building the Magic!

To set your lab up, you have to do three things. Install the server, Immunity (along with the provided Python installer), and throw Mona into your PyCommands folder. After that, you are set to go! Poke around the debugger, get a little familiar with it. Know how to set a few break points, how to navigate, etc. Now on to the fun stuff. Let’s attach the server to Immunity and begin yelling at our target.

Do you notice how after 2400 bytes, you see LOTS of A’s pretty much take over ESP, ESI, and the prized EIP?? Let’s pause to talk about ESP and EIP.

ESP is the Extended Stack Pointer. We check this area when we are going through and trying to single out our bad characters. Bad characters will cause our payload to not execute, which is obviously not good for our exploit.

EIP is the Extended Instruction Pointer. Gaining control of this instruction is CRUCIAL to our exploit. Once we can control this particular location, it is pretty much game over. We can control execution and tell it where we want it. Do you see why this is pretty important? 🙂

Ok, back to the crash. In the last sentence, I mention controlling EIP. We have to find at what position the four characters are out of the 2400 bytes that will overwrite EIP.

Lets begin by building our exploit. We know that 2400 bytes crashes the server. We build our skeleton and run the exploit again to make sure it is 2400. You don’t need to, but I would recommend it.

After doing so, Metasploit has an awesome tool called Pattern Create that does exactly what it sounds like. The plan here is to feed it the output, retrieve the EIP address, then feed the address into another awesome tool called Pattern Offset. This will give us the exact byte that begins to overwrite the EIP.


Notice the address EIP gave us? It is 43376F43

We need that address to plugin to Pattern Offset.

Sweet! So after sending 2001 bytes, the next four bytes will overwrite EIP. Next thing to do now is update our skeleton 🙂

Let’s take a look at the registers after firing this bad boy!

Notice how EIP shows “42424242”?? That translates to “BBBB”. Bingooo…we now have control of our coveted register!! What’s next on our list…

Hunting for Bad Characters

Next thing to do is to figure out our bad characters. One thing I never include is “\x00”. That is a null byte that would ruin your exploit for sure! Wait, but how would you check for that?? Easy! You have to feed all the characters into the program using your exploit. Let’s update our script to include the bad characters. Also, take note of it being put at the end of payload.

After sending our exploit again, this is where the fun part begins. Get ready for some action packed, heart pounding repetitiveness…It’s going to get exhilerating!! We go to our ESP register, right click to follow in the dump. You’ll notice your A’s, B’s, and then your characters will show up in order. Well, they should.

IE6 - WinXP-2016-05-01-01-14-53

Notice how you see your numbers in order? After \x09, \x0a should have appeared…yet it didn’t, but it threw off the count. We need to take that out. This process will be repeated until you have \x01 through \xff with the exception of the bad characters. See how this can be repetitive? It can be a pain! 🙂

After several minutes, we find the bad characters for this exploit are: \x00, \x0a, and \x0d. Let’s move on to the next step…

Redirecting Code Execution

Last thing on our list is to find a “jmp address” so we can redirect code execution and land on our shellcode. What we are looking for in this case is “\xff\xe4”. To find this, we can’t just replace our four B’s with \xff\xe4. No sir. We find this by seeing what modules this server runs and checking in these modules for ffe4. Our good friend Mona comes to the rescue.

There are two things that you need to check for when looking at these modules:

  1. Make sure there’s no protections like DEP and ASLR. That’ll prevent you from having a working exploit. DEP is Data Execution prevention which does what the name says. It prevents code execution. ASLR is Address Space Layout Randomization. This also helps prevent shellcode from happening. With ASLR, the address of the modules are always changing and will NEVER be the same.
  2. Your jmp address does not contain any of the bad characters, which in this case are “\x00,\x0a, and \x0d”.

What I do to find this is call Mona from within the debugger


I’m going to use this address, shell32.dll because why not? Looks good to me! 🙂

Another thing about this address is we are working with little endian. So instead of writing the address out as you see it, you would write it out backwards. So you would have 0x7cb41020 and rewrite it to \x20\x10\xb4\x7c. Simple, huh? Now, to make sure we are actually hitting this address, we need to place a breakpoint on this address and then update our exploit. Double clicking it takes you right were you need to be. Notice FFE4?? Very nice 🙂

Now after we fire off our script, we immediately hit our break point! You still here?? Hang on, we’re almost done 🙂


Generating our Payload and Exploitation

Now that we have everything we need, another tool that we are going to use is MSFvenom. Such an awesome tool for generating any type of payload you can possibly imagine. It replaced MSFpayload and MSFencode, and probably for a really good reason! If at any point you need to read a little more on how to use MSFvenom, please refer to their tutorial.

The payload I will be using is “windows/shell_bind_tcp”. Attaching “–payload-options” will give you all the information you need to generate the payload.

Sweet. Let’s get to generating!  Another neat feature is the option to include NOPs, or No Operation instructions, as well! NOPs are there because Metasploit will essentially overwrite the first few bytes of the shellcode which would render it useless. So…NOPs are added 🙂

Whoa! What the heck is going on here?! That’s a really long command!! What does this sorcery even mean?! Let’s break this down. We selected a bind shell for Windows which opens up port 54321 on the target. We then threw in 15 bytes for NOPs and the output will be in Python. It is then encoded to exclude the bad characters so our exploit will not fail, and resulting size is 370 bytes. Not that bad, right? 🙂 Let’s fire it up and see if it works!! Moment of truth 🙂



Now, all there is to do is connect! After updating the script, you can then keep it like that or perfect it into a nicer POC 🙂 If you stuck this long, congrats! Hopefully you followed along, learned a thing or two, and keep on keeping on! It can get a bit tedious, but I can assure you if you really want it…you’ll get it. As the good ol folks at Offsec would say, “Try Harder!”

Here is my final POC if you are interested 🙂


8 thoughts on “Intro to Buffer Overflows

  1. Although I only understand about 70% of this tutorial your approach to the subject is exactly my cup of tea. I hope you continue making tutorials. I’ve read about buffer overflows and understand whats happening, but I had never seen such straight forward code like this. It really solidifies the understanding. Coming from a background in programming I surprisingly know very little about networking or binary exploits. I’m falling in love with Pen-testing because it fits my stubborn nature of not giving up and debugging until I get a solution that works. Thanks again for such a nice write up.

  2. That is the most neat tutorial I ever saw. Do you have some other software other than pcman ftp?
    I want to test more and more so I could get more knowledge on how different softwares responds.
    Thanks for the tutorial my man.

    1. Thanks a lot! 🙂
      So most of the software can be found on Exploit-DB. I chose that one as an intro because it’s pretty vulnerable and there is more than the way I went to exploit that particular application 😉
      If you want a different application, you can search for buffer overflow on Exploit-DB. One application you can try against is Easy FTP Server, which can be found here:
      Have fun! If you have any questions, feel free to ask 🙂

  3. I enjoyed your tutorial, thank you. I had a question about how you chose shell32.dll. You used mona to look for a module that does not contain ASLR and DEP. I see “ASLR: Flase” in the screen shot, but I do not see “DEP: False” anywhere. What do you look at to confirm shell32.dll does not have DEP?

  4. If your pattern offset was 2001 why at the very end of the exploit did you switch to 2006 which is a 5 byte difference before putting your return address in and then dropping the payload?

    I was able to follow this pretty well but when I got to the section to get the return address I didn’t have all of the options you had I only had 4 all of which were PCMan, and all of which contained bad characters, I chalked this up to the fact I was running this on windows 10 and decided I would need to get a Windows VM to test further– but this part with the switch from 2001 to 2006 in the full exploit code at the ending. This confused me.

    Other than that everything was clear! Great walkthrough!

    1. Howdy!

      My pattern offset is different because of the way the ftp and sockets modules handles the data. I don’t know why it handles the data differently, but that is why you see the difference. It threw me off a bit too 🙂

      As for your second, that is indeed why! Just a newer OS. If you want to see all those options and not see that nullbyte in the way, check it out with Windows XP. It may be possible to still get it going for Win10 with some creativity 😉

      Thanks for the feedback and keep kicking ass!

      1. I figured that out because when I got it working the payload only runs every 1 in 4 times, the other 3 times it won’t crash PCMan with my offset (by the way I used 2013) I ended up finding a different DLL with a JMP ESP in COMCTL32.dll that worked with windows 10, thanks so much for writing this I feel like I learned a lot and I popped my first shell without a tool! THE RUSH. Lol. — Anyway I’m working on your SEH based on now, I’ll save my questions for that post, though!

        Thanks for getting back to me!

Leave a Reply

Your email address will not be published. Required fields are marked *