14.3 Building Custom Kali Live ISO Images

The live-build Toolchain

Kali's official ISOs — and any custom ISO you build — are produced by live-build, Debian's toolchain for assembling live systems. Kali is literally constructed this way: the distribution is 'built with live-build' from the same scripts you can download. live-build works by creating a chroot (an isolated filesystem tree), installing packages into it with APT, applying your customizations, and then compressing the result into a bootable ISO hybrid image.

The raw live-build commands are:

• lb config — generates the config/ tree describing the build (distribution, architecture, package lists, boot options)
• lb build — executes the build stages (bootstrap, chroot, binary, source) and must be run as root
• lb clean — resets build stages so you can iterate

You rarely call these directly on Kali, because Kali wraps them in its own build scripts, but the exam may ask which command does what: lb config configures, lb build builds.

The kali-live Build Scripts (formerly live-build-config)

Kali's official custom-ISO entry point is the kali-live project in Kali's build-scripts group on GitLab (it was called live-build-config in the Kali Linux Revealed book, and installer ISOs now come from a separate kali-installer repository):

sudo apt install -y git live-build cdebootstrap curl
git clone https://gitlab.com/kalilinux/build-scripts/kali-live.git
cd kali-live

The centerpiece is the build.sh wrapper script, which prepares a correct live-build configuration for a chosen variant and then invokes the build. Key facts about the environment:

• You must build on Kali — building on plain Debian or Ubuntu is not supported because package sets and keys differ
• The build runs as root (build.sh invokes sudo internally)
• You need substantial free disk space (tens of gigabytes) and a reliable network connection, since packages are downloaded fresh from the Kali mirror

A typical invocation selects a variant, which maps to a package list and desktop configuration:

./build.sh --variant default --verbose
./build.sh --variant light --verbose

Common variants include default (Xfce desktop with the standard toolset), light (a minimal image: kali-linux-core plus a desktop, with the tool metapackage omitted), and desktop-specific variants such as kde, gnome, or xfce. build.sh also supports options for architecture (--arch amd64 or arm64 style targets on suitable hosts), distribution, and verbose logging.

Variants and Package Lists

The variant system is layered on Kali's metapackages (from kali-meta, Section 14.1). The package list for a variant names the metapackage that defines the toolset:

Package lists live in the kali-live tree under kali-config/variant-*/package-lists/ as *.list.chroot files, one package or metapackage name per line. Adding your own line there is the simplest customization: it pulls the package (and its dependencies) into the live image from kali-rolling.

Customizing the Image: includes.chroot and Hooks

live-build offers two primary customization hooks inside the configuration tree, and you must be able to tell them apart:

includes.chroot — static files. Anything you place in an includes.chroot directory (for example kali-config/common/includes.chroot/) is copied verbatim into the live filesystem at the matching path. To pre-seed a configuration file, mirror the target path:

kali-config/common/includes.chroot/etc/ssh/sshd_config
kali-config/common/includes.chroot/opt/custom/banner.txt

Use this for dotfiles, pre-written configs, scripts you want on the desktop, wallpaper, or license files. No code runs — it is a pure file copy.

Hooks — executable scripts. Files ending in .chroot inside a hooks directory (for example kali-config/common/hooks/live/*.chroot) are executed inside the chroot during the build. Use hooks for changes that require running commands: enabling or disabling a systemd service, creating users, running update-ca-certificates, or compiling something small. Hooks ending in .binary run later, on the image-staging side. A hook must be executable and idempotent; a failing hook aborts the whole build.

The rule of thumb the exam tests: files to place → includes.chroot; commands to run → hooks.

Live Images vs Installer Images

A standard build produces a live ISO: it boots into a running Kali desktop without touching the disk, and it also carries an installer launched from the live session. Kali's build system can also produce installer images — classic Debian Installer images that boot straight into a text/graphical installer — and netinstaller variants that fetch most packages from the mirror at install time. In the kali-live tree this is controlled through build.sh options and variant configuration rather than by hand-editing live-build files. Know the distinction: live images are for portable, non-destructive use (and pair with USB persistence, Section 14.4); installer images are for permanent deployment.

Running the Build and Finding the Output

A full build walks live-build's stages — bootstrap the chroot, install package lists, run hooks, copy includes, build the squashfs, generate the ISO — and takes anywhere from half an hour to several hours depending on your machine, mirror speed, and variant size. Log output is verbose; --verbose on build.sh helps when a hook fails.

When the build completes, the resulting .iso file lands in the images/ subdirectory of the kali-live tree (for example images/kali-linux-rolling-live-amd64.iso; build.sh only adds a subdirectory if you pass --subdir). Verify the checksums, then write it to USB with dd exactly as you would an official image (Section 14.4) or boot it in a VM for testing.

Exam Traps Recap

• Building on a non-Kali host → unsupported; do it on Kali
• Confusing includes.chroot (file copy) with hooks (script execution)
• Thinking variants are arbitrary names — they map to package lists and metapackages like kali-linux-default
• Looking for the ISO in the build root → check the images/ directory
• Forgetting that lb build / build.sh need root and heavy disk and bandwidth