Module 4: Hardware Breakpoints & Debug Registers

Using the CPU's own debug facilities to intercept execution — invisibly.

1. Software vs Hardware Breakpoints

There are two fundamentally different ways to set breakpoints on x64. Understanding the distinction is critical because one modifies memory (detectable) and one does not (stealthy).

ComparisonSoftware Breakpoint (INT3):
  BEFORE:  4C 8B D1 B8 18 00 00 00 0F 05 C3    ; clean stub
  AFTER:   CC 8B D1 B8 18 00 00 00 0F 05 C3    ; 0xCC replaces first byte!
           ^^ DETECTABLE - byte changed in memory

Hardware Breakpoint (Dr0):
  MEMORY:  4C 8B D1 B8 18 00 00 00 0F 05 C3    ; unchanged! clean!
  Dr0:     points to address of 0F 05 (syscall)
  Dr7:     bit 0 enabled
  Result:  exception fires when RIP reaches Dr0's address, but ntdll bytes are untouched

2. x64 Debug Registers

The x64 architecture provides 8 debug registers (Dr0–Dr7). LayeredSyscall uses Dr0, Dr1, and Dr7:

Dr7: Debug Control Register Layout

Dr7 is the most complex debug register. It controls which breakpoints are active and what conditions trigger them:

For LayeredSyscall, the relevant operations on Dr7 are:

C++// Enable Dr0 (local enable, bit 0)
Dr7 |= (1 << 0);    // Sets bit 0 = L0 = enable Dr0

// Enable Dr1 (local enable, bit 2)
Dr7 |= (1 << 2);    // Sets bit 2 = L1 = enable Dr1

// Condition bits for Dr0 at bits 16-17: 00 = execution breakpoint
// Condition bits for Dr1 at bits 20-21: 00 = execution breakpoint
// (00 is the default, so no explicit set needed for execution type)

// Disable Dr0
Dr7 &= ~(1 << 0);   // Clears bit 0 = L0 = disable Dr0

3. Setting Hardware Breakpoints via VEH

Normally, modifying debug registers requires the SetThreadContext API, which EDRs monitor. But when you're inside a VEH handler, you have direct access to the CONTEXT structure — including the debug registers. This is how LayeredSyscall sets breakpoints without calling any suspicious APIs.

C++// From LayeredSyscall's AddHwBp handler
LONG WINAPI AddHwBp(PEXCEPTION_POINTERS ExceptionInfo) {
    if (ExceptionInfo->ExceptionRecord->ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
        return EXCEPTION_CONTINUE_SEARCH;

    PCONTEXT ctx = ExceptionInfo->ContextRecord;

    // Set Dr0 = address of 'syscall' (0F 05) in the target Nt* function
    ctx->Dr0 = (DWORD64)pSyscallAddress;

    // Set Dr1 = address of 'ret' (C3) after the syscall instruction
    ctx->Dr1 = (DWORD64)pRetAddress;

    // Enable both breakpoints in Dr7
    ctx->Dr7 |= (1 << 0);  // Enable Dr0 (L0)
    ctx->Dr7 |= (1 << 2);  // Enable Dr1 (L1)

    // Advance RIP past the faulting instruction (null deref)
    ctx->Rip += INSTRUCTION_SIZE;

    // Set up the call to the legitimate API...
    return EXCEPTION_CONTINUE_EXECUTION;
}

C++ (Traditional - Detectable)// This is what EDRs watch for!
CONTEXT ctx;
ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
GetThreadContext(hThread, &ctx);
ctx.Dr0 = targetAddr;
ctx.Dr7 |= 1;
SetThreadContext(hThread, &ctx);  // EDR hooks this!

4. Breakpoint Types

The R/W (condition) bits in Dr7 determine what triggers the breakpoint. There are four types:

LayeredSyscall exclusively uses execution breakpoints (R/W = 00). This is the default value, so the condition bits don't need explicit configuration beyond enabling the local enable flags.

5. How LayeredSyscall Uses Hardware Breakpoints

LayeredSyscall sets two hardware breakpoints per syscall invocation, each serving a distinct purpose:

Finding the Syscall and Ret Addresses

The code scans forward from the beginning of the Nt* function, looking for the 0F 05 (syscall) byte sequence within the first 25 bytes:

C++// From LayeredSyscall - finding syscall instruction offset
BOOL GetSyscallAddresses(PVOID funcBase, PVOID* pSyscall, PVOID* pRet) {
    BYTE* p = (BYTE*)funcBase;

    for (DWORD i = 0; i < 25; i++) {
        // Look for syscall opcode: 0F 05
        if (p[i] == 0x0F && p[i + 1] == 0x05) {
            *pSyscall = (PVOID)&p[i];       // Address of 'syscall'
            *pRet     = (PVOID)&p[i + 2];   // Address of 'ret' (C3)
            return TRUE;
        }
    }
    return FALSE;  // syscall not found within range
}

// These addresses become:
// OPCODE_SYSCALL_OFF   = offset of 0F 05 from function base (typically +8)
// OPCODE_SYSCALL_RET_OFF = offset of C3 from function base (typically +10)

Memory LayoutNtAllocateVirtualMemory:
  +0:  4C 8B D1          mov r10, rcx
  +3:  B8 18 00 00 00    mov eax, 0x18
  +8:  0F 05             syscall          ← Dr0 breakpoint HERE
  +10: C3                ret              ← Dr1 breakpoint HERE

6. The EXCEPTION_SINGLE_STEP Exception

When execution hits an address stored in Dr0–Dr3 (with the corresponding enable bit set in Dr7), the CPU raises an exception with code 0x80000004 (EXCEPTION_SINGLE_STEP). This is the same exception code produced by:

LayeredSyscall's HandlerHwBp differentiates by checking whether the exception address matches Dr0 or Dr1:

C++LONG WINAPI HandlerHwBp(PEXCEPTION_POINTERS ExceptionInfo) {
    if (ExceptionInfo->ExceptionRecord->ExceptionCode != EXCEPTION_SINGLE_STEP)
        return EXCEPTION_CONTINUE_SEARCH;

    PCONTEXT ctx = ExceptionInfo->ContextRecord;
    DWORD64 rip = ctx->Rip;

    if (rip == ctx->Dr0) {
        // Hit the syscall instruction breakpoint
        // Swap SSN and arguments...
    }
    else if (rip == ctx->Dr1) {
        // Hit the ret instruction breakpoint
        // Clean up and restore state...
    }
    else {
        // This is a trap flag single-step (used for call stack building)
        // Handle single-step logic...
    }

    return EXCEPTION_CONTINUE_EXECUTION;
}

7. Advantages for Evasion

Summary: The Complete Interception Chain

Combining what we learned in Modules 2–4, here is how the pieces fit together: