2) After I open the created file “exploit_seh.wav” with “A-pdf all to mp3 converter”, the software silently crashes without any error message. (This is probably because we overwrote the seh handler, which was suppose to handle exception.)

3) To check what happened, this time i open the debugger “immunity debugger “ and attach the debugger to the process “Alltomp3” as shown below:

4) Afer attaching the debugger to the process, now run the program and then open the created file “exploit_seh.wav” with “PDf all to mp3 converter”, this time you find that the program crashes and eip is overwritten with 41414141 (AAAA) as shown in the below figure.

5) Since we have control over eip, we can write a classic stack based buffer overflow exploit but since we want to write a reliable exploit, let us see if we can write a seh based exploit. After looking into the seh chain i find that our seh handler is also overwritten with 41414141 (AAAA) as shown below. This means we now have control over seh handler.

After following the seh chain in the stack, we find that pointer to the next seh record and address of the seh handler is also overwritten with 41414141 (AAAA). As shown below (see the lower right corner)…so now we have control over pointer to the next seh record and also the seh handler.

1) Now to write an seh based exploit, we have to know where exactly our seh handler is located. To find the exact offset, let us create a pattern of 5000 characters using metasploit and replace the 5000 A’s in our perl script with this pattern as shown below:

2) After running the script “exploit_seh.wav” file is created, now attach the debugger to the process and after opening the exploit_seh.wav file with “PDF All to mp3 converter” we find that seh handler contains the pattern 39684638, because of the little endian format you will have to read it as 38 46 68 39 which stands for 8Fh9

3) Now let us give this value to the pattern_offset.rb (ruby script in metasploit), after giving this value to the metasploit i found that the offset to the seh handler is 4136, which means the offset of the pointer to the next seh record is 4136-4 = 4132

4) Now let us modify our script to contain 4132 A’s followed by break (“\xcc\xcc\xcc\xcc”) instruction then seh handler would contain address of pop pop ret instruction and then a pattern (this will be replaced with our shellcode).

If everything works well the application should run and when the exception occurs, the control is passed to the seh handler (which executes POP POP RET instruction, which removes first 8 bytes from the stack and puts the next 4 bytes into EIP, which is the address of the pointer to the next seh record ) because of this the instruction at the pointer to the next seh record is executed (which is the break instruction), so if the exploit succeeds the application should pause at break instruction (“\xcc\xcc\xcc\xcc”)
Finding the address of POP POP RET

5) Before we modify the script, Lets us find the address of pop pop ret in the application dll and also we should make sure that the dll doesn’t use the safeseh protection (i.e compiled with safeseh)…to find the application dll’s that are not safeseh compiled, we can use a immunity debugger plugin called pvefindaddr, this plugin will display the dll’s which are not safeseh complied (displayed in red) and then we can use the address of POP POP RET instruction from the non safeseh compiled Dll or EXE. The below figure shows pvefindaddr plugin showing the non safeseh dll’s and EXE’s in red.

6) From the above figure we see that there are 4 application dll’s and EXE’s which are not compiled with safeseh protection (shown in red in the above figure)....i have chosen the application EXE “Alltomp3.exe” to find the address of POP POP RET.

7) To find the address of POP POP RET from the EXE, we can use another ruby script in metasploit (msfpescan) as shown below.

8) I will use the last address 0x005d6a91 (address of pop pop ret instruction)….now the modified script is shown below, now if the exploit works the application should pause at the break instruction (\xcc\xcc\xcc\xcc). If this works then we will replace the shellcode with real shellcode.

9) Now I open the Alltomp3.exe using immunity debugger and run it and then open the file “exploit_seh.wav” created from the above script, now the exception occurs as shown in the figure below (left bottom corner)

After pressing shift+F9, the exception is passed to exception handler you will see that the application breaks at \XCC as expected…and also in the memory dump (lower left pane) you will see our shellcode (which is at plus 6 bytes)….it looks like everything is working fine.

10) Now since our shellcode is at plus 6 bytes, instead of break instruction (\xcc\xcc\xcc\xcc) we will use jmp + 6 bytes, so when the application runs it will jump to our shellcode and execute it, the opcode for jmp + 6 bytes is (\xeb\x06\x90\x90) and we will also replace our shellcode with real shellcode (shellcode to pop a calculator)….The modified script looks like this.
If everthing works well, it should pop a calculator

Comments

Make the tutorials little independent of the tools and rather prefer the technique.
E.g somewhere you have mentioned that use metasploit blah-blah script to find "POP POP RET". Well, once u had debugger open, you can just hit the ctrl+S or ctrl+F buttons to search for patterns, moreover, such tasks should be done manually when someone is learning the stuff for first time, otherwise there is no need to learn anything when everything can be made by tools.
Think, you guys will improve the tutorials in this way.

Note: Remember tools are not readily available to everyone. E.g. in my dormant days i had scanty of resources and even no internet, no one new metasploit by several 100 KM around my place so was difficult to learn from such tutorials.
Always take worst case scenario when you write a tutorial, Otherwise it seems like you are just targetting a special class of resourceful people and others below that class no one is intended to review ur stuff.