[ExpDev] Winamp 5.12 Exploitation using Egghunter


Hello! This is my second blog posting series about the exploit development. Today’s topic is “Winamp 5.12 Playlist UNC Path Computer Name Overflow” that was discovered by ATmaCA in 2007. To exploit this, I will be leveraging a cool black magic called the Egghunter to escape from the restricted byte space. This vulnerability will not give us enough space to add our own code at the initial entry point. Therefore, we will be using multiple staged payloads to accomplish our goal = reverse shell. We will place our first stage payload to redirect our flow to a little bigger space, and then, we will place the second stage payload (which will be the Egghunter) to again redirect our flow to much bigger space where we will have plenty of space to put our reverse shell code. Let’s get it!


Winamp 5.12

First Staged Payload (JMP ESP)

The following is our template for the Proof-of-Concept (PoC) exploit. This will simply create a malicious playlist file, and when it is added to the playlist, it will execute our selected code. Where the $jmp is the one we will use for our first stage payload.

PoC Exploit Template

First, create a playlist file with the PoC exploit template as-is using the Perl Command in Windows XP. We want to make sure if our script will overwrite EIP with 4 \x41 as intended:

Creating “exploit.pls”

[Steps] Attach Winamp to OllyDbg → “File” → “Play File…” → Select “exploit.pls”

As the program gets crashed, we can see that EIP is overflowed with our intended bytes: \x41\x41\x41\x41

EIP Successfully Overwritten

Winamp comes with various DLL files, and we will pick “in_mp3.dll” and use its CALL ESP (0x0202D961) as our return address for the initial entry point.

CALL ESP = 0x0202D961

Now, we need to update our Proof-of-Concept (PoC) script:

Update $jmp with CALL ESP

When we run our updated script, we can see that EIP is now overwritten as CALL ESP 0x0202D961 address. When we follow in dump of the ESP address, we only have very limited space (11 bytes) that we can control:

Follow in Dump of ESP

But when we go up a bit, there are larger empty spaces:

Empty Space Above the Current ESP Address

What we need to do is we need to use the 11 bytes as the first staged payload ( SUB ESP, 58; SUB ESP, 58; JMP ESP) to jump into the bigger empty spaces. Let’s make theses changes in our current debugging process before we actually update our PoC script. When we run it, we can see that our ESP is now redirected to our intended empty spaces:

First Staged Payload

Perfect! Now update our Proof-of-Concept (PoC) script accordingly:

Update First Staged Payload

Second Staged Payload (Egghunter)

So, now we successfully gained additional 126 bytes that we can control. But it is still not enough to put our reverse shell yet. We need to jump into another bigger space. To do this, we will use a neat assembly code called Egghunter.

Simply put, an Egghunter payload will be created with a user specified signature, and then we can place that signature into the location where our execution flow needs to be redirected. The Egghunter payload will attempt to compare memory space byte-by-byte to find our signature, and once it’s found, we will be jumped to that location. It sounds a little ambiguous now, but it will shed light on as we go through it in the following practice. Additionally, if you really want to know how the Egghunter works, read this from Infosec website.

We will be using our signature as “b0ss” which can be converted into the hex of 0x62307373.

Now, we will run the following command to create our 32 byte Egghunter payload:

Egghunter Payload

Update our PoC script once again and debug it:

Update Second Staged Payload

While we are debugging, we get stuck at the 0x0011FBD0 address due to bad characters: 2E (Winamp identified this 2E as a bad character and stripped it into 00)

Bad Character

As you compare our PoC script and the debugger output above, “CD 00” is supposed to be “CD 2E.” Winamp might not like “2E,” and we now need to leverage msfvenom to encode the payload which will then be decoded in memory.

First, create a egg.bin file and copy and paste our Egghunter payload:


Next, we will encode egg.bin using msfvenom and alpha_mixed encoder (*Note: Encoded payload size might vary. Make sure to record the right byte numbers):

Encoded Egghunter Payload

Finally, we need to update our PoC script. Also, this time we will place our signature “b0ssb0ss” at the beginning of our stage 3 exploit space in order to see if our Egghunter can find it correctly:

Updated Second Staged Payload #2

Once we debug it this time, our Egghunter payload is decoded in memory and bad character was successfully bypassed:

Egghunter Payload

Finally, when we kept running through it, we were able to find our egg=signature “b0ssb0ss” in memory:

Egghunter Found!

And when we follow the JMP EDI, we can see over 800+ empty bytes where we can put our reverse shell :)

Empty Land of Fun

Third Staged Payload (Reverse Shell)

We’re very close to the end. This part is pretty simple. We can create a reverse shell using msfvenom, and place it into our PoC script.

Msfvenom Reverse Shell
Update Third Staged Payload — Part 1
Update Third Staged Payload — Part 2

Now, let’s run our finalized exploit to see if we get a reverse shell:

Final Exploit…
Reverse Shell Gained!


We successfully exploited the “Winamp 5.12 Playlist UNC Path Computer Name Overflow” leveraging Egghunter technique. This exercise was really handy for me to understand how to redirect my execution flow when I don’t have enough spaces to play with. I also wish you learn something from this as well. I also uploaded my final exploit code here. Enjoy it and thanks for reading!

OSCE | OSCP | CREST | Offensive Security Consultant — All about Penetration Test | Red Team | Cloud Security | Web Application Security

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