Walkthrough of the Windows Boot Process - with a focus on System Files

This article/blog gives a walkthrough of the modern windows (NT 6.0 till windows 8.1) boot process. The focus of this article is to make the reader aware of the different files that are used by the system especially the exe and dll files.

Who is this article for: People interested in windows security and feel that the windows hood is too opaque for comfort. The article is an effort to explain different processes and what they do also naming the files that start those processes. The article is for people who use tools like ‘Process Explorer’, ’Process Monitor’ from the Sysinternals Suite and with the new (Windows 8) Task Manager and find process names they do not recognize (but should).

Fig1 - The Windows Boot Process with System Files (Click Image to enlarge)

The intention to write this article came up during investigations, on system performance and malware hunting/analysis, when filenames kept coming up repeatedly but did make any sense to newer members of the team. For example svchost which has multiple copies running, csrss and smss all sounded like names a hacker would use to name his malware. Where do these files come from and what is the legal path for them to be executed from are discussed in this article.

Introduction

The word boot up comes from bootstrap i.e. to pull up by the bootstraps used figuratively means to do something practically impossible. (You can’t lift yourself by pulling on your own bootstraps). This impossible task turns out to be what our computer does daily and possibly, multiple times a day.

Scope of this article: The boot process of the computer hardware machine is not the scope of this article therefore we will begin our story after the BIOS passes the control to the Master Boot Record, still focusing on lesser details for the phases before

1-      After powering up the machine the BIOS (or EFI) gets the control of the processor. The BIOS reads the Master Boot Record from the Hard disk in to physical memory and sets the microprocessor registers to jump to the Master Boot Record’s code.

2-      The Master Boot Record (MBR) is a special area which contains information about the hard disks, the partition table and which partitions are the active bootable partitions on the hard disk. The control is then passed to an operating system loader i.e. the MBR loads the Volume Boot Record (VBR) into memory.

3-      Point 2 is the case when there is just one operating system installed on the machine. If there are multiple operating systems (like the case of dual boot) then the MBR needs to carry out a more complex operation. Due to the limited size of the Master Boot Record it cannot contain a very large or complex set of instructions. Therefore it may load a boot loader at this point, instead of an operating system. For example in case of a dual boot system a boot loader like GRUB is loaded which may give you multiple options to choose from to boot an operating system.

4-      Continuing with the example of GRUB, it contains the partition identifier on which an OS is installed. If a user chooses to boot in Windows GRUB will pass on control to the Volume Boot Sector of the partition on which Windows is expected to be. This process of loading an OS via a Boot loader (like grub) is called chain loading.

5-      The NT Boot Sector serves its purpose of reading from the NTFS file system, We are now inside the NTFS file system and from here onwards the files with .exe extension will start coming up.
The primary purpose of the NT Boot sector is to read and load the BOOTMGR file which is a hidden system file located either on the %SYSTEMROOT% partition or on an EFI partition, therefore it will not be displayed if it is searched on the hard disk using Windows Explorer. The file cannot be executed as it has a 16 bit header, it starts executing in 32 bit later, automatically.

6-      The BOOTMGR file is located in the ‘c:\ folder’. In a lot of texts the bootmgr is called the bootmgr.exe

7-      The BOOTMGR, basically, replaces the NTLDR file from the pre-Vista era.  BOOTMGR checks the system status if the system was in hibernation. At this point the boot process can branch off in two ways.

8-      The BOOTMGR checks for the Boot Configuration Data (BCD) file located in EFI System Partition, therefore the BCD will not be displayed if searched for using Windows Explorer as it is on a different System Partition. The BCD file contains the information regarding the boot process. The purpose of the BCD can be easily understood knowing that it replaces the boot.ini file from the pre-vista era.
The format of the contents of the BCD is just like the Windows Registry, and it is very suitable for the BCD to have a Binary Windows Registry like format as the contents of the BCD file are loaded in the Windows Registry under the key: HKEY_LOCAL_MACHINE\BCD0000.
The BCD is stored in windows registry format and can be edited using bcedit.exe, it can also be edited using the registry editor since it is loaded in to the registry, and it can also be edited using Windows Management Instrumentation or some other third party tool.

Note: If you have multiple operating systems installed or you wish to keep two different versions of Windows on your system then you are presented with a menu of installed operating systems to choose from. This menu is presented to you by bootmgr.

