Ascii of D00M

Posted on

WooWEEE!! You guys are going to be. in. for. a. treat! Have you guys ever encoded your own payloads?? You will now if you follow along!!

For this tutorial, I am going to be using SipXezPhone. This application is vulnerable to yet another SEH Overflow due to a long CSeq header. By now, you should already know how to exploit an SEH overflow, but if not…never fear for you can take a read here. Now the direct download for this app is here as well if you would like to follow along. I chose an easy one that way you won’t have a complete meltdown 😉 On that note, if you are feeling rather adventurous…please, please, PLEEEEASE feel free to venture out and practice more. After all, practice makes perfect right?? With a bit of math, you are going to create a little bit of evil doings and it doesn’t have to stop at message boxes or calculators 😉

I hope you like doing math because you’re going to be doing quite a bit of math with repetitiveness orrrr…you can flex them scripting muscles! Let’s take a look at what we’re getting into today…

  1. Finding our problem
  2. Work with what we’re given
  3. Exchange numbers for letters
  4. Math and Wizardry
  5. Profit

 

Finding our Problem

By now, you should be already be familiar with the mechanics of an overflow. At this point, we are going to encode our payload with ascii characters. You’ll see how letters will turn into your best friend, their enemy 😉

So how does this work?

It’s that time of bringing back the tedious task of finding bad characters. After sifting through 0x01 – 0xFF and taking out all the characters that will truncate your payload, you’re obviously left with good ones. For this particular application, our list of bad characters contain the following:

So since we are using ascii characters, we will then need to narrow that list AGAIN to contain the following allowed character set of 0x21 – 0x7E. Take a look at the following table to see how I got those values.

 

As a sidenote, the commands are limited to that of what your character set allows you…hehe

Also, this payload will only be good for one session due to ASLR. Once you restart, it will no longer work. Can you put in the work to make it reliable?? 😉

Our payload is going to be a message box. It’s going to say, “ASCII of D00M” for that is what we will be bringing 😉 This message box is only good for one session just for the sake of less bytes!

Awesome.

So we have a piece of our puzzle. Let’s get into some other things like…encoding, shall we?

One point to bring up is how everything gets ran when inside a debugger. This will make sense for the next couple of sections. Hopefully by now, you would have seen how everything works. If not, that’s okay!

So when you are stepping through your instructions in the debugger, you go downwards. Just a gif, it actually doesn’t go back up, haha

Now this is getting ahead of ourselves just a bit, but as the instructions start getting executed, it will land on the address that we target. From there, it will begin to grow upward. For this example, I am just going to put in junk so you can see it growing upwards.

growing

So now that we have the gist of how that works, on with the show.

 

RELEASE…THE MATH!!!

So once you pass the exception and and take the jump to your payload…you are now going to make the magic happen. The interesting thing about this is watching out for your sizes. You have to take account the size of the encoded payload, as well as the size of your decoded payload. As of right now, we know our Message Box is 59 bytes. You will also need to split your payload into four bytes.

At this point, I encode the payload FIRST an-

Excuse me, but why do you do that first??

Good question! Not only will you need to create your encoded payload, but you also have to calculate the addresses you need and incorporate that into your shellcode. And we will get into that after this portion.

As I mentioned earlier, we will be using numbers to bring out letters. So what we need to do in order to achieve this is figure out a way in coming up with four bytes in order to get our desired values. To do this, we will be using two’s compliment. You can take a read here if you are not familiar with what that is. I have another code snippet that you can use to do this for you. Think of this as a very helpful calculator that has no features, haha 🙂

Remember how we went over how the debugger acts when you are feeding it instructions? Because of this, we need to work backwards, meaning we need to start from the bottom and work our way to the top. So the first address we will be using will be:

Running that with my simple script will output the following and give us what we need to come up with:

Now we know what we have to come up with to insert our payload into the application by using a set of SUB commands…into our EAX register. Why EAX? Because it is used for doing calculations. BOOM.

As a side note, for a good, quick guide for what these registers do…please take a read here!

Keeping 6f29008b in mind, what values in our allowed character set can we use to come up with this? We need three sets of four bytes…

Let’s take a look at solving this problem. There are several ways of getting these values and the way I do it is by starting out with division and go from there. Remember, don’t pick any other values other than the ones in your allowed ascii character set.

So, to keep this simple…I will show you instead of explain

 

So what about numbers like 0x00 or 0x29? The values needed for that do not fall under any ascii character. Obviously we can’t do that. So what can we do?

The answer to that is by “overflowing” the bit by adding a “1” in front. So 0x00 now becomes 0x100 and 0x29 now becomes 0x129. So when this happens, we have to borrow from the next bit. Sort of like subtracting 18 from 22. Confused? If so, that is perfectly okay. You will see it.

