Stacks and Handlers and Python, oh my!

Another overflow, and this gone be goooood 😉 This overflow will be based on overcoming SEH and using it to jump to our shellcode thus executing our sweet, sweet payload. This way of exploiting it, we won’t need to overwrite EIP as the first step like we did in a regular stack overflow. We actually won’t need to bother with it all, but the concepts still apply. Also, this is done on a Windows 7 32 bit machine. From now on, I’ll try to keep everything on more recent OS’. Also…because it looks purdy.

We all know that catching shell is way more fun than actually reading about what these acronyms are so I’ll keep it short and simple, and then we’ll hit the fun stuff!

As always, it’s ALWAYS best to follow along. Reading and doing are totally different things as some may soon find out. So fight the good fight and I HIGHLY encourage you to follow along, and then look for one on Exploit-DB to do for yourself. It only makes you more ninja.

For this overflow, I have moved on to WinDbg and it is absolutely awesome! Smoother and quicker in my opinion. Only gripe I have is when you restart it multiple times, the debugger crashes when loading Mona after a couple restarts. Never tried to control that, but you never know 😉

We will be taking a look at the Easy File Sharing Web Server that suffers from an SEH overflow. You can get the software you need from here:

  1. Easy File Sharing Web Server
  2. WinDbg
  3. Mona

The actual webpage for WinDbg is here if you want to look yourself. I provided the direct download link in case you get overwhelmed with all the info they provide and not sure what to download. All the instructions needed are included in the GitHub repo for installing Mona.

As a side note, when running the sdksetup.exe, uncheck everything with the exception of the debugger and you’ll be good to go.

SEH? Whatchu tawkn bout Willis?

SEH stands for Structured Exception Handler. SEH comes in two parts: SEH and NSEH, or Next SEH. These handlers were put in place to pretty much prevent code execution outside the normal flow of execution. Yes, I’m looking at you buffer overflows… So what happens when an exception gets raised? So think of this as a list the OS has of anything that can go wrong, with a solution to what error it’ll raise. Check it…

SEH: “OMGWTFBBQ?! Something happened but I’m not sure what I can do!

–Scroll down the list…scroll more–

Can I handle it?? Should I keep going?? Is this what happened??

–Scroll a little more…–

Umm…here you go NSEH!”

NSEH: “Hmm…Gotcha! This is what we are going to do… <insert solution here>”

Then the NSEH goes on to executing whatever it decides on doing. Also, the way we see it is SEH –> NSEH, but the way you’ll see it when debugging would be NSEH <– SEH. Keep this in mind when we are creating our exploit! Now, how can we leverage this?? Because technically, you can’t execute code after this happens. Continue reading/doing and you’ll see how we will leverage this amazingzingness. Whew!! That was boring. Let’s get into the fun stuff now.


So in our last Stack Overflow tutorial, I went into fuzzing and how you can create your own. Because of this, I won’t go into the process and just use the amount the author specified. Keep in mind, the only thing I am taking from this is the format and the crash. Everything else is not going to be used. As you’ll see, we will have totally different results than ArminCyber.

To begin, our skeleton will be this:

If you take a look at the exploit, it says “entire = 4500”

Although it says 4500, I am going to up it to 5500 and see if that is good enough. Fortunately for us, it indeed crashed!

crash 1

So what happened here?? Let’s do a breakdown:

  1. We had crashed the service with our million A’s
  2. Since we are attacking SEH, we pass the exception with gN
  3. We then view our SEH Chain with !exchain

Notice how we have EAX filled with our A’s and after passing the exception, ECX and EIP gets rewritten?? Notice the SEH chain overwritten with A’s?? Very nice.  Let’s begin by gaining control…

Weaponizing our GET Request!

First thing we need to do is see where exactly our SEH gets overwritten. We can use this by, again, using Metasploit’s Pattern Create for this task. Once creating, we update our skeleton to include our new buffer.

After sending out pattern, we can load Mona through our command line and then calling it to find our pattern.

As a side note, when you are creating your exploit, just remember to keep passing the exception!! This is for each time you restart your debugger.

Sweet. So after 4,061 bytes, you should overwrite NSEH. Let’s test this theory to make sure we are correct! Remember how I mentioned earlier about the format of our exploit? Don’t forget that because it is about to get used now. Let’s update our POC now. For the sake of having to repeat that, you’ll see the POC instead.

Let’s rerun our script and hope for the best!

Sweet. We now have full control our SEH! All we have to do now is find an address that will work perfectly! The way you find that is by calling up on thy Mona again and asking her for our coveted addresses…

We have control of our registers. What’s going to happen next now that we have full control?? Well, we are going to replace our SEH with our Pop Pop Ret address 🙂 We are going to place a breakpoint on the chosen address, and if we hit it…we are going to begin our payload process!

Sweet! Let’s walk through what happened:

  1. We set a breakpoint on 0x100228ff, our Pop Pop Ret address
  2. After sending our exploit, we passed the exception with gN
  3. We reached our breakpoint, w00t!
  4. Lastly, we examined our registers and we can see our address waiting for us 🙂

