Processes, Services & Packages

To understand a machine you map two things: what is running, and where that software came from. Both are quick to check from the terminal, and both matter to a tester, running services are attack surface, and out-of-date packages are vulnerabilities.

Processes: what is running

A process is a running program. Each has a PID (process id), an owner (user), and a parent.

ps              # your shell's processes
ps aux          # EVERY process: USER, PID, %CPU, %MEM, COMMAND
top             # live, sorted by CPU (q to quit) , htop is the prettier version
ps aux | grep nginx   # is a specific service running?

In ps aux the columns you care about: USER (who it runs as, root is interesting), PID (to act on it), %MEM/%CPU, and COMMAND.

Services and systemd

A service (or daemon) is a long-running background process, the SSH server (sshd), the web server (nginx), the database (mysqld). On modern Linux they are managed by systemd, the init system. systemd is PID 1: the first process the kernel starts, and the ancestor of every other process.

systemd describes each service as a unit (a .service file). You control them with systemctl:

systemctl status ssh       # is it running? since when? what PID?
systemctl list-units       # everything systemd is managing
systemctl start  nginx     # start now
systemctl enable nginx     # start automatically at boot
journalctl -u ssh          # that service's logs

The boot-to-login chain

When you press the power button, the machine is just electrified silicon, no operating system, nothing running. Booting is the chain of hand-offs that turns that cold hardware into a working system with a login prompt. ("Boot" is short for bootstrap, as in "pull yourself up by your bootstraps", each stage loads the slightly bigger, smarter thing that runs next.)

Walk it one hand-off at a time:

1. Firmware (UEFI or BIOS). A tiny program baked into a chip on the motherboard. The instant there's power it runs POST (Power-On Self-Test, checking RAM, CPU, disks), then goes looking for a disk to boot from. Firmware comes in two eras: old BIOS and modern UEFI (which added Secure Boot, huge-disk support, and a friendlier interface). Firmware is the only thing that runs before an operating system exists.
2. The partition table (GPT or MBR). To boot, firmware must find the bootloader on the disk, and to make sense of a disk it reads the partition table: the map at the very start of the disk that says where each partition begins and ends. There are two formats, MBR and GPT (next section), and which one you have decides how the disk is laid out and how it boots.
3. Bootloader (GRUB). A small program the firmware loads from the disk. Its whole job is to find the kernel, load it (plus a tiny temporary filesystem called initramfs) into RAM, and jump into it. On Linux this is almost always GRUB, and it's where you'd pick between multiple kernels or boot into recovery mode.
4. The kernel. The core of the OS. It initialises the real hardware with proper drivers, mounts the actual root filesystem (/), and then starts the very first user-space process.
5. init — systemd (PID 1). That first process is the init system, on modern Linux, systemd, and it always gets PID 1. It brings up every configured service and drives the system to a target (a state like multi-user for a server or graphical for a desktop). Every other process descends from it.
6. Login. systemd starts a login prompt, a text getty on a server or a graphical display manager on a desktop. You type your credentials, and the shell it hands you is, ultimately, a child of PID 1.

Why a tester cares. Anyone who controls an early stage controls everything above it. Physical access to the firmware or GRUB often means booting from a USB stick or editing the GRUB line to spawn a root shell and reset the root password, no login required. That's why hardened machines set a BIOS/UEFI password, a GRUB password, and Secure Boot, to stop an attacker from hijacking the chain before Linux even loads.

MBR vs GPT: how a disk is partitioned

Step 2 mentioned the partition table. It's worth understanding properly, because it decides how the disk is structured, how big it can be, and how it boots. A raw disk is just a long line of numbered sectors; the partition table at the front records how that space is carved into partitions. Two schemes exist.

MBR — Master Boot Record (the legacy scheme)

MBR has been around since the early 1980s and lives in the very first 512-byte sector of the disk. That single sector holds three things:

• Boot code (446 bytes) , a scrap of program the BIOS runs first. It's just big enough to find an active partition and chain-load the real bootloader (GRUB's first stage lives here).
• Partition table (64 bytes) , room for exactly four entries, each describing one partition (start, size, type, active flag). This is why classic MBR disks are limited to 4 primary partitions. The workaround is to make one an extended partition that holds many logical partitions inside it.
• Boot signature (2 bytes) , the fixed magic number 0x55AA that tells firmware "yes, this is a valid boot sector."

MBR's limits are the reason it's fading out: addresses are 32-bit, so it can't use a disk larger than 2 TB, and there's only one copy, corrupt those 512 bytes and the whole disk becomes unbootable. MBR pairs with BIOS firmware.

GPT — GUID Partition Table (the modern scheme)

GPT is part of the UEFI standard and fixes almost every MBR limitation. Instead of cramming everything into one sector, it spreads a proper structure across the start (and end) of the disk:

• Protective MBR (LBA 0) , a fake old-style MBR in sector 0 whose only purpose is to stop legacy tools from seeing the disk as "empty" and overwriting it.
• Primary GPT header (LBA 1) , records the disk's unique GUID, where the partition entries are, and CRC checksums so corruption is detectable.
• Partition entries (LBA 2–33) , room for 128 partitions by default, each with its own GUID and a proper name, no primary/extended/logical hack needed.
• Backup GPT (last sectors) , a full second copy of the header and entries at the end of the disk. If the primary is damaged, the system repairs it from the backup. MBR has nothing like this.

GPT uses 64-bit addressing, so it handles disks up to roughly 9.4 zettabytes (effectively unlimited). It pairs with UEFI firmware, and UEFI boots differently: instead of running boot code from sector 0, it reads the bootloader as a file from a small FAT partition called the EFI System Partition (ESP), usually mounted at /boot/efi.

Which one am I on?

sudo parted -l              # prints "Partition Table: gpt" or "msdos" (= MBR)
sudo gdisk -l /dev/sda      # GPT-aware; shows the full layout
ls /sys/firmware/efi        # exists ⇒ you booted via UEFI (so almost certainly GPT)
lsblk                       # the tree of disks and partitions

Rule of thumb: BIOS + MBR is the old pairing; UEFI + GPT is what modern machines use. On a real box, checking the scheme (and whether /sys/firmware/efi exists) tells you at a glance how modern the system is and how it boots.

Where software comes from

You rarely download installers on Linux. Software comes from package managers pulling signed packages from repositories:

• apt , Debian and Ubuntu. Sources live in /etc/apt/sources.list.
• dnf (older: yum) , Fedora and RHEL.

apt update                 # refresh the index of what's available (NOT install)
apt upgrade                # install the newer versions
apt install nginx          # install a package and its dependencies
apt list --installed       # what's already here

apt update only refreshes the list; apt upgrade actually installs the updates. Keeping packages current is the single most important defence against known exploits, an unpatched service is the easiest way in.

Try it (terminal)

1. ps aux , scan the USER and COMMAND columns. Who runs nginx? mysqld?
2. systemctl status ssh and systemctl list-units , the map of running services.
3. apt update , watch it refresh the index (it doesn't install anything).
4. free and uname -a , memory and kernel version (the kernel version hints at patch level).

Why this matters

ps aux plus systemctl list-units is your map of what is running and why, the services a tester probes. The package manager and kernel version tell you how current the box is, which is often where the way in hides.