[Research] Analyzing Low-Level C Constructs in Windows

Introduction

In this class, I explored the SEH mechanism in Windows, a fundamental feature for exception control in applications written in C. In addition to the legitimate approach of SEH, I also analyzed how this structure can be exploited in offensive security scenarios—especially in vulnerabilities that allow the redirection of execution flow. This study is part of my development in debugging, reverse engineering, and understanding the internal mechanisms of Windows that can be both protection tools and attack vectors.

Understanding the Internal Structure of the SEH

SEH works like a linked list of records maintained by Windows on the stack. Each time a protected block is created, a new record is placed on top of the chain; when the block ends, it is removed.

Each record contains two main pieces of information:

• a pointer to the next handler
• the address of the function responsible for handling the exception

The first record in the list is always pointed to by the address stored in FS:[0], which acts as the “head” of this chain.

As new handlers are registered, they accumulate on the stack, forming a linked sequence. When an exception occurs, Windows goes through this sequence from top to bottom, calling each handler until one of them manages to handle the error — or until no records are left.

The Node Structure in Memory

Each node in the list follows a simple but extremely important format in binary exploration:

[ pointer_to_next_handler ][ handler_function_address ]

This means that, in memory, the chaining is entirely controlled by pointers on the stack. This feature is precisely what makes SEH a classic target in exploits: if an attacker manages to overwrite these fields, they can redirect the execution flow to any address of their choice.

The Role of FS:[0] and the TIB (Thread Information Block)

To understand precisely how the SEH chain works, it is necessary to observe how Windows stores the pointer to the first record in the list.

Each thread has a structure called the TIB (Thread Information Block). Within this structure, in 32-bit processes, the FS:[0] register contains the address of the active SEH record.

Therefore:

• FS:[0] → first SEH record on the stack
• This record has a prev field that points to the next record
• The chain continues until the special address 0xFFFFFFFF, which marks the end of the list

This is the chain that Windows goes through during the handling of an exception. Microsoft’s documentation describes this behavior as follows:

“Uses a pointer value stored at FS:[0] to point to the current exception handler frame.”

In other words: FS:[0] always points to the currently active handler.
Each new protected block adds a new record; when exiting the block, it is removed.
Windows simply follows the prev pointers until it finds a handler capable of handling the error.

The Dynamics of Exploration

When we analyze the SEH chain in debuggers like x64dbg or WinDbg, we can clearly see:

• 1. The order of the registered handlers
• 2. The pointers chaining each record
• 3. The final handler — which is usually the default in Windows itself
• 4. The path taken when an exception dispatch occurs

This understanding is essential for more advanced stages of exploration, such as:

• manipulate the Structured Exception Handler
• use techniques like pop pop ret
• exploit buffer overflows that allow replacing the Next SEH and the SE Handler

But before getting to these offensive techniques, it’s important to understand the natural behavior of the structure — exactly what we are doing here.

Moving on to practice

In the next step, we analyze a simple code that deliberately generates an exception (like writing to a null address). This allows us to observe:

• how SEH is organized on the stack
• what is the active register at the time of the fault
• how Windows walks through the handlers
• and why the control flow can be manipulated during this process

This low-level view will be crucial in the next steps, where we will see how classic vulnerabilities exploit this very structure.