If you continue stepping through, you’ll see the rest of our payload!

Notice how we have our B’s and now D’s? Sweet. What does that mean for you? We have to jump to our D’s. How can we do that? We have to figure out how many bytes we need to jump in order to reach that area. The cool thing about this is that you can let the debugger do that for you! Ahhh yisssssss!!!

Awesome! That was rather quick! Notice that two B’s were replaced with our needed opcode? So we need to jump six bytes to reach our destination and will replace our B’s with our new opcode!

On le Hunt of the Bad Characters!

In my last tutorial for the Stack Overflow, I went over the bad characters and why they should be left out and how crucial it is to hunt them down. Let’s do the same for this and find them. Our new POC will look as such

As a reminder, don’t forget to keep passing the exceptions! Also, don’t forget to set your breakpoints as well! Let’s run our new script and begin to search for them. At this time, you should already have the gist of how to find them. If not, refer back to my last tutorial on how to find them.


To give you an idea, the first bad character (with the exception of \x00) is \x20. Take that out of your characters, notate it, and continue until you get to \xff. Now for this program, you have six bad ones:

Generating Mah-jeek and Exploitation!

Coming back to our handy dandy MSFVenom tool, we begin by thinking of what we want to do. Do you want Calc? Reverse shell? Bind shell? The decision is up to you, but since I heart shells…I am going to go with yet another bind shell 🙂

Sweet. Let’s add this to our exploit, run it, and see if we can gain shell on port 12345…


Awesome!! Now for the poor soul that runs this version of Easy File Sharing Web Server, they are in trouble!

Hopefully, you have learned something and you can venture out and practice, practice, PRACTICE! WinDbg, itself, has a learning curve so fight the good fight and keep going! Don’t give up!! All we doin is keepn it coo 😉

This has been tested and working on Windows 7, Windows 8, Windows 8.1, and Windows 10 🙂

If you are interested in my pretty poc for this exploit, here is how mine is



6 thoughts on “Stacks and Handlers and Python, oh my!

  1. Man you’re good at this. I’m hoping to read more and more of your tutorials in the future.
    Interesting as always keep it up

  2. Alright Sir,

    So I’m having trouble wrapping my head around this one, I guess because of the use of two addresses. When we used overwriting the EIP to jump to our shellcode, it seems like it was a bit easier (that’s fine, try harder, right?) However with this one I got kind of gridlocked in windbg, I think it’s because of the nullbyte being in my POP ESI address, so I’ll have to look for another way in like I did in your last walkthrough, but before I continue can I run this by you to make sure I get it, unlike in the previous one this is what we are doing here:

    try {

    catch (error)
    exception raises at the address of the current SEH
    HEY! Fuck everything you thought you were doing, we’re going to do something else
    next SEH is reached, next SEH points forward in the stack to our shellcode
    shellcode executes

    Now if this is the case does execution stop at the point of the raised exception and resume when it jumps to the new exception?

    Honestly any light you could shed on this process would probably help me get through this, I mean I could probably bask in the glory of shell right now but I really want to understand it, thanks!

    1. First off, good job on the last one man! It’s always great creating your own exploit 🙂

      WinDBG was used because I wanted to start getting comfortable with it. It’s much more easier doing this in Immunity, so give that a shot so you won’t die with WinDBG if you haven’t used it before. There’s a slight learning curve to it, but it’s pretty great. As for your nullbyte, there are quite a bit of addresses if I remember correctly. Inside the debugger’s folder, it will have a file called “seh.txt” that will display all the addresses it has. Just go down the list and see if there are any without a null. If there isn’t one, run the debugger with admin privs.

      You got the gist of it. It just handles the exception. So instead of the, “HEY! Fuck everything you thought you were doing, we’re going to do something else and fuck yo couch,” it’s more like, “Oh shit, something happened. This is what we are going to do next.”

      The funny thing is once you set it off, it doesn’t point forward in the stack to our shellcode and shellcode executes. Instead, it stops you dead in your tracks and you don’t have code execution. Here is where all the fun starts…

      If you can overwrite the handlers, you can restore code execution by using a pop pop ret 🙂
      Once you have your ppr (SEH 0x100228ff), it’ll lead to your next controlled area (NSEH ‘\xeb\x06\x90\x90’) and you’ll use that address to jump to your shellcode. Thennnn you can execute the shellcode of your choice. Place a breakpoint on SEH (0x100228ff or whatever address you chose), and step through the instructions so you can see it happen.

      Hope that made it clear and keep kicking ass!

      1. Dude thank you for that, so it walks backwards through your payload then hitting the SEH first and then the NSEH and thats when you regain code exec because that’s the essence of the ppr? Okay man, this is really starting to make sense, I think I get WinDBG A bit better, I went and read some interesting papers on this but your reply solidifies it for me. Ahhhh I hate to ask this and all but do you think you could drop me an E-Mail if your up for some theoretical questions from an up n commer =O

        Either way appreciate the help ! Keep it up!

Leave a Reply

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