Post

From Power Button to Application: How a Computer Boots and Runs Programs

Discover what happens inside a computer from power-on to running apps: BIOS/UEFI, bootloader, kernel, processes, and security insights.

Posted
By Zyad Elsayed
6 min read
From Power Button to Application: How a Computer Boots and Runs Programs

بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيم

Understanding what happens from the moment you press the power button until you finally launch an application is crucial for system engineers, penetration testers, and cybersecurity professionals. This journey spans hardware initialization, firmware checks, kernel loading, authentication, and process execution.

Let’s break it down step by step.

1. Hardware & Firmware (Power On & POST)

  • When you press the power button, the Power Supply Unit (PSU) delivers the required voltages (3.3V, 5V, 12V) to the system components.

  • The CPU starts execution from a fixed address in the firmware, called the reset vector which is stored in the rom.

    When a CPU powers on, it doesn’t just “guess” where to start — it always begins execution from a special hard-wired memory location called the reset vector. This ensures a predictable entry point for the firmware (BIOS/UEFI or equivalent).

    Different processor families place this vector at different addresses:

    • x86 (Intel/AMD):

      • 8086: 0xFFFF0 (16 bytes below 1 MB).
      • 80286: 0xFFFFF0 (16 bytes below 16 MB).
      • 80386 and later: 0xFFFFFFF0 (16 bytes below 4 GB).
    • ARM: Typically 0x00000000 (some allow relocation to 0xFFFF0000).
    • MIPS: 0xBFC00000 in the non-cacheable region.
    • PowerPC: 0x00000100 (32-bit) or 0x0000000000000100 (64-bit).
    • Motorola 68000: Vector table begins at 0x00000000, with the reset vector stored at the first entry.

    • 8-bit families:

      • 6502: stored at 0xFFFC–0xFFFD.
      • 8051 / Z80: execution starts at 0x0000.
      • PIC / AVR: reset at 0x0000 (often a jump to main routine).

  • The firmware (BIOS or UEFI) runs the Power-On Self Test (POST):

    • Checks RAM availability and functionality.
    • Detects and initializes essential hardware (keyboard, GPU, chipset, PCI devices).
    • With UEFI, additional drivers can be loaded, and Secure Boot ensures only trusted bootloaders are executed.

If hardware errors are found, the system emits beep codes or displays diagnostic messages.

Security Note: At this stage, an attacker could target the firmware with malicious implants.

2. BIOS/UEFI & Boot Loader

  • Once POST is complete, BIOS/UEFI searches for a bootable device (HDD, SSD, USB, or network).
  • It reads the boot sector (MBR) or the EFI System Partition.

  • The bootloader (e.g., GRUB on Linux, Windows Boot Manager) is executed.

    • It allows OS selection and kernel version choice.

Security Note: Attackers may use bootkits or Evil Maid attacks at this stage to hijack the boot process.

BIOS vs. UEFI

Both BIOS and UEFI serve the same fundamental role: initializing hardware and passing control to the OS bootloader. Many UEFI systems include CSM, which allows legacy BIOS booting (MBR).

  • BIOS (Basic Input/Output System):
    • Legacy Technology: BIOS is an older standard, limited to 16-bit mode. It can only address 1MB of RAM, so it needs to transition to protected mode to load a modern 64-bit OS.
    • MBR (Master Boot Record): It relies on the MBR, which is limited to 2TB disks and supports a maximum of four primary partitions. The MBR contains the bootloader code.
    • Lack of Advanced Features: BIOS lacks native support for mouse input, network capabilities, and advanced security features like Secure Boot.
    • Legacy BIOS malware often modifies the MBR/VBR (bootkits) – e.g., TDL4, Mebroot. Detection and cleanup is possible by rewriting the MBR.
  • UEFI (Unified Extensible Firmware Interface):
    • Modern Successor: UEFI is a modern firmware interface that operates in 32-bit or 64-bit mode. It supports larger disks and has a more flexible, modular design.
    • GPT (GUID Partition Table): It uses the GPT, which supports disks larger than 2TB and an unlimited number of partitions. The bootloader is a file stored on the EFI System Partition (ESP).
    • Enhanced Security: UEFI provides Secure Boot, a feature that prevents the loading of unsigned or malicious bootloaders and operating systems by checking their digital signatures. This is a crucial security point that deserves its own sub-section.
      • But attackers sometimes exploit misconfigurations (e.g., admins disabling Secure Boot for dual boot/testing).
    • Measured Boot + TPM: UEFI can use a TPM chip to measure each boot stage and report integrity to security software (important in enterprise environments).
    • Fast Startup: It can significantly speed up the boot process.
    • More modern malware can implant in the firmware (e.g., LoJax UEFI rootkit). These are much stealthier, survive OS reinstallation and disk replacement, and require reflashing firmware to remove.

