Kernel Security Levels in Windows Mobile 6.5

Windows Mobile 6.5 relied on an architecture derived from the Windows Embedded CE 5.2 core to enforce strict separation between critical operating system functions and third-party software. By leveraging hardware-enforced CPU modes, a two-tier application trust model, memory-mapping boundaries, and API interception mechanisms, the platform ensured that user-space applications could neither corrupt the core kernel nor compromise critical system tasks.

Hardware CPU Modes: User vs. Kernel Separation

At the processor level, Windows Mobile 6.5 utilized ARM architecture privilege states to establish a fundamental barrier between system and user code. The kernel, driver modules, and core hardware abstractions ran in privileged Supervisor Mode (kernel mode), granting unrestricted access to hardware registers and system memory. In contrast, standard application threads executed in non-privileged User Mode.

Any attempt by a user-mode process to directly access memory addresses assigned to the kernel triggered an immediate hardware-level access violation via the Memory Management Unit (MMU). For user software to request operating system tasks, it had to invoke software interrupts that securely transitioned execution into kernel mode through controlled entry points.

The Two-Tier Security Model

Process isolation in Windows Mobile 6.5 was governed by an execution policy categorizing code into two primary security levels:

• Trusted (Privileged): Binaries bearing a cryptographic signature from a recognized Certificate Authority (CA) residing in the device's system certificate store were granted trusted status. Trusted processes could call sensitive system APIs, access restricted registry paths, communicate directly with hardware-level drivers, and interact with the kernel without aggressive sandboxing.
• Untrusted (Normal): Unsigned applications, or applications signed with unverified certificates, ran as untrusted code. Untrusted processes were strictly sandboxed. The operating system actively blocked them from loading native kernel-mode drivers, modifying core system binaries, accessing shared memory belonging to other processes, or executing privileged API sets.

Protected Server Libraries and API Trapping

To allow processes to safely interact with core operating system services, Windows Mobile 6.5 employed Protected Server Libraries (PSLs). System servers—such as the graphics engine (GWES), file system (Filesys), and connection managers—existed as distinct processes outside standard application space.

When an application called a system API, the call was converted into an inter-process Remote Procedure Call (RPC) intercepted by the kernel. The kernel evaluated the calling process's security token and trust level before passing the execution context to the destination server. If an untrusted process attempted to invoke an unauthorized API function (such as modifying radio stack settings or cellular provisioning), the kernel rejected the call and returned an access-denied error, preventing privilege escalation.

Memory Slotting and Access Control

The 32-bit virtual memory model used by Windows Mobile 6.5 divided addressable space into 32 distinct slots of 32 megabytes each. The kernel (nk.exe) and primary system drivers were assigned dedicated slots, while active user processes were assigned their own isolated slots.

Memory isolation between these slots was enforced through hardware page tables configured by the kernel:

• Each process could only modify data within its assigned 32 MB slot and its allotted thread-local storage.
• The kernel dynamically modified the MMU's domain access control registers during thread switches to disable read and write access to other active process slots.
• Inter-process memory reading or writing required explicit shared-memory handles or kernel-brokered point-to-point message queues, preventing rogue processes from reading sensitive data from concurrent processes.