Vuln Dev
overwriting SEH and debugging Dec 20 2007 04:05PM
opexoc gmail com (1 replies)
Re: overwriting SEH and debugging Dec 20 2007 05:36PM
H D Moore (sflist digitaloffense net) (1 replies)
This occurs because of a feature known as "SafeSEH". This is a new
compiler flag that creates a list of registered SEH handlers within each
executable and DLL. If your target executable was compiled with /SafeSEH
and you try to return into a module that has been also been compiled with
this feature, but the address you chose is not in the list of registered
handlers, then the exception handling code will not transfer execution.

There are a few options to work around this:

1. On Windows 2003, prior to SP1, SafeSEH was essentially broken and you
can return to DLLs such as "ATL.dll" and a few others without the
registered list being checked.

2. Find a module loaded into memory that was not compiled with this flag.
In the case of non-Microsoft applications, use a return address in a DLL
shipped with the product. There is an OllyDbg plugin that lets you check
all loaded modules for a registered SEH list. I am a lazy bastard and
just use msfpescan:

# Windows XP SP0
$ msfpescan -i ws2help.dll | grep SEHandler
<no results>

# Windows XP SP2
$ msfpescan -i ws2_32.dll | grep SEHandler
SEHandlerTable 0x71abbcc0
SEHandlerCount 0x00000001

3. Find another opcode, in-memory, that is not part of a module, but is
still marked executable. A known location on the heap or a loaded
codepage might do the trick. Using a debugger, or tools like memdump.exe
+ msfpescan can simplify this.

More information:


On Thursday 20 December 2007, opexoc (at) gmail (dot) com [email concealed] wrote:
> I am in situation that I have successfully overwrite SEH in some app. I
> know that because when I am debugging this app I get exception ( access
> violation ) and then I can thanks to go to fs:[0] find out what is in
> first SEH structure.
> I have overwritten this SEH by ordinary \xeb\x30\x90\x90 and address of
> POP edi/POP esi/RET 8 instruction in shell32 module. I am wondering why
> when I press SHIFT+F9 in ollydbg I get "Debugged program was unable to
> process exception". But when I overwrite address of handler in SEH by
> for example: \x41\x42\x43\x44 then when I press SHIFT+F9 I get that
> 0x44434241 cannot be accessed - so next exception - as it should be.
> Where is a problem?

[ reply ]
Re: overwriting SEH and debugging Dec 22 2007 07:19PM
Dude VanWinkle (dudevanwinkle gmail com) (1 replies)
Re: overwriting SEH and debugging Dec 22 2007 07:35PM
H D Moore (sflist digitaloffense net)


Privacy Statement
Copyright 2010, SecurityFocus