3. Kernel Loading

  • The bootloader loads the Operating System kernel into RAM.

  • The kernel initializes:

    • Memory management (paging, virtual memory).
    • Process scheduler.
    • Device drivers for disk, graphics, and networking.
  • Finally, the kernel mounts the root filesystem, giving the OS access to storage.

Security Note: Vulnerabilities in kernel drivers can lead to rootkits or kernel-level exploits.

4. User Space & System Processes

Once the kernel is running:

  • The first process (PID 1) is created:

    • Linux: init or systemd.
    • Windows: smss.exe (Session Manager).

  • These core processes spawn others:

    • Linux: systemd launches target units (network, logging, GUI).

    • Windows: smss.exe → csrss.exe + wininit.exe → services.exe, lsass.exe.

Note: lsass.exe (Local Security Authority Subsystem Service) is critical—it stores credentials in memory, making it a high-value attack target.

5. User Login & Session

  • At the login screen, the user provides credentials.

  • Authentication occurs:

    • Windows: LSASS validates credentials locally or against a Domain Controller using Kerberos/NTLM.

      Windows processes user/service credentials during authentication using credential providers, LSA (Local Security Authority), and protocols like Kerberos or NTLM. Credential data is either locally validated (via SAM) or domain-validated (via Active Directory).

    • Linux: PAM (Pluggable Authentication Modules) handles verification.

  • A user session is created, loading the user’s profile and startup applications.

6. Application Execution

When you launch an application:

  1. The OS initiates process creation:

    • Linux: execve() system call.
    • Windows: CreateProcess().

  2. The program is loaded into RAM:

    • Code, data, and required libraries (DLLs or shared objects).
  3. The CPU executes instructions, managed by the scheduler.
  4. System calls allow the application to interact with files, memory, or the network via the kernel.

Security Perspective: Attack Surfaces Along the Way

Each stage of the boot-to-application journey represents a potential attack vector:

  • Firmware (BIOS/UEFI): Firmware rootkits, malicious implants.
  • Bootloader: Bootkits, Evil Maid attacks.
  • Kernel: Kernel exploits, rootkits.
  • System Processes: LSASS credential dumping, persistence via services.
  • Applications: Exploits, privilege escalation, malware injection.

Conclusion

When I press the power button, the power supply signals the CPU, which begins execution from the BIOS/UEFI. The BIOS performs the POST, initializes hardware, and then loads the bootloader from disk. The bootloader places the operating system kernel into RAM. The kernel activates memory management, loads drivers, and launches the very first process—such as systemd on Linux or smss.exe on Windows. From there, other essential services are started, including lsass.exe on Windows, which is responsible for handling credentials. Once I log in, a user session is created and startup programs are launched. Finally, when I open any application, the OS creates a new process, maps the code and necessary DLLs into memory, and the CPU executes the instructions.

A lot happens behind the scenes. This multi-layered process—spanning hardware, firmware, kernel, system processes, authentication, and application execution—is not only fascinating but also critical for security professionals to understand.

For penetration testers, each step is a potential attack surface. Recognizing these layers enables better defense strategies, detection of malicious activity, and stronger system hardening.

Fundamentals, Operating Systems
Linux Windows Operating Systems Boot Process Kernel BIOS UEFI System Internals Security
This post is licensed under CC BY 4.0 by the author.