Module 2: Software Breakpoints & INT3

The single-byte opcode that stops the CPU — and the foundation of ShellGhost's per-instruction control.

1. The INT3 Instruction

The x86/x64 architecture defines a special one-byte instruction specifically for debugger breakpoints: INT3, encoded as the single byte 0xCC. When the CPU executes this byte, it immediately raises a breakpoint exception (interrupt vector 3) without executing any further instructions.

x86 ASM; A simple function with a breakpoint inserted
original_code:
    push rbp            ; 0x55
    mov rbp, rsp        ; 0x48 0x89 0xE5
    sub rsp, 0x20       ; 0x48 0x83 0xEC 0x20
    ...

; After debugger sets breakpoint at the 'mov' instruction:
patched_code:
    push rbp            ; 0x55
    int3                ; 0xCC  (replaced first byte of 'mov rbp, rsp')
    db 0x89, 0xE5       ; remaining bytes of original instruction
    sub rsp, 0x20       ; 0x48 0x83 0xEC 0x20
    ...

2. How Debuggers Use INT3

When a debugger (WinDbg, x64dbg, Visual Studio) sets a software breakpoint, it performs a simple three-step operation:

1. Save the original byte at the target address
2. Write 0xCC to that address
3. Wait for the CPU to hit it and raise EXCEPTION_BREAKPOINT

When the breakpoint fires, the debugger:

1. Catches the EXCEPTION_BREAKPOINT exception
2. Restores the original byte to the target address
3. Decrements the instruction pointer (RIP) by 1 (because the CPU advanced past the 0xCC byte)
4. Allows the user to inspect state, then resumes execution from the restored instruction

C// How a debugger sets a software breakpoint (simplified)
BYTE original_byte;
LPVOID breakpoint_addr = (LPVOID)0x00007FF6A0001000;

// Save and patch
ReadProcessMemory(hProcess, breakpoint_addr, &original_byte, 1, NULL);
BYTE int3 = 0xCC;
WriteProcessMemory(hProcess, breakpoint_addr, &int3, 1, NULL);

// ... CPU hits 0xCC, raises EXCEPTION_BREAKPOINT ...
// KiDispatchException already decremented RIP by 1 for us

// In debug event handler: restore original byte, RIP already correct
WriteProcessMemory(hProcess, breakpoint_addr, &original_byte, 1, NULL);
// context.Rip already points at breakpoint_addr (kernel adjusted it)
SetThreadContext(hThread, &context);

3. CPU Exception Flow for INT3

When the CPU encounters 0xCC, a precise sequence of events unfolds at the hardware and OS levels:

4. The EXCEPTION_BREAKPOINT Code

The exception code for an INT3 breakpoint is defined in the Windows headers as:

C// From winnt.h / ntstatus.h
#define EXCEPTION_BREAKPOINT    0x80000003L
#define STATUS_BREAKPOINT       0x80000003L

// The exception record delivered to handlers:
typedef struct _EXCEPTION_RECORD {
    DWORD ExceptionCode;        // 0x80000003 for INT3
    DWORD ExceptionFlags;       // 0 for first-chance
    struct _EXCEPTION_RECORD *ExceptionRecord;
    PVOID ExceptionAddress;     // Address of the 0xCC byte
    DWORD NumberParameters;     // 1 for breakpoint
    ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;

5. INT3 vs Other Exception Mechanisms

ShellGhost specifically uses INT3 because of its unique properties compared to other exception-generating mechanisms:

6. Filling a Region with 0xCC

ShellGhost's preparation step fills the entire shellcode execution region with 0xCC. Here is what that looks like in practice:

C// Allocate writable memory and fill with INT3
SIZE_T shellcode_size = 512;  // size of actual shellcode

LPVOID exec_mem = VirtualAlloc(
    NULL,
    shellcode_size,
    MEM_COMMIT | MEM_RESERVE,
    PAGE_READWRITE       // RW initially, toggled to RX for execution
);

// Fill entire region with 0xCC (INT3 breakpoints)
memset(exec_mem, 0xCC, shellcode_size);

// Memory dump at this point:
// 00007FF6`A0000000  CC CC CC CC CC CC CC CC
// 00007FF6`A0000008  CC CC CC CC CC CC CC CC
// 00007FF6`A0000010  CC CC CC CC CC CC CC CC
// ... (all 0xCC for shellcode_size bytes)

A memory scanner examining this region sees nothing but INT3 opcodes. There is no encrypted data, no entropy anomaly, and no signatured byte sequence. The real shellcode bytes (encrypted with RC4) are stored in a separate data buffer that is never made executable.

7. From Breakpoint to Handler: The ShellGhost Connection

Putting it all together, here is how INT3 connects to ShellGhost's execution model:

1. A new thread starts at the first 0xCC in the execution buffer
2. CPU raises EXCEPTION_BREAKPOINT (0x80000003)
3. Windows dispatches to VEH handlers first (ShellGhost's handler is registered with highest priority)
4. ShellGhost's handler sees ExceptionCode == 0x80000003
5. Handler re-encrypts the previously executed instruction (if any) back to 0xCC
6. Handler uses ContextRecord->Rip (already pointing at the 0xCC, adjusted by the kernel) to identify the current instruction
7. Handler decrypts the full instruction from the encrypted data using SystemFunction032 (RC4)
8. Handler writes the decrypted instruction bytes to the execution buffer
9. Handler toggles the memory page from RW to RX via VirtualProtect
10. Handler returns EXCEPTION_CONTINUE_EXECUTION — the CPU resumes and executes the real instruction, then hits the next 0xCC

The next module covers Vectored Exception Handling in detail — the mechanism that makes step 3 possible.