In the previous section, we saw how virtual memory is divided into user-space (process memory) and kernel space (kernel memory). The user-space contains code (such as executable and DLL) that runs with restricted access, known as the user mode. In other words, the executable or DLL code that runs in the user space cannot access anything in the kernel space or directly interact with the hardware. The kernel space contains the kernel itself (ntoskrnl.exe) and the device drivers. The code running in the kernel space executes with a high privilege, known as kernel mode, and it can access both the user-space and the kernel space. By providing the kernel with a high privilege level, the operating system ensures that a user-mode application cannot cause system instability by accessing protected memory or I/O ports. Third-party drivers can get their code to run in kernel mode by implementing and installing signed drivers.

The difference between the space (user space/kernel space) and the mode (user mode/kernel mode) is that space specifies the location where the contents (data/code) are stored, and mode refers to the execution mode, which specifies how an application's instructions are allowed to execute.

If the user-mode applications cannot directly interact with the hardware, then the question is, how can a malware binary running in user-mode write content to a file on the disk by calling the WriteFile API?. In fact, most of the APIs called by user-mode applications, end up calling the system service routines (functions) implemented in the kernel executive (ntoskrnl.exe), which in turn interacts with the hardware (such as, for writing to a file on the disk). In the same manner, any user-mode application that calls a GUI-related API ends up calling the functions exposed by win32k.sys in the kernel space. The following diagram illustrates this concept; I have removed some components from the user-space, to keep it simple. The ntdll.dll (residing in the user-space) acts as the gateway between the user-space and the kernel space. In the same way, user32.dll acts as a gateway for the GUI applications. In the next section, we will mainly focus on the transition of the API call to the kernel executive's system service routines via ntdll.dll: