Module 4: ROP Gadgets & NtContinue

Redirecting execution by overwriting the thread context — one CONTEXT at a time.

1. What Is Return-Oriented Programming?

Return-Oriented Programming (ROP) is a code-reuse exploitation technique that chains together small sequences of existing code (called "gadgets") that each end with a RET instruction. By controlling the stack, an attacker can make the CPU "return" from one gadget into the next, executing a sequence of operations without injecting any new code.

In classical ROP exploitation, the attacker corrupts the stack so that each RET pops the address of the next gadget from the stack, forming a chain of tiny code snippets that together perform arbitrary operations (like calling VirtualProtect to mark memory as executable, then jumping to shellcode).

Ekko does not use classical stack-based ROP chains. Instead, it uses a more elegant mechanism: NtContinue. Rather than manipulating the stack to chain gadgets via RET instructions, Ekko sets up complete CONTEXT structures for each operation and uses NtContinue to atomically load them into the CPU. This is sometimes called "context-oriented programming" or a "ROP-like" approach because the concept is similar (redirect execution to existing code), but the mechanism is different (CONTEXT replacement instead of stack manipulation).

2. NtContinue — The Context Restorer

NtContinue is an undocumented ntdll function that restores a thread's execution context from a CONTEXT structure. It is normally used internally by Windows for exception handling — after an exception handler runs, NtContinue restores the thread to continue execution from where the exception occurred (or a modified location).

C// NtContinue - restores thread context
// Exported by ntdll.dll
//
// NTSTATUS NtContinue(
//     PCONTEXT ThreadContext,   // Context to restore
//     BOOLEAN  RaiseAlert       // Whether to test for alert delivery
// );

// Ekko resolves it at runtime:
PVOID NtContinue = GetProcAddress(
    GetModuleHandleA("Ntdll"),
    "NtContinue"
);

3. NtContinue as a Timer Callback

Recall from Module 2 that CreateTimerQueueTimer expects a callback with the signature:

CVOID CALLBACK WaitOrTimerCallback(
    PVOID lpParameter,
    BOOLEAN TimerOrWaitFired
);

Ekko exploits a critical alignment between this callback signature and NtContinue's signature:

C// Ekko's pattern: NtContinue as callback, CONTEXT* as parameter
CreateTimerQueueTimer(
    &hNewTimer,
    hTimerQueue,
    NtContinue,      // Callback = NtContinue
    &RopProtRW,      // Parameter = CONTEXT* (loaded into RCX)
    100, 0,
    WT_EXECUTEINTIMERTHREAD );

// When this timer fires:
// 1. Timer system calls: NtContinue(&RopProtRW, TRUE)
// 2. NtContinue reads RopProtRW context
// 3. Sets RIP = VirtualProtect, RCX = ImageBase, etc.
// 4. Execution jumps to VirtualProtect with correct arguments

4. The CONTEXT Structure

The CONTEXT structure is a large Windows structure that holds the complete CPU register state for a thread. On x64, it is defined in winnt.h and contains over 50 fields:

C// Simplified view of CONTEXT (x64) - key fields for Ekko
typedef struct _CONTEXT {
    // Control registers
    DWORD64 Rip;    // Instruction pointer
    DWORD64 Rsp;    // Stack pointer
    DWORD   EFlags; // Processor flags

    // Segment registers
    WORD SegCs, SegDs, SegEs, SegFs, SegGs, SegSs;

    // General-purpose registers
    DWORD64 Rax, Rcx, Rdx, Rbx;
    DWORD64 Rbp, Rsi, Rdi;
    DWORD64 R8, R9, R10, R11, R12, R13, R14, R15;

    // Floating-point / SSE state
    M128A Xmm0, Xmm1, /* ... */ Xmm15;

    // ... additional fields (debug registers, vector registers, etc.)
    DWORD ContextFlags;  // Which parts of the context are valid

} CONTEXT;

The full CONTEXT structure on x64 is 1232 bytes. Ekko allocates six of these on the stack (plus the initial capture context), totaling over 8.5 KB of stack space for the context structures alone.

5. Building a CONTEXT for an API Call

Each CONTEXT in Ekko's chain is constructed by copying the captured baseline context and modifying the registers needed for a specific function call. Here is how Ekko constructs the VirtualProtect(RW) context:

C// Step 1: Copy the baseline context (captured from timer thread)
memcpy( &RopProtRW, &CtxThread, sizeof(CONTEXT) );

// Step 2: Set RIP to the target function
RopProtRW.Rip = (DWORD64)VirtualProtect;

// Step 3: Set arguments per x64 calling convention
RopProtRW.Rcx = (DWORD64)ImageBase;         // arg1: lpAddress
RopProtRW.Rdx = (DWORD64)ImageSize;         // arg2: dwSize
RopProtRW.R8  = PAGE_READWRITE;             // arg3: flNewProtect
RopProtRW.R9  = (DWORD64)&OldProtect;       // arg4: lpflOldProtect

// Step 4: Adjust RSP for stack alignment
RopProtRW.Rsp -= 8;

6. Why Not Call Functions Directly?

A natural question is: why go through all this complexity with CONTEXT structures and NtContinue instead of just calling VirtualProtect and SystemFunction032 directly?

7. NtContinue vs. SetThreadContext

Windows also provides SetThreadContext / NtSetContextThread for modifying a thread's registers. Why does Ekko use NtContinue instead?

NtContinue is the natural choice for timer callbacks because it allows the timer thread to modify its own context. The timer infrastructure calls NtContinue, which replaces the timer thread's registers, and execution seamlessly continues at the target function. No thread suspension or cross-thread manipulation is needed.

8. Security Implications of NtContinue

From a defensive perspective, NtContinue is a powerful primitive because it allows arbitrary code execution without creating new threads or injecting shellcode. The execution happens within the context of an existing, legitimate thread (the timer thread), using code that already exists in loaded system DLLs.

9. Putting It Together: The NtContinue Execution Model

Each timer follows the same pattern: the timer infrastructure calls NtContinue with a CONTEXT pointer, NtContinue replaces all registers, and execution jumps to the target API with the correct arguments already in registers. The target API executes normally and returns — but since the RSP and return address were set up by the context, the return flows back into the timer infrastructure, which then waits for the next timer to fire.