A few weeks ago, one of my followers asked me if I can help him writing a functional exploit for the current version of the Audio Media Player by ABBS because he’s experiencing problems with successfully exploiting a NULL-byte issue. All exploits that are available over at the Exploit Database like this one or even this Metasploit module are either only working on specific versions of Windows or are not working with the current version of the application.

The goal is to write an exploit which is usable in a reliable way among all Windows versions (I tend to call those exploits WinALL in further articles 🙂 ). The application itself is neither very amazing nor actual, but the behaviour is quite interesting when exploiting the vulnerability which was initially discovered by Rh0!

Let’s have a look.

1. Reproduce the crash

If you open the created .lst file with the application, it crashes and looks like a typical SEH overflow issue:


2. Finding the exact position of the EIP control

(I skip the detailed steps here – mentioned too many times 😉 )

EIP control after 4116 bytes of junk data:


If you have a look at the content of ESP+8 in the dump view, you recognize the typcial nseh-structure of a SEH-based overflow issue. So far so good.

3. Overwrite SEH address with pop/pop/ret

Taking an address directly from the amp.exe to bring reliability into game. Now things are getting interesting. Executing the exploit so far results in something unexpected:


Using the  p/p/r instruction (0x004127BB) at the EIP breaks somehow the flow of the exploit. The expected junk2 – data after the nseh/seh handler containing \xCCs are lost and the EIP is set to CCCCCC at ESP-4. Since we’re using a POP EBX, POP EBP, we would expect this registers to contain the pop’ed values (7C9132A8 & 0012F688) but they contain completely different values (EBX = CCCCCC and EBP=0012F9B8). What happened here ?

The following modified exploit source shows a bit better what happens:

This results in:


The nseh is overwritten correctly, but EIP still contains the CC’s from ESP-4.

4. WTF happens here ?

Well quite easy. The SE handler contains an address with a NULL byte, which breaks the further exploit and “resets” the EIP to the next lower position (ESP-4) before the nseh.

Thanks Rh0 for the hint. The reason why the EIP is reset to ESP-4: The application executes the commands (starting at 0x0042652B)

and finally RETs (@0x00426534) into the overwritten part of the stack.


This is not bad at all, since you are able to execute code at this position without any problems, even if it contains NULL bytes. Looks like the NULL byte is only a problem at the SE handler position.

This needs some small modifications to the exploit code:

Since the nseh cannot be used, you can replace it with some junk data:

At the new position of the EIP you can use a combination of

to jump to the code at ESP+20, which points to the beginning of our input 🙂

Executing the script results in the EIP being moved to our CCs which means control over the application flow:


5. Finalize the exploit

Now the CC’s can be easily replaced with any kind of shellcode (nice: 4108 bytes of space for the shellcode).

The first address of the EIP cannot be used due to the NULL condition, you can simply replace this with some NULLs – called “breaker” in my script.

Now any available shellcode can be used, like a reverse meterpreter shell – the rest of the available space for the shellcode is filled by NOPs – my preferred way of filling uneccessary spaces 😀

You’re able to use an address from the amp.exe itself at the new EIP position, and this makes the exploit reliable among all known Windows versions – even Windows 8:


The crashing application results in a thrilling meterpreter shell:


The public exploit can be found over at Exploit-DB.

ABBS Audio Media Player v3.1 WinALL Exploit
Tagged on:             

6 thoughts on “ABBS Audio Media Player v3.1 WinALL Exploit

  • May 8, 2013 at 12:09 pm

    First of all: Very professional behaviour!

    Second: Show me one line I’ve stolen! I did not copy&paste anything from your exploit code – the lines containing general messages like “Error while creating file!” do not count, because every 2nd exploit uses them.

    Third: This detailed walkthrough shows clearly that I’ve created my own way of exploiting the issue in a reliable way and for the current version.

    The only thing I have to admit here is: I did not reference you (who initially discovered the vulnerability – without an advisory) by name, only indirectly by adding the link to your exploit. If that’s not enough…I’ve edited the introductory text…I do not want to steal anyones kudos here.


  • May 8, 2013 at 3:15 pm

    Hello J.,

    I sent you an email to info()inshell.net with an apology some minutes after i wrote the above stupid non-professional comment, because I overreacted and realized that this was just absolutely inappropriate. In the past I experienced some plagiarism, that’s why I overreacted. I apologize for that comment.


  • May 10, 2013 at 7:48 pm

    youSUCK is frustrated that he doesn’t understand how it works exploit 🙂

    youSUCK this is version ABBS 3.1 not older versions

    • May 12, 2013 at 8:54 pm

      Hi guys,

      I think “youSUCK”s frustration has other reasons. He reacted like Hulk while actually he’s more like Bruce Banner 😉
      Regarding the exploitation of ABBS: The vulnerability exploited here is the same in version 3.0 and 3.1.
      The reason while http://www.exploit-db.com/exploits/16971/ does not work is that the addresses used for the return (“ret =”) and WinExec inside windows changed.
      Addresses in windows DLLs frequently change when e.g. windows internals are updated by MS. The addresses can be also different among different windows versions.
      If you change the shellcode such that eax will contain the address of WinExec@kernel32.dll during execution of “call eax”,
      and change the return address (“ret =”) to an address which points to a “jmp esp” instruction, then it works again. Do you agree ?
      (see quick and dirty change: http://pastebin.com/b6SCkmCr)

      At point 4 in the post you write that a NULL is a problem only at the address of a SE handler and that the NULL “resets” EIP to ESP-4.
      Is that correct ? I think it’s more like this:

      1) A NULL is used as a buffer/string terminator and is problematic anywhere in the buffer.
      If you use “\xCC\xCC\xCC\xCC” + pack(‘<L',0x00412c91) then you get "\xCC\xCC\xCC\xCC\x91\x2c\x41\x00", because of little endianess. The \x00 terminates the string.
      Anything after the NULL is not used regardless where the NULL is included. You can verify that by removing "junk2" and "evil" from your final exploit as it will still work.
      You can even replace pack('<L',0x00412c91) with pack('<L',0x0a412c91) because \x0a terminates the buffer as well and will be replaced by a NULL.

      2) When the program tries to return from the function where the buffer overflow happened, it uses the return address to continue execution at this address.
      Thats why the instruction pointer is filled with the return address (0xCCCCCC) and it has nothing to do with the NULL. Do you agree ?

      Also in point 1 you gain control of the instruction pointer via overwriting the SE Handler and in point 4 via overwriting the return address, right ?

      Best regards

      • May 14, 2013 at 10:24 pm

        You’re right – thanks for the hint :-)! I had a quick look at the application flow again, and noticed that the application directly returns into the overwritten part of the stack (without SEH interaction) and at this position we’re able to use an address containing a NULL byte (0x00412c91). I’ve edited my post.

        The WinExec address problem:
        You’re right, but you can also take an address from amp.exe to achieve reliability – so why taking it from a system library ?



Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.