Hubbry Logo
Windows Native APIWindows Native APIMain
Open search
Windows Native API
Community hub
Windows Native API
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Windows Native API
Windows Native API
Windows Native API
View on Wikipedia
from Wikipedia

The Native API is a lightweight application programming interface (API) used by Windows NT's kernel and user mode applications. This API is used in the early stages of Windows NT startup process, when other components and APIs are still unavailable. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API. The Native API is also used by subroutines such as those in kernel32.dll that implement the Windows API, the API based on which most of the Windows components are created.

Most of the Native API calls are implemented in ntoskrnl.exe and are exposed to user mode by ntdll.dll. The entry point of ntdll.dll is LdrInitializeThunk. Native API calls are handled by the kernel via the System Service Descriptor Table (SSDT).

Function groups

[edit]

The Native API comprises many functions. They include C runtime functions that are needed for a very basic C runtime execution, such as strlen(), sprintf(), memcpy() and floor(). Other common procedures like malloc(), printf(), scanf() are missing (the first because it does not specify a heap to allocate memory from and the second and third because they use the console, accessed only via KERNEL32.DLL). The vast majority of other Native API routines, by convention, have a 2 or 3 letter prefix, which is:

  • Nt or Zw are system calls declared in ntdll.dll and ntoskrnl.exe. When called from ntdll.dll in user mode, these groups are almost exactly the same; they execute an interrupt into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT. When calling the functions directly in ntoskrnl.exe (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not.[1] The Zw prefix does not stand for anything.[2]
  • Rtl is the second largest group of ntdll calls. These comprise the (extended) C Run-Time Library, which includes many utility functions that can be used by native applications, yet don't directly involve kernel support.
  • Csr are client-server functions that are used to communicate with the Win32 subsystem process, csrss.exe (csrss stands for client/server runtime sub-system).
  • Dbg are debugging functions such as a software breakpoint.
  • Ki are upcalls from kernel mode for events like APC dispatching.
  • Ldr are loader functions for PE file handling and starting of new processes.
  • Nls for National Language Support (similar to code pages).
  • Pfx for prefix handling.
  • Tp for threadpool handling.

user32.dll and gdi32.dll include several other calls that execute an interrupt into kernel mode. These were not part of the original Windows NT design, as can be seen in Windows NT 3.5. However, due to performance issues of hardware of that age, it was decided to move the graphics subsystem into kernel mode. As such, system call in the range of 0x1000-0x1FFF are satisfied by win32k.sys (instead of ntoskrnl.exe as done for 0-0x0FFF), and are declared in user32.dll and gdi32.dll. These functions have the NtUser and NtGdi prefix (e.g. NtUserLockWorkStation and NtGdiEnableEudc).

Uses

[edit]

Uses of Native API functions includes but not limited to:

  • Enabling and disabling privileges (RtlAdjustPrivilege)
  • Creating remote threads within processes that are running in different session (RtlCreateUserThread)
  • Running native applications (RtlCreateUserProcess)
  • Performing a forced shutdown (NtShutdownSystem)
  • Causing a BSOD in User mode (NtRaiseHardError)
  • Displaying a string in Native Mode (NtDisplayString)

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Windows Native API

View on Grokipedia
from Grokipedia
The Windows Native API is the low-level interface in Windows NT-based operating systems that enables user-mode applications and subsystems to directly invoke kernel-mode executive services through system calls. It comprises approximately 250 functions, most of which are exported from the NTDLL.DLL in user mode and implemented in the kernel module, with names typically prefixed by "Nt" or "Zw". These functions provide core operating system capabilities, such as process and thread management, memory allocation, file I/O, and , forming the foundation for higher-level APIs like Win32. Introduced with in 1993, the Native API was designed to support multiple execution environments (subsystems) on the NT kernel, allowing native applications to execute even before environment-specific subsystems like Win32 load during system boot. For instance, boot-time utilities such as autochk.exe (which performs disk checks akin to ) rely on Native API calls for their operation, bypassing the Win32 subsystem. The API's routines are invoked via system service dispatch, where user-mode calls transition to kernel mode for execution, ensuring secure and efficient access to system resources. The "Nt" prefix denotes the standard native system services, abbreviating "NT" for Windows NT, while the "Zw" prefix serves as an alias with no inherent meaning, primarily chosen to avoid naming conflicts with other APIs and to facilitate future expansions. In user mode, both versions behave identically, validating parameters as untrusted and probing user-mode buffers for safety; in kernel mode, however, "Zw" assumes trusted inputs without validation, whereas "Nt" checks the caller's mode via the PreviousMode kernel variable. Although largely undocumented— with only a subset detailed in the Windows Driver Kit (WDK)—the Native API is essential for system components like the Client/Server Runtime Subsystem (CSRSS) and is occasionally used by third-party developers for advanced, low-level tasks despite Microsoft's discouragement for general application programming. Over successive Windows versions, the API has evolved, adding functions like those for Advanced Local Procedure Call (ALPC) in Windows Vista while maintaining backward compatibility for core services.

Introduction

Definition and Purpose

The Windows Native is a lightweight, undocumented application programming interface (API) consisting of approximately 250-300 functions that provide direct access to kernel services in Windows NT-based operating systems, bypassing higher-level abstractions. This API forms the foundational layer for system operations, enabling low-level interactions between user-mode components and the kernel without reliance on environment-specific subsystems. It serves as the underlying interface for documented higher-level APIs like Win32, which build upon its primitives to offer more abstracted functionality. The primary purpose of the Native API is to act as the interface for user-mode applications and subsystems to invoke kernel-mode operations, particularly during the early stages of the Windows boot process when components such as the Win32 subsystem are not yet available. For instance, native applications like disk-checking utilities execute in this phase to perform essential initialization tasks directly against kernel services. This design ensures that core system functions can operate independently of loaded environment layers, supporting reliable startup and maintenance operations. Key characteristics of the Native API include its exports from the ntdll.dll dynamic-link library in user mode, which provide stubs that transition to kernel-mode implementations. Error handling is managed through NTSTATUS codes, which are 32-bit values structured with 2 bits for severity (e.g., success, informational, warning, error in bits 30-31), 12 bits for facility codes (bits 16-27) identifying the subsystem, and 16 bits for specific error codes (bits 0-15); for example, STATUS_SUCCESS is defined as 0x00000000. These codes allow precise reporting of outcomes from kernel interactions. The API's internal and undocumented nature is intentional, designed to maintain operating system stability by preventing external dependencies that could lead to compatibility breaks across Windows versions. does not guarantee consistency for undocumented interfaces, allowing internal modifications without impacting officially supported applications. This approach prioritizes the robustness of the core OS while reserving the Native API for 's own subsystems and select low-level tools.

Relation to Other APIs

The Windows Native API constitutes the lowest user-accessible layer in the Windows operating system architecture, serving as the direct interface between user-mode code and the kernel. Higher-level APIs, such as the implemented in dynamic link libraries like kernel32.dll and user32.dll, wrap and abstract Native API calls to provide portability, enhanced error handling, and a consistent developer experience across Windows versions. This layering ensures that applications interact with the system through familiar abstractions while the Native API handles raw kernel communications, including system calls that transition from user mode to kernel mode. A typical invocation path illustrates this relationship: a Win32 function like CreateFileA in kernel32.dll translates parameters (such as converting ANSI strings to and constructing OBJECT_ATTRIBUTES structures) and forwards the request to NtCreateFile in ntdll.dll, which then issues a (e.g., via syscall instruction on x64 architectures) to the kernel's executive services. This path allows Win32 to maintain compatibility and add features like automatic resource cleanup, while the Native provides unmediated access to kernel objects such as file handles. Native API calls return NTSTATUS codes, a mechanism distinct from Win32's error reporting via GetLastError, emphasizing its lower-level nature. In terms of scope, the Native API offers version-specific, fine-grained control—such as direct manipulation of kernel handles without additional validation—making it suitable for system components but riskier for general applications due to its lack of built-in safeguards like normalization or cross-architecture portability provided by Win32. Other environment subsystems, including the deprecated subsystem (implemented via psxdll.dll) and components managed by the (CSRSS), integrate by routing their operations through the Native API to access shared kernel services, ensuring subsystem-agnostic kernel interactions without relying on Win32 exclusivity.

History

Origins in Windows NT

The Windows Native API originated in the late 1980s as part of the project, led by 's team at , drawing heavily on Cutler's prior experience developing the VMS operating system at . Work on the project began in October 1988, with the aim of creating a robust, portable kernel for a new generation of operating systems, initially conceived as a successor to but evolving into a standalone platform. The Native API was designed to serve as the foundational interface between user-mode components and the kernel, providing a secure and efficient that isolated core system services from higher-level user interfaces. A primary design goal was portability across diverse hardware architectures, enabling the system to support not only x86 processors but also RISC platforms such as and Digital Alpha, with the latter added shortly after launch. This modularity was achieved through the use of portable code, a hardware abstraction layer (HAL), and compartmentalized processor-specific implementations, allowing kernel services to remain stable amid user-mode changes. By separating the Native from the Win32 user-mode , ensured that kernel-level operations could evolve independently, promoting long-term security and maintainability while preventing direct user-mode dependencies on internal kernel details. At its debut with on July 27, 1993, the Native API encompassed approximately 100 functions, concentrating on essential areas such as and thread management, file input/output, and allocation. These functions were intentionally undocumented to discourage third-party developers from bypassing the Win32 , thereby enforcing a standardized and preserving Microsoft's control over kernel evolution. About one-third of the services supported asynchronous operations, such as file reads and directory enumerations, to optimize performance in multitasking environments. The API's key integration milestone involved embedding it within the NT kernel executable, , for kernel-mode execution, complemented by user-mode stubs in ntdll.dll to facilitate calls from subsystems and applications. This structure replaced earlier OS/2-style APIs that were initially planned for the project, shifting the focus to a native kernel interface tailored for the Win32 environment while retaining compatibility layers for legacy support.

Evolution Across Versions

The Windows Native API underwent significant expansion in , released in 1996, with additions focused on security enhancements such as additional Nt*-prefixed functions for managing Access Control Lists (ACLs) and improved support for emerging hardware architectures like multiprocessor systems. These changes addressed growing enterprise needs for robust access controls and scalability, building on the foundational set from earlier NT versions. By this release, the total number of Nt/Zw-prefixed system calls had reached approximately 258, reflecting a modest but targeted growth in core kernel interfaces. Windows 2000, launched in 2000, further evolved the API to integrate with services, introducing new Rtl*-prefixed runtime library functions for enhanced registry management and LDAP protocol handling to support directory-based authentication and policy enforcement. optimizations were also implemented for the x86 architecture, improving performance in networked environments. The function count expanded to around 314, accommodating the shift toward domain-centric computing while maintaining compatibility with prior NT applications. In (2006) and (2009), the API incorporated features for session isolation—separating system services into Session 0—and (UAC), adding Nt*-prefixed calls for file and registry virtualization, including NtSetCachedSigningLevel for managing levels in protected processes. These enhancements bolstered security by enforcing mandatory integrity levels and preventing unauthorized elevations. The number of functions grew substantially to about 497 in Vista, enabling more granular control over user-mode interactions. Subsequent versions, from (2012) through and 11 (extending into 2021 and beyond), added support for touch and gesture inputs via new input-handling functions in NTDLL, alongside minor expansions for virtualization and security refinements, such as variants of NtProtectVirtualMemory for advanced . The API's port to ARM64 architecture preserved full compatibility through x64 emulation layers, ensuring seamless operation across processor types. Function counts continued to rise, reaching approximately 589 in and 614 in , with ongoing additions for modern hardware. Windows Server 2025, released on November 1, 2024, features no major structural overhauls to the Native API, with the core set remaining stable at around 614 functions. is rigorously enforced through version-specific checks in NTDLL exports and conditional feature loading, allowing legacy applications to function without modification across decades of OS releases. This evolutionary approach prioritizes stability, with new capabilities typically introduced as optional extensions rather than disruptive changes.

Architecture

User-Mode Components

The user-mode components of the Windows Native API are primarily encapsulated within ntdll.dll, a core that serves as the primary interface for native applications to access system services. This DLL, approximately 2-3 MB in size depending on the Windows version, exports all Native API functions and is automatically loaded into the of every user-mode by the operating system loader. It provides syscall stubs that facilitate the transition from user mode to kernel mode, enabling processes to invoke kernel services without direct dependency on higher-level APIs like Win32. Key components within ntdll.dll include the Ldr* functions, which manage executable image loading and process initialization at a low level. For instance, LdrLoadDll loads dynamic-link libraries into the address space, resolving dependencies and mapping sections before the Win32 loader (kernel32.dll) intervenes, ensuring native applications can bootstrap without relying on the full Win32 subsystem. The entry point of ntdll.dll, LdrInitializeThunk, orchestrates initial thread execution and setup, handling tasks such as initializing the process environment block (PEB) and preparing the runtime before control passes to the application's main . Heap and runtime management are supported by the Rtl* functions, which offer low-level utilities independent of the C runtime library. RtlCreateHeap allocates a heap object in the process's for subsequent operations, allowing native applications to manage dynamic storage via paired functions like RtlAllocateHeap and RtlFreeHeap. These functions also include string manipulation routines, such as RtlStringCbCopy for safe buffer copying, enabling text processing without external library dependencies. Error handling in user mode is facilitated by RtlNtStatusToDosError, which translates NTSTATUS codes returned from Native API calls into equivalent Win32 error codes for compatibility with broader application ecosystems. For example, the NTSTATUS value STATUS_ACCESS_DENIED (0xC0000022) maps to the Win32 error ERROR_ACCESS_DENIED (5), allowing native code to integrate seamlessly with error-reporting mechanisms in user-mode components. This translation occurs entirely in user mode after Native API calls return an NTSTATUS code.

Kernel-Mode Components and System Calls

The kernel-mode components of the Windows Native API are primarily implemented within the executive layer of the operating system, housed in the core kernel executable ntoskrnl.exe. This module provides essential services for device drivers and higher-level components, encompassing object management, virtual memory allocation, process and thread scheduling, input/output operations, and configuration handling. For hardware-specific interactions, the Native API relies on the Hardware Abstraction Layer (HAL), implemented in hal.dll, which abstracts low-level hardware details—such as interrupt controllers, timers, and multiprocessor communication—allowing the executive to operate consistently across diverse hardware platforms without modification. System calls transition from user mode to kernel mode via architecture-dependent instructions that efficiently switch privilege levels and stacks. On x86-64 architectures, the SYSCALL instruction initiates the transition, loading the kernel's system call entry point from the IA32_LSTAR model-specific register (MSR) and preserving user-mode context in registers like RCX and R11. On 32-bit x86 architectures, the SYSENTER instruction serves a similar role, offering faster execution than the legacy INT 2Eh software by avoiding the full overhead; however, INT 2Eh remains supported for in certain scenarios. Once in kernel mode, the system service dispatcher—part of the kernel executive—interprets the System Service Number (SSN) stored in the EAX (x86) or RAX (x64) register to locate the target routine. The dispatch occurs through the System Service Dispatch Table (SSDT), a kernel that maps SSNs to offsets or pointers of executive service implementations in ntoskrnl.exe. Each Native API function is assigned a unique SSN during kernel initialization, enabling rapid lookup; for instance, NtCreateFile uses SSN 0x55 in version 23H2. This mechanism ensures that calls like NtCreateFile are routed to the appropriate I/O manager subsystem, which then forwards the request to file system drivers (e.g., or ) after initial processing. The SSDT is protected in kernel memory and versioned across Windows releases to maintain stability, with SSNs generally preserved for compatibility unless architectural changes necessitate reordering. The Nt* and Zw* variants of Native API functions share identical implementations in kernel mode but differ in their calling conventions and validation behavior, particularly when invoked from kernel-mode . In user mode, both variants execute equivalently, transitioning via the mechanism to the same executive routine without distinction. From kernel mode, Nt* functions invoke the service directly, bypassing and assuming valid, trusted parameters to optimize performance at any level (IRQL). In contrast, Zw* functions route through (KiSystemService), which copies parameters from the caller stack, sets the previous mode to kernel (for access checks), and enforces IRQL restrictions—typically requiring PASSIVE_LEVEL to prevent issues in high-IRQL contexts like dispatch or deferred procedure calls. This design supports robust error handling and in driver code while maintaining efficiency for trusted paths. Prior to executing any service, the kernel rigorously validates parameters passed from user mode to prevent or corruption, including checks for pointer accessibility, buffer bounds, object handles, and alignment. Invalid inputs trigger immediate returns with NTSTATUS error codes, such as STATUS_INVALID_PARAMETER (0xC000000D), which indicates a malformed argument like an inaccessible user pointer or incorrect structure size. These validations occur early in the dispatcher or within the service routine itself, ensuring system integrity; for example, NtCreateFile probes the input object attributes and I/O status block before attempting file creation or opening. User-mode invocations originate from stubs exported by ntdll.dll, which prepare registers with the SSN and parameters before issuing the transition instruction.

Function Categories

Nt and Zw System Calls

The Nt* and Zw* functions constitute the primary system call interfaces within the Windows Native API, enabling direct invocation of kernel-mode services from user mode. These functions, exported from ntdll.dll, number approximately 500 as of Windows 11 and provide low-level access to operating system resources such as processes, files, and the registry. Each system service routine exists in two variants—prefixed with Nt or Zw—that are functionally equivalent in user mode, where they trigger a transition to kernel mode via instructions like SYSENTER or SYSCALL to execute the underlying kernel implementation in ntoskrnl.exe. In kernel mode, however, the Zw variants assume parameters are trusted and skip validation, while the Nt variants probe parameters based on the caller's previous mode to ensure security. These functions are organized into categories reflecting core kernel operations, including and thread , file and I/O handling, and registry manipulation. In and thread , functions like NtCreateThreadEx allow creation of threads with precise control, using parameters such as a pointer to receive the thread , desired access mask, object attributes for security, the target , start routine address, argument to pass, creation flags (e.g., THREAD_CREATE_FLAGS for initial state), and stack sizing options. For file and I/O operations, NtCreateFile facilitates file object creation or opening, specifying parameters including a pointer to the file , access , object attributes (incorporating FILE_OBJECT details like name and security), an I/O status block for results, allocation size, , mode, , creation options, and extended attributes buffer. Registry functions, such as NtCreateKey, enable key creation with parameters like a pointer to the key , desired access, object attributes, title index for subkeys, class name string, creation options, and an optional output for result status. Parameter passing in Nt and Zw functions relies on kernel-defined structures for robustness and , such as OBJECT_ATTRIBUTES for object naming and contexts, IO_STATUS_BLOCK for asynchronous operation outcomes (storing status and byte counts), and opaque handles (typedef void* ) to reference kernel objects without exposing internals. Buffers and pointers must reside in valid spaces, with user-mode calls undergoing automatic probing to prevent kernel crashes from invalid access. All functions return an NTSTATUS value—a 32-bit indicating (e.g., STATUS_SUCCESS = 0x00000000) or specific errors like STATUS_ACCESS_DENIED. Usage demands manual parameter validation by developers, as these interfaces lack higher-level abstractions and comprehensive ; for example, NtAllocateVirtualMemory reserves or commits regions via parameters including the process , base pointer, zero bits for alignment, region pointer, allocation type (e.g., MEM_COMMIT), and protection flags (e.g., PAGE_READWRITE), requiring precise calculations to avoid STATUS_INVALID_PARAMETER. Supporting structures like RTL_USER_PROCESS_PARAMETERS may be prepared using Rtl run-time routines for parameter initialization.

Rtl Run-Time Library Functions

The Rtl Run-Time Library functions constitute a substantial portion of the , comprising over 1,000 utility routines primarily implemented in user mode within ntdll.dll. These functions serve as low-level helpers for a variety of tasks, enabling efficient operations without direct kernel invocations or reliance on higher-level abstractions like the Win32 API. They support the core functionality of native applications and internal Windows components by providing reusable primitives for resource management and data processing, often returning NTSTATUS codes to indicate success or failure. Unlike system calls, Rtl functions execute entirely in user space, making them integral to the runtime environment of processes that interact with the Native API. Key categories of Rtl functions address essential user-mode needs, including memory allocation, string manipulation, and time handling. In , RtlCreateHeap initializes a private heap object, reserving and returning a on success or an NTSTATUS value such as STATUS_NO_MEMORY if allocation fails; subsequent allocations use RtlAllocateHeap, which supports options via HEAP_INFORMATION_CLASS for features like low-fragmentation heaps. String operations emphasize safety and efficiency, with RtlStringCbCopyN performing bounded copies of Unicode or ANSI strings to mitigate risks by enforcing byte-count limits. Time-related utilities, such as RtlTimeToSecondsSince1970, convert 64-bit absolute system times to seconds elapsed since January 1, 1970 (the Unix ), facilitating cross-platform compatibility in native code. Synchronization primitives like RtlInitializeCriticalSection enable thread-safe critical sections, allowing developers to implement without Win32 dependencies. Error handling across Rtl functions typically involves NTSTATUS returns, a 32-bit status code format that distinguishes between success (values with the high bit clear) and various failure conditions, enabling granular error propagation in native applications. For example, heap creation failures propagate STATUS_NO_MEMORY, while other routines may return codes like STATUS_ACCESS_DENIED for privilege issues. This mechanism integrates seamlessly with the broader Native API, where Rtl functions underpin ntdll.dll's internal logic, such as process initialization and subsystem support. Developers building native executables leverage these for direct system interaction; RtlCaptureContext, for instance, retrieves the current thread's CONTEXT record for , stack walking, or scenarios, capturing registers and control flow without kernel assistance.

Other Native API Functions

The Windows Native API includes a collection of miscellaneous functions outside the primary Nt/Zw and Rtl categories, encompassing routines that support specialized operations such as module loading, , and limited kernel interfaces. These functions are primarily employed in low-level scenarios like early boot processes, custom (DLL) loaders, and interactions with the (CSRSS). They enable fine-grained control over system initialization and runtime behaviors that higher-level APIs abstract away, often in environments where standard Win32 components are unavailable. The Ldr* family of functions handles (PE) module loading and dependency resolution within user-mode processes. For instance, LdrLoadDll loads a specified DLL into the calling process's , accepting a path prefix, optional DLL characteristics (such as flags like LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR for directory-specific searches), the module name as a UNICODE_STRING, and an output for the loaded module. This function underpins dependency resolution during process startup and is invoked internally by higher-level loaders like LoadLibraryExW. Similarly, LdrGetDllHandle retrieves a to an already-loaded DLL without incrementing its reference count, facilitating efficient dependency checks by searching the process's loaded module based on the module name and optional path flags. Another key routine, LdrpInitializeProcess, performs early process setup during initialization, configuring the loader environment and preparing the module before full subsystem . These functions are essential for custom loaders in boot environments, where they manage PE file handling without relying on the full Win32 subsystem. The Csr* functions facilitate client-server runtime communication between user-mode applications and the CSRSS , which manages subsystem services like console I/O and creation. Central to this is CsrClientCallServer, which sends API messages to CSRSS server DLLs (such as basesrv.dll or winsrv.dll) via Local Procedure Call (LPC) ports and awaits replies, supporting empty packets for simple requests, short packets within LPC size limits (up to 304 bytes), and long packets using sections for larger data transfers via capture buffers. Connections are established early via CsrClientConnectToServer to ports like \Windows\ApiPort, enabling abstractions for Win32 in kernel32.dll and user32.dll. The CSR API dispatch tables include over 100 routines across categories like base server operations (e.g., BaseSrvCreateProcess for management) and console server functions (e.g., SrvAllocConsole for console allocation), all invoked through CsrClientCallServer for tasks such as thread creation and NLS cache updates. Supporting utilities like CsrAllocateCaptureBuffer and CsrFreeCaptureBuffer manage for these exchanges, ensuring efficient IPC in multi-locale or console-heavy applications. Ki* and Nls* functions provide limited user-accessible interfaces to kernel operations and national language support, respectively, though they remain largely internal. Ki routines, such as those for upcalls from kernel mode, handle events like asynchronous procedure call (APC) dispatching and privilege checks (e.g., KiRaiseSecurityCheck for escalation validation), but user-mode access is restricted and typically reserved for debugging or low-level kernel interactions. Nls* functions support code page handling and locale-specific string operations, often integrated with Rtl* for parsing in loader contexts during multilingual process initialization. These categories are used sparingly in custom or boot-time code to interface with kernel events or localization without full subsystem dependencies.

Applications and Uses

Internal Use by Microsoft Components

The Windows Native API plays a foundational role in the internal operations of components, particularly during the boot process and in core system subsystems. Winload.exe, the OS loader, loads essential kernel components such as , Hal.dll, and boot-start device drivers, while preparing CPU registers for kernel execution. Once loaded, initializes executive subsystems and boot drivers in its phase 0 initialization, invoking functions like KiSystemStartup to set up the kernel environment before loading Win32k.sys. This direct reliance on low-level functions ensures control over and executive services prior to higher-level subsystem activation. Microsoft's user-mode subsystems heavily depend on the Native API for seamless kernel interactions. Kernel32.dll, a key component of the Win32 subsystem, forwards the majority of its API calls to Native API functions (prefixed with Nt*) to handle executive operations, bridging user-mode applications with kernel services. The Client/Server Runtime Subsystem (CSRSS.exe), launched by the Session Manager, uses Native API mechanisms indirectly through kernel-mode components like Win32k.sys for session initialization and management, including Csr* functions that facilitate client-server communication within the subsystem. In performance-critical areas, components employ direct Nt* calls to minimize overhead in sensitive operations. For instance, the Local Security Authority Subsystem Service (LSASS.exe) handles processes, including credential validation and creation, through interactions with kernel services. Drivers and services, such as those managing I/O in security contexts, similarly use Nt* calls to bypass higher-level abstractions for efficient resource access. Exemplifying this exclusive reliance, the (Smss.exe) operates as a native application during startup, invoking only Windows Native API functions—such as NtInitializeRegistry—to create security tokens, initialize sessions, and spawn CSRSS.exe without any dependency on Win32 APIs. This design underscores the Native API's centrality to 's core infrastructure, enabling internal calls across boot phases to establish a secure and operational system environment.

Third-Party and Specialized Applications

The Windows Native API, though primarily intended for internal use, has found application in select third-party projects aimed at achieving compatibility with Windows ecosystems. A notable example is , an open-source operating system project that reimplements key Native API functions to enable binary compatibility with Windows applications and drivers, allowing them to run natively without emulation layers. This implementation draws from publicly reverse-engineered details of the API to replicate behaviors such as process management and file I/O, supporting the project's goal of creating a free alternative to Windows. In the realm of security research and adversarial software, the Native API is frequently targeted by and exploits for low-level system manipulation. Rootkits, a class of stealthy , commonly hook syscall dispatch tables to intercept and modify Native calls, enabling them to conceal processes, files, or network activity from detection tools. techniques in exploits often leverage undocumented Nt* functions, such as NtCreateSection for memory mapping or NtDuplicateObject for handle manipulation, to bypass security boundaries like (UAC) without invoking higher-level Win32 APIs that trigger prompts. These methods allow attackers to gain elevated privileges by directly interfacing with kernel services, as documented in analyses of real-world campaigns. Specialized performance-critical applications, including certain antivirus engines and real-time games, occasionally employ direct Native API calls to optimize and avoid overhead from layered abstractions. For instance, custom memory allocators in may invoke NtAllocateVirtualMemory to manage process address space with finer control over commitment and protection attributes, potentially reducing latency in scanning operations. Similarly, some game engines use Rtl* functions for efficient string handling or heap management to enhance runtime performance. However, explicitly discourages such usage in user-mode applications due to the API's lack of guarantees, emphasizing reliance on documented Win32 APIs instead. In embedded and recovery scenarios, the Native API supports third-party bootloaders and custom operating system loaders that require seamless integration with Windows environments. Tools in dual-boot configurations or forensic recovery kits may call Native functions like NtLoadDriver to manage boot-time drivers or NtQuerySystemInformation to probe hardware during initialization, facilitating hybrid setups where non-Windows loaders chain into the Windows . These applications are typically limited to expert developers in niche domains, such as for industrial systems. The fragility of the Native API poses substantial risks for third-party implementations, as undocumented changes in Windows versions can render code inoperable. Undocumented changes in Native API functions across Windows versions, including , can disrupt specialized tools relying on them for data structures, necessitating frequent re-engineering. Such breakage underscores the API's unsuitability for production third-party software, confining its adoption to experimental or high-risk contexts where alternatives are infeasible.

Documentation and Challenges

Official Documentation Status

Microsoft maintains a policy of intentionally limiting official documentation for the Windows Native API to discourage direct developer reliance on it, documenting only a select few functions primarily for kernel-mode scenarios. The (WDK) covers approximately 25 out of more than 250 Native API functions, exemplified by NtCreateFile for file operations in drivers, while the full API remains unpublished to avoid and promote higher-level interfaces. Partial official resources exist through the Windows Internals book series by and colleagues, which provides conceptual overviews and examples of select Native API usage; Microsoft Learn platforms document NTSTATUS error codes comprehensively and detail some associated structures like OBJECT_ATTRIBUTES. No official comprehensive reference has emerged since Gary Nebbett's 2000 publication, Windows NT/2000 Native API Reference, which reverse-engineered and cataloged the then-current . As of November 2025, the core Windows Native API continues to lack full official documentation. Driver developers access more targeted guidance via WDK components like NDIS for networking and WDM for device management, but user-mode comprehensive coverage is absent. This approach stems from Microsoft's strategy to encourage adoption of stable, documented APIs like Win32 and WinRT for general applications, thereby insulating developers from potential ABI changes in the internal Native API during system updates. Community-driven resources supplement these gaps but do not alter the official stance.

Reverse Engineering and Community Efforts

Developers and researchers often resort to to uncover the details of the Windows Native API, given its largely undocumented nature. Common tools for this purpose include API Monitor, which intercepts and logs API calls made by applications in real-time; , a powerful for analyzing user-mode and kernel-mode code; and x64dbg, an open-source suited for dynamic analysis of 64-bit executables. These tools facilitate tracing system calls by attaching to processes and monitoring interactions with ntdll.dll, the primary user-mode library exporting Native API functions. A key method involves disassembling ntdll.dll using IDA Pro, a commercial disassembler that reveals function prototypes, parameters, and control flows through static analysis. Complementing this, dynamic analysis employs Event Tracing for Windows (ETW) to log syscalls at runtime, capturing kernel transitions without significant performance overhead. ETW providers, such as the Microsoft-Windows-Kernel-Process provider, enable detailed tracing of Native API invocations, aiding in parameter inference and behavior mapping. Community efforts have produced valuable resources for Native API exploration. Geoff Chappell's extensive studies document structures, parameters, and version-specific variations of undocumented functions, serving as a reference for reverse engineers. The Undocumented NT site compiles low-level details on kernel, Native API, and functions, including prototypes and usage notes derived from analysis. On , repositories like winsiderss/phnt maintain header files with over 300 Native API prototypes, updated regularly from and symbol files for use in projects like Process Hacker. Additionally, the project offers an open-source reference implementation of many Native API functions, allowing developers to study and verify behaviors against Windows. In 2025, efforts have intensified due to security research, particularly in defending against syscall hijacking techniques where attackers direct syscalls to malicious handlers. This has led to deeper scrutiny of Native API for evasion patterns, with tools and methods evolving to counter (EDR) bypasses. Books such as "Windows Kernel Programming" by Pavel Yosifovich provide partial guides to Native API usage, including debugging and implementation examples drawn from . Challenges persist in recent Windows versions, including techniques that complicate analysis, such as dynamic resolution of system service numbers (SSNs) in to prevent static mapping of syscalls. While Microsoft's permits for purposes, the practice raises ethical concerns regarding proprietary internals and potential misuse in security contexts.

References

  1. https://learn.microsoft.com/en-us/sysinternals/resources/inside-native-applications
  2. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-nt-and-zw-versions-of-the-native-system-services-routines
  3. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/what-does-the-zw-prefix-mean-
  4. https://www.geoffchappell.com/studies/windows/win32/ntdll/api/native.htm
  5. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/87fba13e-bf06-450e-83b1-9241dc81e781
  6. https://learn.microsoft.com/en-us/windows/compatibility/undocumented-apis
  7. https://empyreal96.github.io/nt-info-depot/Windows-Internals-PDFs/Windows%20System%20Internals%207e%20Part%201.pdf
  8. http://www.bitsavers.org/pdf/microsoft/windows_NT_3.1/Custer_Inside_Windows_NT_1993.pdf
  9. https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/
  10. https://empyreal96.github.io/nt-info-depot/Windows-Internals-PDFs/WindowsInternals-4e.pdf
  11. https://betawiki.net/wiki/Windows_NT_3.1
  12. https://www.cl.cam.ac.uk/teaching/1516/OpSystems/pdf/12-Case-Study-WindowsNT.pdf
  13. https://j00ru.vexillium.org/syscalls/nt/32/
  14. https://learn.microsoft.com/en-us/windows/arm/overview
  15. https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
  16. https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info
  17. https://www.dll-files.com/ntdll.dll.html
  18. https://community.osr.com/t/ntdll-dll/31789
  19. https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-rtlntstatustodoserror
  20. http://undocumented.ntinternals.net/index.html?page=UserMode%252FUndocumented%2520Functions%252FExecutable%2520Images%252FLdrLoadDll.html
  21. https://www.nynaeve.net/?p=205
  22. https://blogs.blackberry.com/en/2017/10/windows-10-parallel-loading-breakdown
  23. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlcreateheap
  24. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/windows-kernel-mode-executive-support-library
  25. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/windows-kernel-mode-hal-library
  26. https://codemachine.com/articles/system_call_instructions.html
  27. https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/glimpse-into-ssdt-in-windows-x64-kernel
  28. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
  29. https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntcreatefile
  30. https://github.com/j00ru/windows-syscalls
  31. http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FNT%20Objects%2FKey%2FNtCreateKey.html
  32. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntallocatevirtualmemory
  33. https://www.geoffchappell.com/studies/windows/win32/ntdll/api/index.htm
  34. https://learn.microsoft.com/en-us/sysinternals/resources/windows-internals
  35. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlallocateheap
  36. https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-rtltimetosecondssince1970
  37. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-ntstatus-values
  38. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlcapturecontext
  39. https://ntdoc.m417z.com/ldrloaddll
  40. https://ntdoc.m417z.com/ldrgetdllhandle
  41. https://www.elastic.co/security-labs/winvisor-hypervisor-based-emulator
  42. https://www.geoffchappell.com/studies/windows/win32/ntdll/api/csrutil/clientcallserver.htm
  43. https://j00ru.vexillium.org/2010/07/windows-csrss-write-up-inter-process-communication-part-2/
  44. https://j00ru.vexillium.org/csrss_list/api_list.html
  45. https://learn.microsoft.com/en-us/windows/win32/intl/national-language-support
  46. https://www.microsoftpressstore.com/articles/article.aspx?p=2201310
  47. https://attack.mitre.org/techniques/T1014/
  48. https://dl.acm.org/doi/10.1145/3708821.3736206
  49. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntcreatefile
  50. https://www.informit.com/store/windows-nt-2000-native-api-reference-9781578701995
  51. https://learn.microsoft.com/en-us/windows/win32/w8cookbook/undocumented-apis
  52. http://www.rohitab.com/apimonitor
  53. https://www.apriorit.com/dev-blog/reverse-engineering-monitoring-syscalls-windows
  54. http://undocumented.ntinternals.net/
  55. https://github.com/winsiderss/phnt
  56. https://www.darkrelay.com/post/stealth-syscall-execution-bypass-edr-detection
  57. https://leanpub.com/windowskernelprogramming
  58. https://redops.at/en/blog/indirect-syscalls-and-dynamic-ssn-retrieval-via-apis
  59. https://fluxsec.red/reverse-engineering-windows-11-kernel
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.