Windows Exploit Development: A simple buffer overflow example

In this post, we are going to write an exploit for a real application on Windows 7 without mitigations (DEP and ASLR). We will be targeting VUPLayer 2.49 which is vulnerable to buffer overflow when loading playlists. Here is how our test subject looks like:

Image for post
Image for post
nice retro GUI ;)

1st round

In order to hit the buffer overflow, we craft a long list containing only ‘A’s and ‘B’s using this simple nodejs script:

Let’s attach a debugger, load the sample playlist and analyze the crash.

Image for post
Image for post

We are effectively making the application crash and overriding EIP with 0x41414141 (‘AAAA’). We are sure we hit a buffer overflow and now we need to measure the buffer’s length in order to override EIP with whatever value we want. We should try overriding ESP and EIP with known values.

2nd round

We can try using smaller chunks of bytes to improve our precision. Using chunks of 500 bytes long we get ESP pointing to 0x0012EEAC which is filled with 43’s (C’s).

Image for post
Image for post

Here we can see ESP points to 0x0012EEAC and the 43’s (C’s) start 4 addressed before ESP.

So, we have to provide 500 ‘A’s, 500 ‘B’s and 16 ‘C’s in order to reach ESP.

3rd round

We change the block size to 1016 bytes to match our calculations and we successfully hit esp as expected.

Image for post
Image for post

We placed 1016 ‘A’s, then 1016 ‘B’s starting at ESP, then 1016 ‘C’s.

Now we need to know how big the stack is. We can use a De Bruijn pattern to measure this using radare2’s ragg2 utility

4th Round

Our new exploit.js includes a De Bruijn sequence and looks like this:

Let’s try it out!

Image for post
Image for post
great! EIP = 0x44444444 == ‘DDDD’
Image for post
Image for post

Our ‘A’s chunk starts at 0x12EAb4 and EIP is at 0x12EEA8. Using radare2 we can calculate the difference between the addresses. A third way of knowing the stack length would be providing a Bruijn pattern directly and then getting the offset of EIP’s value after the crash.

After loading this sample.m3u EIP’s value is 0x41684641 which is at offset 1012 as we would expect:

Image for post
Image for post

Then, we could calculate where the start of the stack was by subtracting this value to EIP’s content address, which is 0x12EAB4 (again, as expected)

Image for post
Image for post

In this environment, we can’t place an address from the stack straight into EIP because stack addresses start with 0x00 which is a null character that will prevent the rest of the file to be loaded. We need to jump into the portion of the stack containing our payload using an indirect method. We’ll find an address containing the “jmp esp” instruction and override EIP with it.

Finding the address is easy with Immunity debugger :

Image for post
Image for post

Here’s the new payload with the gadget:

With the new payload, EIP is overridden with the address of the gadget (0x1010539f) and we placed a placeholder (‘DDDD’) right after. Now we need to provide code to run in place of the placeholder.

5th Round

We can use msfvenom from Metasploit to create a common payload used in PoC exploits. It’ll pop up a calculator. Here’s the command:

Make sure to ban bad characters (-b option) in order to get the entire exploit loaded into the stack. Remember that certain characters like null-bytes can terminate our input prematurely.

After having added the shellcode from Metasploit our exploit looks like this:

If you take a look at the list crafted by the exploit at byte-level you’ll see something like this:

Finally, the time has come for our exploit to pwn!

Image for post
Image for post

InfoSec Write-ups

A collection of write-ups from the best hackers in the…

Sign up for Infosec Writeups

By InfoSec Write-ups

Newsletter from Infosec Writeups Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Syscall59 — Alan Vivona

Written by

Golang, Python, Javascript, Linux & Infosec. https://twitter.com/syscall59

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Syscall59 — Alan Vivona

Written by

Golang, Python, Javascript, Linux & Infosec. https://twitter.com/syscall59

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store