The exception hierarchy of the operating system allows the developers to handle both hardware and software exceptions in a unified way and also improves the modularity of the code being developed. In the previous post we observed how the disassembly of a guarded code (__try, __except) block is different. In this post and explore how the system takes control when the exception happens. It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.
Catching Exception In Debugger
Using WinDbg, load the application symbols during loader break and set a breakpoint on ‘main’ routine Continue reading “The Trap of Operating System: Exception Handling (Part 2)”
The exception handling is one of the common features of the Operating System together with programming language runtime. It is very closely related to software security. The programming language like C/C++ together with OS capability can guard a piece of code against the software exceptions by adding a handling construct or exception handler. It is commonly observed that programmers use the exception handler to start execution at another location however a specific type of exception can be handled with a specific exception handler. This is one of the most widely used mechanisms in the software industry and part of almost all programming languages. This is why it is of utmost importance for security researchers, developers and IT administrators to have in-depth knowledge of this mechanism.
This post introduces the concept and highlights a few important questions on the internal working of the Structured Exception Handling (SEH) for better understanding. This is the first post of an upcoming long series of posts where we will dissect the internals of Exception Handling. Every post in this series will include some reverse-engineering of the sample program and its explanation to understand the internal structure and flow. It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.
Continue reading “The Developer’s Pandora Box: Exception Handling (Part 1)”
The idea of non-executable memory regions was introduced in late 90’s when the special exploitation techniques used buffer overflow vulnerabilities to attack the operating systems. To secure the operating system from such attacks, Microsoft implemented this security measure starting with two of their products: Windows XP SP2 and Server 2003. The implementation is known as ‘Data Execution Prevention‘ or DEP in short. The assumption behind the design was that by making certain regions of the memory as non-executable, we can prevent the break-ins to the system by malicious attackers. Many techniques on how to bypass the DEP has already been explored and available in public. In this article, we take a look at the internals of DEP mechanism which would help the developers, IT admins and reverse engineering community. Readers are expected to know basics of address translation.
DEP Is applied in two parts:
Continue reading “Not everything is executable: NX bit and Data Execution Prevention”