Module 3: System Service Numbers (SSN)

Every kernel function has a number. Know the number, open the gate.

What Is an SSN?

Each Nt* / Zw* function exported by ntdll.dll has a unique SSN. This number serves as an index into the kernel's System Service Descriptor Table (SSDT). The SSN is a simple unsigned integer, typically fitting in 12 bits (values range from 0 to roughly 470 on modern Windows builds).

The SSN for a function is embedded directly in the ntdll stub as an immediate value in the mov eax, <SSN> instruction:

ASM; NtAllocateVirtualMemory on Windows 10 21H2 (x64)
; SSN = 0x18 (24 decimal)
ntdll!NtAllocateVirtualMemory:
  4c 8b d1          mov  r10, rcx       ; save 1st param
  b8 18 00 00 00    mov  eax, 0x18      ; SSN = 0x18
  f6 04 25 08 03 fe
  7f 01             test byte ptr [SharedUserData+0x308], 1
  75 03             jnz  +3             ; if hypervisor flag set (VBS/HVCI), use int 2e path
  0f 05             syscall
  c3                ret
  cd 2e             int  0x2e           ; alternative path (VBS/HVCI)
  c3                ret

SSN Variation Across Versions

Here are some examples showing how SSNs differ across Windows builds. Note how the ordering is not always consistent -- Microsoft can insert new syscalls between existing ones, shifting everything above:

Notice that some SSNs (like NtAllocateVirtualMemory at 0x18) remain stable across recent Windows 10 and 11 builds, while others (like NtCreateThreadEx) shift with each major version as new syscalls are added to the table.

The Nt* / Zw* Naming Convention

You will see two prefixes for system service functions: Nt and Zw. In user mode (ntdll.dll), they are identical -- both point to the same stub and the same SSN. The distinction matters only in kernel mode:

C// In ntdll.dll (user mode): Nt and Zw are the SAME function
// Both resolve to the same SSN and syscall stub
NtAllocateVirtualMemory == ZwAllocateVirtualMemory  // same address

// In ntoskrnl.exe (kernel mode): they differ
// Nt* = direct call (no privilege check, assumes kernel caller)
// Zw* = sets PreviousMode = KernelMode, then dispatches through SSDT
//        This is how kernel-mode code safely calls itself through the SSDT

Static vs. Dynamic SSN Resolution

There are fundamentally two approaches to obtaining SSNs for direct syscalls:

Hell's Gate pioneered the dynamic approach. At runtime, it reads the loaded ntdll.dll from the process's own memory, walks the Export Address Table to find Nt*/Zw* functions, and extracts the SSN directly from the mov eax, SSN instruction bytes in each stub. Since ntdll.dll is loaded into every Windows process, this information is always available.

SSN Ordering: The Alphabetical Property

A critical observation that Hell's Gate and its successors exploit: on every Windows version, the SSNs are assigned in alphabetical order of the Zw* function names. This means:

C// SSNs are assigned alphabetically by Zw* name:
// ZwAcceptConnectPort       -> SSN 0x00
// ZwAccessCheck             -> SSN 0x01
// ZwAccessCheckAndAuditAlarm -> SSN 0x02
// ...
// ZwAllocateVirtualMemory   -> SSN 0x18
// ...
// ZwWriteVirtualMemory      -> SSN 0x3A
// ...

// This means: if you know the SSN of one function,
// and you know the alphabetical order of Zw* names,
// you can CALCULATE any other SSN.

// Neighbor functions in the EAT (sorted by address) have SSNs
// that differ by exactly 1 from their alphabetical neighbors.