{"id":2114,"date":"2009-07-19T08:55:19","date_gmt":"2009-07-19T06:55:19","guid":{"rendered":"http:\/\/www.corelan.be:8800\/index.php\/2009\/07\/19\/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-1\/"},"modified":"2026-04-01T13:37:55","modified_gmt":"2026-04-01T11:37:55","slug":"exploit-writing-tutorial-part-1-stack-based-overflows","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2009\/07\/19\/exploit-writing-tutorial-part-1-stack-based-overflows\/","title":{"rendered":"Exploit writing tutorial part 1 : Stack Based Overflows"},"content":{"rendered":"

Last friday (july 17th 2009), somebody (nick)named \u2018Crazy_Hacker\u2019 has reported a vulnerability in Easy RM to MP3 Conversion Utility<\/a> (on XP SP2 En), via packetstormsecurity.org. (see http:\/\/packetstormsecurity.org\/0907-exploits\/<\/a>). The vulnerability report included a proof of concept exploit (which, by the way,\u00a0 failed to work on my MS Virtual PC based XP SP3 En).<\/p>\n

Another exploit<\/a> was released just a little bit later. Nice work.<\/p>\n

You can copy the PoC exploit code, run it, see that it doesn\u2019t work (or if you are lucky, conclude that it works), or\u2026 you can try to understand the process of building the exploit so you can correct broken exploits, or just build your own exploits from scratch.<\/p>\n

(By the way : unless you can disassemble, read and comprehend shellcode real fast, I would never advise you to just take an exploit (especially if it\u2019s a precompiled executable) and run it.\u00a0 What if it\u2019s just built to open a backdoor on your own computer ?<\/p>\n

The question is : How do exploit writers build their exploits ? What does the process of going from detecting a possible issue to building an actual working exploit look like ? How can you use vulnerability information to build your own exploit ?<\/p>\n

Ever since I\u2019ve started this blog, writing a basic tutorial about writing buffer overflows has been on my \u201cto do\u201d list\u2026 but I never really took the time to do so (or simply forgot about it).<\/p>\n

When I saw the vulnerability report today, and had a look at the exploit, I figured this vulnerability report could acts as a perfect example to explain the basics about writing exploits\u2026 It\u2019s clean, simple and allows me to demonstrate some of the techniques that are used to write working and stable stack based buffer overflows.<\/p>\n

So perhaps this is a good time\u2026\u00a0 Despite the fact that the aforementioned vulnerability report already includes an exploit (working or not), I\u2019ll still use the vulnerability in \u201cEasy RM to MP3 conversion utility\u201d as an example and we\u2019ll go through the steps of building a working exploit, without copying anything from the original exploit. We\u2019ll just build it from scratch (and make it work on XP SP3 this time \ud83d\ude42 )<\/p>\n

Before we continue, let me get one thing straight.
This document is purely intended for educational purposes. I do not want anyone to use this information (or any information on this blog) to actually hack into computers or do other illegal things. So I cannot be held responsible for the acts of other people who took parts of this document and used it for illegal purposes.<\/p>\n

Anyways, that having said, the kind of information that you get from vulnerability reports usually contains information on the basics of the vulnerability.
In this case, the vulnerability report states \u201cEasy RM to MP3 Converter version 2.7.3.700 universal buffer overflow exploit that creates a malicious .m3u file\u201d. In other words, you can create a malicious .m3u file, feed it into the utility and trigger the exploit.
These reports may not be very specific every time, but in most cases you can get an idea of how you can simulate a crash or make the application behave weird. If not, then the security researcher probably wanted to disclose his\/her findings first to the vendor, give them the opportunity to fix things\u2026 or just wants to keep the intel for him\/herself\u2026<\/p>\n

Verify the bug<\/h3>\n

First of all, let\u2019s verify that the application does indeed crash when opening a malformed m3u file. (or find yourself an application that crashes when you feed specifically crafted data to it).
Get yourself a copy of the vulnerable version of Easy RM to MP3 and install it on a computer running Windows XP. The vulnerability report states that the exploit works on XP SP2 (English), but I\u2019ll use XP SP3 (English).
You can find a copy of the vulnerable application on exploit-db<\/a><\/p>\n

\"image\"<\/a><\/p>\n

Quick sidenote : you can find older versions of applications at <\/em>oldapps.com<\/em><\/a> and <\/em>oldversion.com<\/em><\/a>, or by looking at exploits on exploit-db.com (which often have a local copy of the vulnerable application as well)<\/p>\n

We\u2019ll use the following simple perl script to create a .m3u file that may help us to discover more information about the vulnerability :<\/p>\n

my $file= \"crash.m3u\"<\/span>; \nmy $junk= \"\\x41\"<\/span> x 10000; \nopen($FILE,\">$file\"<\/span>); \nprint $FILE \"$junk\"<\/span>; \nclose($FILE); \nprint \"m3u File Created successfully\\n\"<\/span>;<\/pre>\n
Run the perl script to create the m3u file. The fill will be filled with 10000 A\u2019s (\\x41 is the hexadecimal representation of A) and open this m3u file with Easy RM to MP3\u2026.<\/p>\n
The application throws an error, but it looks like the error is handled correctly and the application does not crash.\u00a0 Modify the script to write a file with 20000 A\u2019s and try again.\u00a0\u00a0 Same behaviour. (exception is handled correctly, so we still could not overwrite anything usefull).<\/p>\n
Now change the script to write 30000 A\u2019s, create the m3u file and open it in the utility.<\/p>\n
Boom - application dies.<\/p>\n
Ok, so the application crashes if we feed it a file that contains between 20000 and 30000 A\u2019s. But what can we do with this ?<\/p>\n
Before we proceed - some theory<\/h3>\n
Just a few terms that you will need : Every Windows application uses parts of memory.\u00a0 The process memory contains 3 major components :<\/p>\n
Verify the bug - and see if it could be interesting<\/h3>\n
Obviously, not every application crash can lead to an exploitation. In many cases, an application crash will not lead to exploitation\u2026 But sometimes it does.\u00a0\u00a0 With \u201cexploitation\u201d, I mean that you want the application to do something it was not intended to do\u2026 such as running your own code.\u00a0 The easiest way to make an application do something different is by controlling its application flow (and redirect it to somewhere else).<\/p>\n
This can be done by controlling the Instruction Pointer<\/a> (or Program Counter), which is a CPU register that contains a pointer to where the next instruction that needs to be executed is located. Suppose an application calls a function with a parameter. Before going to the function, it saves the current location in the instruction pointer (so it knows where to return when the function completes).<\/p>\n
If you can modify the value in the instruction pointer, and point it to a location in memory that contains your own piece of code, then you can change the application flow and make it execute something different (other than returning back to the original place).<\/p>\n
The code that you want to be executed after controlling the flow is often referred to as \u201cshellcode\u201d. So if we make the application run our shellcode, we can call it a working exploit.<\/p>\n
In most cases, this pointer is referenced by the term EIP. This register size is 4 bytes. So if you can modify those 4 bytes, you own the application (and the computer the application runs on)<\/p>\n