Awesome. So let’s double check our math and see if they do add up to the value that we need…

Sick 🙂

So all that is just for one part of your payload. Now this can get extremely tedious and time consuming. Unfortunately for me, I can’t really figure out how to fully automate it. On the bright side, I have the majority of it automated in pieces. Couple scripts to do the job 🙂

Don’t think we are done with 0x90d6ff75. That was only coming up with the value!

Earlier I mentioned that we will be working with the EAX register. I also mentioned that you can only use certain instructions in your allowed character set. Usually you can just XOR out the register and call it quits. With ascii encoding, it is different because EAX doesn’t translate into a character that we can use. So if you can’t XOR EAX, how else can you get your register to zero out? How can you create a clean slate with what you are working with?? Let’s have a look…

Are you familiar with AND? Check out what it does:

Here is an example of that if you have no idea what you are looking at. Take a look at decimal numbers 41 and 21 and turn them into binary:

If you follow the rules on that table, you only get a “1” if you have a “1” and “1”. As you can see, you don’t have any instances of that. So any combination of anything else such as “0 0” or “0 1″…you are going to get a zero. Pretty clever way of getting zero, don’t you think?? 🙂

Now, to find something that will zero out your register with your allowed character set can be a bit time consuming by hand or a tad bit tedious with calculator. Instead, I made another little snippet that does exactly this for you rather quickly…and again with no features, hehe

As a side note, please keep in mind the below script allows ALL characters. Just keep an eye out. With a little modding, you can include the filtering but I’ll leave that up to you if you choose 😉

So let’s put that together now with what we already have! Doing so, we come up with this:

Sweet.

All that’s left to do is push it to EAX, go to our next address and repeat the process. all. over. again.

You should end up with something like this:

Your entire payload, excluding the additional instructions to tell it where to decode, should be more less 400 bytes.

Now that you know it’s going to be around 400-ish bytes, we now have an idea of how much space we need. Next thing to do is work on getting our encoded payload to land somewhere that will begin as a starting point for our payload to grow.

 

Pointing to our Address

When you are looking for your address, the way to get these values is by subtracting the address ESP is at by the address in memory that you want. I am going to use the following address:

This is PLENTY of space to house our 59 byte payload.

Sweet.

So…how are you supposed to subtract that from an address we don’t have?

Again, our debugger comes to the rescue! With literally two instructions, we locate the address we need to subtract from. Before we locate the address, be sure to zero out the EAX register again. Let’s see what we get by executing this:

Take a look at EAX. We  now know the address of ESP: 0x03e3f568.

We aren’t quite done with all the math yet as we are about to do it yet again…I’m sorry 🙁

I think at this point, you should be realizing that tools such as Veil-Evasion, MSFVenom, and any other encoder has been spoiling you.

So now…here is what we have to do:

  1. Subtract the memory address you are wanting to decode from ESP
  2. Find three sets of four byte values to equal the value from step 1
  3. Push EAX
  4. Then pop ESP

Easy enough? Fair enough. Let’s dive in and start taking this thing apart.

The awesome part about this is you don’t need to find its compliment. So what values can be taken to equal the result? Let’s take a look:

As a side note, if you think you are a genius and don’t need to double check your work…I would HIGHLY suggest that you start because one letter or an overseen typo can throw you off 😉 hehe

Awesome 🙂

As before, we need to push into EAX and then pop it into ESP. So in the end, we will end up with this:

As a side note, in case you are wondering why we are using SUB commands instead of ADD commands, ADD translates to 0x05. What ascii character is that??

Awesome!! Now if you step through those instructions along with your payload, you are going to notice you payload decoding at the address you want more/less 🙂

Very nice.

Now putting everything together will give use the ascii characters needed to begin to do some damage 😉 You should end up with something similar:

Now how cool does that look?? Amazing.

So after inserting our new payload and running our POC…we get the prize that we worked so hard for:

Recap

After everything is said and done, you are going to have a pretty hefty payload.

  1. We started out with our Message Box which was a total of 59 bytes.
  2. We then encoded our payload using ascii characters with quite a bit of math. Luckily for scripting, Python had came to save the majority of the day.
  3. After encoding, our Message Box then becomes 419 bytes.
  4. In the end, we ended up with a magnificent looking piece of shellcode that YOU created by YOURSELF

Now how rewarding is that?? If you trooped on and fought the good fight, seriously, give yourself some ice cream or something because the average Joe would’ve quit a looong time ago. You read through quite a bit of information!! If you are asking yourself why put yourself through all of this when you can use Metasploit’s MSFVenom or any other encoder…well…no pain no gain, hehe 😉

For me, it’s more of a “I did that”.

As always, I hope you picked up a trick or two and had as much fun as I did creating your own encoded shellcode 🙂

That’s all for this post folks!

 

 

 

Leave a Reply

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