Deflowering Innocent Applications

Posted on

There are several applications that you can use without the need to install them such as:

  1. PuTTY
  2. Rufus
  3. UNetbootin
  4. Any tool from SysInternal Tools

You get the idea.

The application that I will be using is called GifCam and as always, I highly encourage for the reader to download, follow along, and learn the ways of backdooring exe’s. You can find the direct download HERE.

It is a pretty useful app that I use to make all types of gifs which I include for my posts and/or just making them because they give me a good laugh and I am an idiot!

As a side note, you don’t HAVE to use LordPE. You can use others such as Python. Look into pefile if you are interested in creating your own! That might require more work but you can do it 😉

There are a few things that you need to get the task done:

  1. LordPE
  2. Immunity
  3. Your favorite hex editor (I use HxD)
  4. A notepad
  5. Patience?? Naa, it’s not that difficult

Just know that LordPE might get flagged by AV. I can assure you that I did not modify it in any way. Just throwing that warning out there for those that will download this one due to the nature of this post. 


So what we are looking for??

What we are looking for in this app are areas of nothing that are big enough to house not only our shellcode generated by Msfvenom, but also the commands the app have in place that we will be overwriting. These areas are known as code caves. Notice in the figure below how you have just one long continuous area of nullbytes? This would be an ideal code cave.

In my case, I was unable to write to this huge area and didn’t care to find out why. Instead, I had created a new section with 1000 bytes which is more than enough to house everything I need.

The idea here is take over the flow of execution and have it lead directly to an address of your choice. After your code gets ran, it then jumps back to the original state of the program and begins to execute as if nothing had ever happened. Of course there is a bit more to that, but that is essentially what the idea is.

Crafting our Area

After adding an entire new section of 1000 bytes, there is now a total of 11 sections for this app and we are now ready to go!

Now since we have added 1000 bytes, we will need to add bytes to the file. If you try executing this app, it will no longer work and complain about it not being a valid Win32 application due to the change of file size.

Adding bytes to the file is as simple as opening in your favorite hex editor and adding nulls to the end of the file. Once you add the bytes to GifCam, it will now run without error, w00t!


Taking Innocence

This is the time when that notepad is going to come handy. I highly recommend taking notes of not only the addresses you’ll use to jump to, but the first several instructions. Think of noting down the instructions sort of as a snapshot that you can refer back to when changes are made. See what changed or what did not change. More power to you if you don’t have to take notes. Actually, that is incredible if you can.

So as I mentioned earlier, we need to jump to our newly added section. The first jump will take us to the address of our first instruction in our section, which is 0075b000. So I will take note of that too

There are different ways to achieve the same thing, but we will stick to keeping it simple by simply modifying the entry point’s instruction with a jump.

Do you notice anything different? Very interesting. Let’s update our notes accordingly and save the modifications.


Awesome! We have a change in our file with modified instructions.

Let’s step into the jump and see where we be…


As a side note, we have always been told nullbytes err bad, mmkayy? Although that is not wrong, it doesn’t hurt us one bit and we don’t need to encode our payload.

At this point, we can run anything we want! I will be using your standard reverse shell generated with Msfvenom.


As before, we are going to insert those bytes and save the file again.

So here comes the interesting part where two issues arise…

Problems, Why Do You Continue to Bother?

Journal Entry: Issue #1

Tue Dec 27 06:29:07 EST 2016

Shell stalls the execution of the program. Upon further analysis, breakpoint is only hit upon exiting shell. This is rather interesting. Why is that??

WaitForSingleObject is the culprit causing this problem.

To summarize, any value that is passed here that is not a zero…the app will hang until we are finished doing what we are doing. Obviously, that is a problem because the app is only going to start once we exit our shell. So we have to see what is passing the value and I must admit, this took me quite some time (found my answer looking for ways Msfvenom passed values to that function). Also, single stepping takes FOREVER.

Shown below are the commands responsible for passing the value:

By changing DEC ESI and INC ESI to NOPs, this will pass “0” and let not only our shell run, but for the app to run simultaneously as you would expect to happen.

Very nice.


Journal Entry: Issue #2

Tue Dec 27 07:11:07 EST 2016

For some reason, my laziness of preserving the value of the registers into the stack using pushad and pushfd are not working. It seems as if somethings getting corrupted…

Being able to preserve the original values of the registers using pushad is uber convenient as you will see why soon. It takes all the values that all eight registers hold and pushes them onto the stack. Then once your shellcode is done running, you can pop the values back into the registers using popad. Unfortunately for you, Msfvenom has multiple calls to not only pushad, but also a couple calls to popad and popfd. The icing on the cake is when it pops your “saved” values, it executes code in between those calls. Lastly, it issues another pushad and saves the unwanted values and brings them back later. That obviously ruins the values you were trying to save.

Now you might be wondering, “I can search for these commands and change them to NOPs because some of the code is useless. It might work! Simple!”. Well, you CAN do that, but you are going to have useless code which gives you errors. Unfortunately, it actually has a purpose doing something somewhere and will spit out errors at runtime if you modify them. Because of this, we are going to manually set our registers to the original values that we tried to save. Take note of the registers.

Before Execution

 Now take note of the registers after we hit the last instruction of our shellcode.

After Execution

So with simple math, you can easily use either SUB or ADD to get the values you need. Maybe you have a better way of doing so? If so, do recommend! Your main goal is to do anything you can to get your instructions back to it’s original state. If not, your app will not start. Although you will catch your shell, the app will just not work. That can possibly raise some flags 😉

As a side note, now that you have modified your app with shellcode from Msfvenom, your app is now going to get flagged by AV 😉


Notice how I have also inserted the overwritten commands? Once you have done so, you can once again save your changes and hopefully get a working shell with the expected behavior of the app! Nicely done 🙂

Although this was fun to do, I didn’t see any real world uses for this unless you want to be “THAT” douchebag guy…or do you??? hehe 😉

Well you have successfully backdoored an application! W00T!


Leave a Reply

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