Windows Mobile 6.5 Secure Boot Verification

Windows Mobile 6.5 maintained platform integrity and enforced carrier locks through a hardware-anchored, multi-stage bootloader chain rather than modern UEFI secure boot standards. By validating cryptographic signatures at each stage of the startup sequence and checking firmware images against carrier-specific identification tags, locked devices prevented the installation or execution of unauthorized operating systems, unsigned kernels, and modified radio software.

The Multi-Stage Bootloader Chain

Windows Mobile 6.5 ran on the Windows CE 5.2 kernel, which relied on a staged boot process typically divided into three primary components:

  1. Boot ROM: Hard-coded directly into the processor during manufacturing, this immutable code executed first. It initialized basic hardware registers and verified the integrity of the next stage using manufacturer-embedded public keys.
  2. Initial Program Loader (IPL): The IPL initialized the device's volatile memory (RAM) and loaded the next bootloader stage into system memory.
  3. Secondary Program Loader (SPL): The SPL served as the primary gatekeeper for the system. It managed low-level hardware initialization, user-facing bootloader modes (such as USB flashing interfaces), and final kernel integrity checks.

The chain of trust required that each stage cryptographically verify the digital signature of the subsequent stage before passing execution control. If a signature failed verification, the boot sequence halted immediately, rendering the device inoperable until valid software was restored.

Cryptographic Firmware Signatures

To ensure that only authorized builds reached the execution phase, Original Equipment Manufacturers (OEMs) like HTC, Samsung, and HP signed their firmware packages using asymmetric RSA encryption.

When a firmware package (often packaged as an .nbh or .bin image) was flashed to the device, the SPL extracted the payload's digital signature and verified it against root public keys stored in secure, read-only memory. If an end-user attempted to flash an unsigned ROM, a custom Windows Mobile 6.5 build, or a build signed by an unrecognized private key, the SPL rejected the write operation and preserved the existing partition data.

Carrier Identification (CID) Checks

For carrier-locked devices, signature verification was coupled with Carrier Identification (CID) validation. The CID was a specific alphanumeric string stored in a protected, non-volatile block of device storage (such as NVRAM or the Radio area) that designated the network operator (e.g., AT&T, Vodafone, or T-Mobile).

During the flash process and the boot verification routine:

  • The SPL read the hardware-assigned CID from the protected sector.
  • The SPL inspected the header of the OS and Radio image partitions to identify the intended target carrier.
  • If the image's target CID did not match the device's hardware CID, the bootloader refused to apply the update or launch the kernel.

A universal identifier known as "SuperCID" existed primarily in development and unbranded retail units, which bypassed this specific string comparison while still requiring valid manufacturer signatures.

Execution of the OS Kernel

Once the SPL successfully verified both the cryptographic signature and the carrier metadata of the system image, it unpacked the operating system image into RAM. The SPL then verified the checksum and structure of the core Windows CE kernel file (nk.exe) before handing over execution control. Once nk.exe took control, the Windows Mobile operating system loaded its drivers, system services, and security subsystems, maintaining the protected state established by the hardware boot chain.