Where It All Begins – An Introduction Protected Mode [Data Protection Series – Part 1]

In the last decade the “Data protection” has found new expressions in the field of software security. The word ‘data‘ is being replaced with ‘information‘. The line between them is blur however there is a distinction in the context they are being used. I notice that system security experts or system developers generally use the term ‘data protection’. Otherwise, mostly the term ‘data’ and ‘information’ are used indistinguishably. In my opinion, information is what we deduce from the data. It has a meaning associated with it in the forms of an answer to a question. Data can be stored or transferred by a software system. In general, a system should ‘not’ allow the data to be read or written without the user’s consent. To enable this, software systems have many inbuilt mechanisms for data protection.

The objective of this post and upcoming many posts in this series of “Data Protection” is to not only provide conceptual understanding but walk through various mechanisms (hardware and software)  with the help of sample source code and disassembly by reverse engineering tools such as WinDbg. It is expected that the reader has some knowledge of C, CPU Registers, and WinDbg or any other related debugging tool. To begin with, we look into the security or protection for executable code and data at the processor level. Later we explore other levels of system security built on top of it. Continue reading “Where It All Begins – An Introduction Protected Mode [Data Protection Series – Part 1]”

Everybody likes automation (!exchain) – Exception Handling (Part 5)

This is the last post related to the internals of structured exception handling (SEH). In this post, we look at the summary of the exception handling and dispatching, a WinDbg extension ‘exchain’ to view the chain of registered exception handlers.  We start by inspecting the disassembly of the exception handling code. We look at how the exception handler frames are created on the stack and unwinded as the programs execute. Next, we use the WinDbg extension to display the exception registration records and understand the nested structure in case of nested __try, __except block. It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.

Revisiting Try-Except

Let’s take a look at the code and compiler-generated disassembled code again to understand how the registration record is created:

Continue reading “Everybody likes automation (!exchain) – Exception Handling (Part 5)”

Back to the Start – Exception Handling (Part 4)

The C programming language does not offer any support to handle exceptions in the program and this is one of the major differences between C and C++. The Structured Exception Handling (SEH) is an extension to Microsoft C++ and C language support. Although, it is recommended to use the in-built exception handling mechanism if you are using C++  because it helps with the portability of the code across platforms. But, Microsoft compiler allows us to use SEH with C++ and C. The SEH provides a way to handle resources (memory buffers, synchronization primitives, etc) in case the program flow is interrupted due to software or hardware exceptions.

The SEH mechanism which was mentioned in the first post is :

  • Exception handler – __except block: called in response to an exception.
  • Termination handler – __finally block: always called.

When the developer defines the SEH block (aka exception frame), it gets installed on the stack and with the unwinding of the stack, it gets removed. The exception can be caught in the same function or the caller function. In terms of unwinding the stack, if the exception is unhandled in the callee, it goes higher up the stack in the previous or caller’s frame and appropriate action is taken. So the above two SEH mechanisms may be different in terms of functionality but as far as unwinding the stack is concerned, they are similar.

In this post, we dig into the flow of the exception in user-mode (supported by OS) and in the developer’s code (exception or termination handler written by the developer). It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.

The Thread Environment

Let’s take a look at the stack once we return to the user-mode after the ‘First Chance’ exception (see previous post).

Continue reading “Back to the Start – Exception Handling (Part 4)”

The Hidden Iceberg – Exception Dispatching (Part 3)

In part 2 of this post series, we left with the question concerning how we reach to the ‘first chance exception’ manifested in the debugger. We further see how exceptions and interrupts have associated handlers in kernel mode, called trap-handlers. The CPU stores the address of interrupt dispatch table (IDT) in IDTR register and every entry in IDT corresponds to an exception or interrupt handler routine also called trap handler. We use Windows 7 x86 system for debugging and note that the trap handler symbol for ‘divide by zero’ exception is ‘KiTrap00’.  The processor transfers control to this routine when a ‘divide by zero’ exception occurs. We can set a breakpoint on this handler and get the stack as shown below.

0: kd> kn # ChildEBP RetAddr 
00 93d0dd98 01236a9e nt!_KiTrap00 >>>>trap handler called on exception 
01 93d0ddc8 00000000 Ex1!SafeDiv+0x3e

In this post, we explicate the flow of exception dispatching from user mode to kernel mode which remains unseen by the developers. It is expected that the reader has some knowledge of C and WinDbg or any other related debugging tool.

Reverse Engineering the trap-handler

The ‘KiDispatchException‘ is the key routine to handle the exception and a breakpoint can be set here: Continue reading “The Hidden Iceberg – Exception Dispatching (Part 3)”

The Trap of Operating System: Exception Handling (Part 2)

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 Developer’s Pandora Box: Exception Handling (Part 1)

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)”

Not everything is executable: NX bit and Data Execution Prevention

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”