Module 6: Context Manipulation

Capturing, cloning, and weaponizing the CONTEXT structure for controlled execution.

1. RtlCaptureContext — Capturing Thread State

RtlCaptureContext is an ntdll function that fills a CONTEXT structure with the current thread's register state at the point of the call. It is defined as:

C// RtlCaptureContext - captures current thread state
// Exported by ntdll.dll
//
// VOID RtlCaptureContext(
//     PCONTEXT ContextRecord  // Output: filled with current registers
// );
//
// This function captures:
//   - RIP (pointing to the instruction after the call)
//   - RSP (current stack pointer)
//   - All general-purpose registers
//   - RFLAGS
//   - Segment registers
//   - XMM registers

Ekko uses RtlCaptureContext as the callback for Timer 0, passing &CtxThread as the parameter. Since the timer fires on the timer thread (due to WT_EXECUTEINTIMERTHREAD), the captured context reflects the timer thread's register state — not the main thread's.

2. What RtlCaptureContext Captures

The captured CONTEXT includes these key fields that Ekko depends on:

3. Cloning the Baseline Context

After capturing the baseline, Ekko clones it into all six operational contexts:

Cmemcpy( &RopProtRW, &CtxThread, sizeof(CONTEXT) );
memcpy( &RopMemEnc, &CtxThread, sizeof(CONTEXT) );
memcpy( &RopDelay,  &CtxThread, sizeof(CONTEXT) );
memcpy( &RopMemDec, &CtxThread, sizeof(CONTEXT) );
memcpy( &RopProtRX, &CtxThread, sizeof(CONTEXT) );
memcpy( &RopSetEvt, &CtxThread, sizeof(CONTEXT) );

Each memcpy copies all 1232 bytes of the CONTEXT structure. After cloning, each operational context is an exact copy of the timer thread's state. Ekko then selectively modifies only the registers it needs:

4. RSP Pivoting: The Rsp -= 8 Adjustment

Every operational context includes this adjustment:

CRopProtRW.Rsp -= 8;
RopMemEnc.Rsp -= 8;
RopDelay.Rsp  -= 8;
RopMemDec.Rsp -= 8;
RopProtRX.Rsp -= 8;
RopSetEvt.Rsp -= 8;

This single line is critical and easy to overlook. To understand why it is necessary, we need to understand the x64 stack alignment requirement and the call instruction's behavior:

The x64 ABI Stack Alignment Rule

The Microsoft x64 calling convention requires that at the point of a CALL instruction, RSP must be 16-byte aligned. The CALL instruction itself pushes an 8-byte return address onto the stack, making RSP 16-byte-aligned-minus-8 at function entry. Functions expect this alignment and may use SSE instructions (like MOVAPS) that require 16-byte-aligned operands.

Why Ekko Needs the Adjustment

When NtContinue restores a context, it sets RSP to whatever value is in the CONTEXT structure and sets RIP to the target function. But NtContinue does not execute a CALL instruction — it directly sets the registers. This means no return address is pushed onto the stack.

The captured RSP from RtlCaptureContext reflects the stack state at capture time. By subtracting 8, Ekko simulates the effect of a CALL instruction having pushed a return address. The target function sees RSP at the expected alignment (16-byte-aligned minus 8) and operates correctly:

TextCaptured RSP:     0x00000010AA00F000  (16-byte aligned)
After Rsp -= 8:   0x00000010AA00EFF8  (16-byte aligned - 8)

This matches what a function expects after a CALL instruction.
Without the adjustment, MOVAPS and other aligned SSE instructions
inside VirtualProtect or SystemFunction032 could fault.

5. RIP Control — Directing Execution

Setting RIP in the CONTEXT is the most fundamental operation in Ekko's technique. It determines where execution goes after NtContinue restores the context:

C// Each context's RIP points to a different Windows API:
RopProtRW.Rip = (DWORD64)VirtualProtect;      // kernel32.dll
RopMemEnc.Rip = (DWORD64)SysFunc032;          // advapi32.dll
RopDelay.Rip  = (DWORD64)WaitForSingleObject; // kernel32.dll
RopMemDec.Rip = (DWORD64)SysFunc032;          // advapi32.dll
RopProtRX.Rip = (DWORD64)VirtualProtect;      // kernel32.dll
RopSetEvt.Rip = (DWORD64)SetEvent;            // kernel32.dll

All target functions reside in system DLLs that are mapped at fixed addresses (with ASLR per-boot). Since these DLLs are not part of the implant's image, they remain functional even after the image is encrypted and marked non-executable. This is the key insight that makes the entire technique work.

6. Argument Setup via Registers

The x64 calling convention passes the first four integer/pointer arguments in RCX, RDX, R8, and R9. Ekko sets these registers in each CONTEXT to provide the correct arguments to each target function:

7. Stack Frame Considerations

Beyond the RSP alignment, the x64 calling convention requires a 32-byte "shadow space" (also called "home space") on the stack above the return address. This space is reserved by the caller for the callee to optionally store parameters:

TextStack layout expected by a function on entry:

RSP + 0x28    [5th argument, if any]
RSP + 0x20    [shadow space for R9]
RSP + 0x18    [shadow space for R8]
RSP + 0x10    [shadow space for RDX]
RSP + 0x08    [shadow space for RCX]
RSP + 0x00    [return address]     <-- RSP points here

Ekko's Rsp -= 8 accounts for the return address slot. The shadow space above it already exists on the timer thread's stack from the captured state. As long as the timer thread's stack has at least 32 bytes of usable space above the adjusted RSP, the target functions have valid shadow space. Since the timer thread has a full-sized stack, this is not a problem in practice.

8. Context Lifetime & Stack Variables

A critical detail is that all CONTEXT structures, USTRING descriptors, the key buffer, and OldProtect are local variables in EkkoObf. They live on the main thread's stack frame:

CVOID EkkoObf( DWORD SleepTime )
{
    CONTEXT CtxThread   = { 0 };   // Stack variable
    CONTEXT RopProtRW   = { 0 };   // Stack variable
    // ... all contexts on main thread's stack

    CHAR    KeyBuf[16]  = { ... }; // Stack variable
    USTRING Key         = { 0 };   // Stack variable
    USTRING Img         = { 0 };   // Stack variable
    DWORD   OldProtect  = 0;       // Stack variable

    // ... setup and queue timers ...

    WaitForSingleObject( hEvent, INFINITE );  // BLOCKS HERE
    // While blocked, stack frame is preserved
    // All stack variables remain valid

    DeleteTimerQueue( hTimerQueue );
}  // Stack frame destroyed AFTER timers complete

9. Visualizing the Memory Layout

The timer thread reads CONTEXT structures from the main thread's stack, then NtContinue redirects execution into system DLL functions. The system functions operate on the process image (encrypting/decrypting, changing permissions) and the event handle. All of these exist in process-global memory and are accessible from any thread.