3.2 Booting Kali in Live Mode

Booting Kali in Live Mode

Writing a Kali ISO to a USB stick (with balenaEtcher, Rufus in DD mode, or dd) gives you a portable Kali system. Boot from it and the live boot menu appears. The exam expects you to know each menu entry and, more importantly, what each one guarantees about the host machine.

The live boot menu entries

• Live system (amd64) — the default. Kali loads the kernel, mounts a compressed read-only root filesystem (squashfs) directly from the boot medium, unions it with a copy-on-write overlay in RAM, and boots the full Xfce desktop without touching the host's internal disks.
• Live system (amd64 fail-safe mode) — the same live system booted with conservative kernel parameters that disable problematic features (options like noapic, noapm, nodma, and nomodeset) for hardware that hangs, crashes, or shows a black screen under the normal entry.
• Live system (forensic mode) — a hardened live session for incident-response and forensic work; detailed below.
• Live system with USB persistence and Live system with USB encrypted persistence — live sessions that read and write a persistence partition on the USB device so your changes survive reboots.
• Start installer / Start installer with speech synthesis — launch the Debian-based installer to put Kali onto a hard disk. (The installer-only ISO instead shows Graphical install / Install at the top level.)
• Advanced install options — a submenu holding the graphical, text, expert, automated and rescue installer modes.
• Utilities — a separate submenu holding memtest and the hardware detection tool (HDT).

What plain live mode does (and does not do)

In standard live mode the running system is assembled in memory: the read-only squashfs from the USB stick is layered with a copy-on-write overlay in RAM. Two consequences follow. First, the host's internal drives are left alone — you can poke a suspect machine, a friend's laptop, or a lab box without installing anything. Second, everything you change is discarded at shutdown: installed packages, saved files, browser history, all of it lives only in the RAM overlay. Log in with the default live credentials, user kali with password kali, and treat the session as disposable.

Forensic mode: guarantees and why they matter

Live (forensic mode) exists for one reason: when you examine a machine during an investigation, your own tooling must not contaminate the evidence. Merely mounting a filesystem read-write — or even read-only with certain options — can update metadata; letting the kernel activate a swap partition overwrites whatever sensitive data (passwords, keys, fragments of deleted files) happened to be swapped out there. Forensic mode therefore makes three concrete guarantees:

1. Swap is never used — the kernel will not activate any swap partition it finds, so existing swap contents are preserved.
2. Internal drives are not auto-mounted — Kali's automounter is effectively disabled, so nothing on the host's disks is touched unless you deliberately mount it yourself, and you would mount it read-only (for example mount -o ro /dev/sda1 /mnt/evidence).
3. Removable media is not auto-mounted either — USB sticks, CDs and the like are ignored on insertion; nothing happens to any medium without direct user action.

This matters because forensic soundness is about being able to say, under scrutiny, that your examination did not alter the original evidence. Timestamps, unallocated space, and swap artifacts are exactly what an opposing analyst checks. If your job is to image or triage a drive, boot forensic mode; if you then need Kali's full write access for analysis, work on a forensic copy, never the original.

A classic exam trap: forensic mode is not a privacy or anonymity mode, and it is not persistence. It changes how the host's storage is treated, nothing more. Similarly, do not confuse forensic mode with fail-safe mode — fail-safe is about uncooperative hardware, forensic is about protecting data.

USB persistence

Standard live mode forgets everything at reboot, which is frustrating if you update tools, save wordlists, or customize your environment. Live USB persistence solves this: you partition the USB stick so that, alongside the live image, there is a partition labeled persistence containing a persistence.conf file, and the boot menu's persistence entries mount it as the writable overlay. Files you save, packages you install with apt, and configuration changes are written to that partition and restored on the next boot. The encrypted persistence variant stores the overlay inside a LUKS (Linux Unified Key Setup) encrypted container, so a lost USB stick does not leak your engagement notes, credentials, or client data — the obvious choice for real-world work.

Remember the boundary: persistence still runs Kali from the USB stick with live-mode performance characteristics. It is not a full disk installation, and the boot menu's installer entries remain the right path when you want Kali permanently on a machine.

Quick reference: which entry for which job

One last practical note: live mode is also the best pre-install test. Boot the live entry on the target machine and confirm that Wi-Fi, audio, display, and suspend all work; if something fails live, it will fail installed, and you can research the fix before committing to repartitioning. The Utilities menu's hardware detection tool (HDT) helps inventory exactly which chipsets you are dealing with.