9-      If the system was in hibernation or sleep then bootmgr passes control to WINRESUME.EXE.

10-   WINRESUME.EXE, as its name implies, resumes Windows to the state it was in before going in to hibernation.

Note: The two main points of entry into the windows vista bootstrap is the Windows Loader (WINLOAD.exe) or the Windows Resume Loader (WINRESUME.exe). Both branches will be discussed in this article.

11-   If the machine was not in hibernation the control from BOOTMGR will be passed to WINLOAD.exe

12-   It is important to note here that with Winresume.exe and Winload.exe we have entered the realm of windows exe files. This is also the part where the boot process branches off based on a decision on whether the boot process is after a shutdown or a hibernation.
Loading one of winload.exe or winresume.exe is the primary purpose of the Windows Boot Manager a.k.a bootmgr(.exe).

13-   We will first go down the path of WINLOAD.EXE. WINLOAD.EXE implements what was previously a function of NTLDR. The WINLOAD.EXE does the following:

a.       Loads boot-class drivers, these are drivers needed at startup time. If these drivers are not loaded at this time errors like : “Inaccessible boot device”, “Setup could not determine your machine type” or “Setup could not find any hard drives in your computer” could be faced.

b.      Loads dependencies for the kernel.

c.       Loads HAL.DLL (discussed below)

d.      The kernel of the Microsoft Windows namely, NTOSKERNEL.EXE

e.      Loads the SYSTEM registry hive.

f.        Loads ‘boot’ class device drivers and kernel-mode dll’s imported by hal.dll

HAL.DLL: The hardware abstraction layer, in through hal.dll, provides a standard interface for entities outside of HAL. The object that uses hal.dll does not need to be aware of the internal implementation of the driver.  The value that hal.dll provides to the system is that the client objects that use hal.dll do not need to be concerned whether this version of windows is 32 bit or 64 bit.
Since HAL is loaded into kernel address and runs in kernel address space, its functions cannot be called by applications directly, they can only be called by the kernel and kernel mode device drivers. For example: The PCI kernel device drivers directly call the routines in hal.dll to access the I/O ports associated with the devices attached to the PCI.
HAL.DLL is a kernel mode dll that interfaces between ntoskrnl.exe and the drivers to the hardware, it also behaves as a device driver for the motherboard and it’s components that are not managed by a specific device driver.
If hal.dll is not found at this moment it clearly gives an error about the missing file.
The hal.dll has a counterpart in the linux/unix world known as the hal daemon, they both have the same name because of the same functionality of hardware abstract layering. The hardware abstraction layer allows generic read/write i.e. simpler function calls, to the hardware, possible. hal.dll is located in the C:\Windows\system32 folder.

NTOSKERNEL.EXE: NTOSKERNEL stands for NT Operating System Kernel, and it is exactly that, the Windows Kernel. The Windows Kernel

NTOSKRNL.EXE, the core file of the kernel-mode component of Windows NT, contains the Cache Manager, the Executive, the Kernel, the Security Reference Monitor, the Memory Manager, and the Scheduler, among other things, and is in charge of getting NT up and running. You may be surprised to know that it has a standard main(), like normal programs built in C, that is executed when it is loaded by the OSLOADER (WINLOAD.EXE):

// // NTOSKRNL main // int main( boot parameters ) {  //  // Fire up NT!  // KiSystemStartup(); return 0; }

The WINDOWS REGISTRY Initialization

The Windows Registry is a database that stores configuration settings and options on Windows. It contains settings for low-level operating system components and for applications running on the platform that have opted to use the registry.  The Registry is stored in binary format under C:\Windows\system32\config. Some of the components of the registry and their physical location are given below:

Windows Location	Registry Key
C:\Windows\system32\config \SAM	HKEY_LOCAL_MACHINE\SAM
C:\Windows\system32\config \SECURITY	HKEY_LOCAL_MACHINE\SECURITY
C:\Windows\system32\config \SOFTWARE	HKEY_LOCAL_MACHINE\SOFTWARE
C:\Windows\system32\config \SYSTEM	HKEY_LOCAL_MACHINE\SYSTEM
C:\Windows\system32\config \DEFAULT	HKEY_USERS\.DEFAULT

The content under HKEY_USERS/<User_ID> is loaded from the c:\Users folder.

