{"id":2153,"date":"2009-07-25T00:27:34","date_gmt":"2009-07-24T22:27:34","guid":{"rendered":"http:\/\/www.corelan.be:8800\/index.php\/2009\/07\/25\/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh\/"},"modified":"2009-07-25T00:27:34","modified_gmt":"2009-07-24T22:27:34","slug":"writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2009\/07\/25\/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh\/","title":{"rendered":"Exploit writing tutorial part 3 : SEH Based Exploits"},"content":{"rendered":"

In the first 2 parts of the exploit writing tutorial series, I have discussed how a classic stack buffer overflow works and how you can build a reliable exploit by using various techniques to jump to the shellcode.  The example we have used allowed us to directly overwrite EIP and we had a pretty large buffer space to host our shellcode. On top of that, we had the ability to use multiple jump techniques to reach our goal. But not all overflows are that easy.<\/p>\n

Today, we\u2019ll look at another technique to go from vulnerability to exploit, by using exception handlers.<\/p>\n

What are exception handlers ?<\/h3>\n

An exception handler is a piece of code that is written inside an application, with the purpose of dealing with the fact that the application throws an execption.  A typical exception handler looks like this :<\/p>\n

try<\/span>\n{\n  \/\/run stuff.  If an exception occurs, go to <catch> code<\/span>\n}\ncatch<\/span>\n{\n  \/\/ run stuff when exception occurs<\/span>\n}<\/pre>\n
\n
<\/div>\n<\/div>\n
A quick look on the stack on how the try & catch blocks are related to each other and placed on the stack  :<\/p>\n
\"image\"<\/a><\/p>\n
(Note : "Address of exception handler" is just one part of a SEH record - the image above is an abstract representation, merely showing the various components)<\/em><\/p>\n
Windows has a default SEH (Structured Exception Handler) which will catch exceptions. If Windows catches an exception, you\u2019ll see a \u201cxxx has encountered a problem and needs to close\u201d popup. This is often the result of the default handler kicking in.  It is obvious that, in order to write stable software, one should try to use development language specific exception handlers, and only rely on the windows default SEH as a last resort.   When using language EH\u2019s, the necessary links and calls to the exception handling code are generate in accordance with the underlying OS.  (and when no exception handlers are used, or when the available exception handlers cannot process the exception, the Windows SEH will be used. (UnhandledExceptionFilter)).  So in the event an error or illegal instruction occurs, the application will get a chance to catch the exception and do something with it. If no exception handler is defined in the application, the OS takes over, catches the exception, shows the popup (asking you to Send Error Report to MS).<\/p>\n
In order for the application to be able to go to the catch code, the pointer to the exception handler code is saved on the stack (for each code block). Each code block has its own stack frame, and the pointer to the exception handler is part of this stack frame.  In other words : Each function\/procedure gets a stack frame. If an exception handler is implement in this function\/procedure, the exception handler gets its own stack frame.  Information about the frame-based exception handler is stored in an exception_registration structure on the stack.<\/p>\n
This structure ( also called a SEH record) is 8 bytes and has 2 (4 byte) elements :<\/p>\n