Windows Architecture

Windows Architecture

A processor inside a machine running the Windows operating system can operate under two different modes: User mode and kernel mode. Applications run in user mode, and operating system components run in kernel mode. When an application wants to accomplish a task, such as creating a file, it cannot do so on its own. The only entity that can complete the task is the kernel, so instead applications must follow a specific function call flow. The diagram below shows a high level of this flow.

1. User Processes -a program/application executed by the user such as Notepad, Google Chrome or Microsoft Word.
2. Subsystem DLLs - DLLs that contain API functions that are called by user processes. An example of this would be kernel32.dll exporting the CreateFile function, other common subsystem DLL are ntdll.dll, advapi32.dll and user32.dll
3. Ntdll.dll - A system-wide DLL which is the lowest layer available in user mode. This is a special DLL that creates the transition from user mode to kernel mode. This is often referred to as the Native API or NTAPI.
4. Executive Kernel - This is what is known as the Windows Kernel and it calls other drivers and models available within kernel mode to complete tasks. The Windows Kernel is partially stored in a file ntoskrnl.exe under C:\Windows\System32.

Function Call Flow

The image below shows an example of an application that creates a file. It begins with the user application calling the CreateFile function which is available in kernel32.dll. Kernel32.dll is a critical DLL that exposes applications to the Windows API and is therefore can be seen loaded by most applications. Next, CreateFile calls its equivalent NTAPI function , NtCreateFile, which is provided through ntdll.dll. Ntdll.dll then executes an assembly sysenter (x86) or syscall (x64) instruction, which transfers execution to kernel mode. The kernel NtCreateFile function is then used which calls kernel drivers and modules to perform the requested task.

We are able to observe this functionality within a debugger

Syscalls can be invoked directly without having to go through the Windows API. The Windows API simply acts as a wrapper for the Native API. With that being said, the Native API is more difficult to use because it is not officially documented by Microsoft. Furthermore, Microsoft advises against the use of Native API functions because they can be changed at any time without warning.