14-   The next step is to check for which services need to be started with the startup. This information is stored in the registry under HKEY_LOCAL_MACHINE\SYSTEM\services key. It starts the device drivers that need to be started at boot time, i.e. are in the SERVICE_BOOT_START class.

15-   The paging system is enabled for which the pagefile.sys (C:\pagefile.sys –default location) is used. Explanation of ‘paging’ is beyond the scope of this article.

16-   WINLOAD then passes control to the NTOSKRNL.EXE (discussed above). The kernel initialization itself is quite a detailed process, and sets the environment for the operating system to run. The ntoskrnl.exe when initializing does the following tasks:

a.       Prepares CPU registers for the execution of the ntoskrnl.exe

b.      Initializes executive subsystems which includes: the configuration manager, the process manager, security Reference monitor, I/O manager, PnP manager, power manger, WMI, cache manager, memory manager and logical prefetcher and Super fetch subsystems.

c.       Initializes system-start drivers

d.      Prepares the system for running native applications

e.      Launches smss.exe.

17-   Winresume.exe, which is another branch of this process as shown in the figure Fig1 uses the hiberfil.sys.

18-   The registry is in the c:\windows\system32\config folder

19-   Drivers are in the c:\system32\drivers folder

20-   The process manager creates a process object and names it Idle (The System Idle process). For details on System Idle processes visit this page: http://securityinternals.blogspot.ae/2013/12/what-are-system-idle-processes.html

21-   NTOSKRNL.exe then launches the smss.exe which is the session manager.

22-   Smss.exe calls the configuration manager executive subsystem to finish initializing the registry.

23-   Smss.exe create one session, by default, session 0 and then calls client server runtime subsystem (crss.exe).
At this point the kernel mode part of the Windows subsystem (Win32k.sys) and changes the screen to the resolution chosen for the system.

24-   Smss.exe also launches the graphical UI. As soon as smss.exe is successful in launching the GUI the status bar at login time I displayed.

25-   The first session created has its own smss.exe spawned with it. The initialization of session 0 is different from all other sessions (for details on Session 0 isolation visit this page: http://securityinternals.blogspot.ae/2014/02/windows-session-0-isolation.html ), as session 0 initiates Wininit.exe whereas all other following smss instances run the Winlogon.exe.

26-   Wininit.exe creates its initial window station and desktop objects and also the Session 0 windows hook which is used by the interactive Services Detection Service (UI0Detect.exe). The UI0Detect service looks for visible windows on the main desktop of the WinSta0 window station of session 0 and displays a notification dialog box on the console user’s desktop.

Note that UI0Detect is only there for backward compatibility and after Vista onwards the session 0 is isolated and applications cannot operate in an environment where they could use hooks to access services as it used to be done in times of Windows XP.

27-   Wininit.exe then creates the session control manager (SCM) C:\Windows\system32\services.exe which loads all services and device drivers marked for auto-start.

28-   Services are loaded either from their executable .exe file or the service’s .dll is loaded in to C:\Windows\system32\svchost.exe. That is the reason why there are multiple entries for the svchost when we look at process using process explorer.

29-   Winint.exe also starts the Local session manager C:\Windows\system32\lsm.exe

30-   Wininit.exe also starts the Local Security Authority Subsystem (LSASS) C:\Windows\System32\lsass.exe

31-   On session 1 and beyond, Winlogon runs instead of wininit.exe. Wininit.exe runs on Session 0 only.

32-   Winlogon.exe loads the registered credential provider (password-based by default) into LogonUI – C:\Windows\system32\logonui.exe

33-   LogonUI presents the log on screen to the user, where the user enters credentials.

34-   The credentials are authenticated by LSASS and the security subsystem provides the user with an access token (for details on access control related data structures visit this page: http://securityinternals.blogspot.ae/2014/01/access-control-structures-in-windows.html )

35-   If the user authentication was successful Winlogon.exe then executes userinit.exe. Userinit.exe applies group policy settings and startup and policy setting.

36-   After that winlogon.exe spawns explorer.exe with the signed in user’s access token. Explorer.exe is the shell which the user is presented with.

Updating this document

If you find that any step needs to be changed or added in the above bootup procedure, please leave a comment and it will be addressed. This article will continue to be tweaked and more detail will be added.

About the Author: Saquib Farooq Malik, is a senior Information Security Specialist . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.