Exploit Development: Easy RM RMVB to DVD Burner 1.8.11 (SEH overflow example #1)

SEH (Structured Exception Handler) is a mechanism created by Windows that mitigates the abuse of buffer overflows. This post will cover the development process of one possible exploit of Easy RM RMVB to DVD Burner 1.8.11 that bypass this technique.

Disclaimer: PLEASE! This is for research purposes only and should only be used on authorized systems. Accessing a computer system or network without authorization or explicit permission is illegal.

Easy RM RMVB to DVD Burner 1.8.11:

  • Software running on Windows XP SP3 at
  • Kali attacking machine at
  • Exploit in the “Register your copy” feature.
  • All development process was taken in Windows XP.

Crashing the software:

This is my initial python script used to replicate the crash:

File exploit.txt contains the malicious code to crash the service.

To crash the software we need to:

  • Open it.
  • Press the “Register” button.
  • Ctrl + V the content of exploit.txt in the “Enter User Name” field.
  • Click on “Go”.
Sending 2000 “A”s to crash the software.
Software has crashed!

Taking a look at SEH and nSEH values, it is possible to check that both of them have been filled with “\x41”, the letter A in hex:

SEH Chain has been modified after sending 2000 “A”s.

Controlling nSEH and SEH:

How much “A”s do we need to use until reaching SEH and nSEH? Before using pattern_create.rb + patern_offset.rb from Metasploit Framework to find out, we can try first some Binary Search to avoid creating a big unique string:

Sending 1000 “A”s and 1000 “B”s to avoid generating a very long unique string.

Crashing Easy RM RMVB to DVD Burner again we realize that SEH now has “B”s!

That’s great, let’s generate now a unique 1000 chars length string:

SEH needs at least 1000 “A”s to be reached.

Sending the malicious string to the software and crashing it again:

SEH is overwritten with 41306151.

Using patter_offset.rb with the parameter 41306141 show that the offset corresponds to 0! Wow!

Offset equals 0 reveals that we need exactly 1000 chars to reach SEH.

So, to overflow SEH and nSEH we need the buffer to be something like this:

buffer = junk + nSEH + SEH + junk

As we know that we need 1000 chars to reach SEH, this is how our exploit code should looks like to control it:

BBBB corresponds to nSEH and CCCC corresponds to SEH.
Another crash and know we control both SEH and nSEH.

Finding a return address:

As we have control of SEH, we can insert any address that corresponds to any instruction we want to be executed. A good sequence of instructions we could use here is POP POP RET. These instructions may be found in .dlls used by the software. To check this, we can use mona script inside Immunity Debugger:

POP POP RET found at 0x12037859 of SkinMagic.dll.

Our updated exploit code should now looks like this:

CCCCC is now updated to an address that points to a POP POP RET.

Crashing the server again, we see that we have reached an exception. We now press Shift+F9 and put a breakpoint at 0x10037859:

Shift + F9 pass the exception and redirects the execution to SEH Chain.
And we hit our breakpoint!

Little space to work:

After redirecting our flow with POP POP RET, we came up with little space to work:

As expected, we’re now at nSEH, with only 4 bytes to work.

Although we have only a few bytes, there are some good space up where some of our initial “A”s are. What we could do now is jump up a few bytes back to have some more space to work. One simple Assembly code for so is “\xEB\x??”, where “\xEB” corresponds to the jump and “\x??” to the number of bytes to go back. If we choose 128 bytes to go back, this is how our exploit should looks like:

BBBB (\x43\x43\x43\x43) is now replaced with \x43\x43\xEB\x80 containing our jump.

After crashing the software, we now see that we indeed have jumped a few bytes back, giving us a little more space to work:

More space to work after jump is taken.

Generating Egg Hunter:

Now that we have for about ~128 bytes to use, we can generate a 32 bytes Egg Hunter using mona script with the egg value of “r4f4”:

Ok, so we now that our egg hunter code will be somewhere near our last “A”s. Let’s put some NOPs (\x90) before and after the egg hunter to help us identify it on dump later on:

Crashing the software again and we can see that our egg hunter is there!

Egg hunter is found between NOPs.
Egg hunter will try to find the string “r4f4r4f4”.

The Egg Hunter will now be run and try to find the string “r4f4r4f4” in memory to redirect the execution flow to there. We need now to create a new stage to place our shellcode to be appended right after our egg:

Shellcode with some NOPs just to check it will be found after our egg.
Egg hunter running trying to find “r4f4r4f4”
Egg found and execution flow is redirected to the NOPs.

Generating final shellcode:

Great! Anything we put in shellcode variable will be executed. Let’s use Metastploit to generate one bind shell TCP on port 4444:

msfvenom -a x86 — platform Windows -p windows/shell_bind_tcp LPORT=4444 -f python -e x86/alpha_mixed
Part of the updated exploit.

Getting a shell:

And that’s it! All we need to do now is execute the final exploit code, CTRL +V its content to the software and hope for a new port 4444 opened on the victim’s machine:

Port 4444 opened on the Windows XP machine after executing the exploit code.
And there you go! Connecting to port 4444 gave us a shell on the victim’s system.

Final exploit code can be found here on my Github.