Encrypted Persistence on a Kali Live USB: A Minimal Architecture

You need Kali on hardware you don't control: a client's loaner laptop, a lab machine, a training room box. Installing is off the table, and a plain live USB forgets everything at reboot — scan results, shell history, the report you were halfway through writing. The smallest design that fixes both problems is one USB drive with two personalities: the read-only live image on one partition, and a LUKS-encrypted partition labeled persistence that the live boot merges over the root filesystem at startup. LUKS (Linux Unified Key Setup) is the standard Linux full-partition encryption format, managed with cryptsetup.

This note covers what that design does and doesn't protect, the commands to build it, the checks to run before you trust it, and the points at which you should switch to a full install or a VM instead.

What the design has to satisfy

• No host-disk footprint. Nothing installed, nothing written to the borrowed machine's drives.
• State survives reboots. Tool output, shell history, notes and reports persist across power cycles.
• Loss is survivable. If the stick is lost or seized, its contents are unreadable without the passphrase.
• Runs on unprepared hardware. Boots from the USB port on machines you didn't set up.

If you need long-lived services, kernel updates, or multi-week state, stop here — that is a different design, covered at the end.

The smallest suitable design

A Kali live image runs from a read-only squashfs — a compressed, immutable filesystem image. The persistence trick adds a second partition that the boot system unlocks and merges over that read-only root with overlayfs, so writes land on the encrypted volume while the base system stays exactly as the ISO built it. One drive, two partitions, one config file.

Write the official live ISO to the whole device. Run this from any Linux host with sudo; dd overwrites the target without further prompting, so confirm the device by size with lsblk first, not by its position in the list:

lsblk -o NAME,SIZE,TYPE,LABEL,MOUNTPOINT
sudo dd if=kali-linux-<release>-live-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync

Then boot the stick (or work from another Linux host), create one new partition in the free space after the image — accept the default start sector and extend to the end of the drive — and format it as LUKS. On current images the new partition is usually /dev/sdX3, but confirm the number with lsblk before formatting, because luksFormat destroys its target:

sudo fdisk /dev/sdX                      # n) new partition in free space, w) write
sudo cryptsetup luksFormat /dev/sdX3     # type uppercase YES, set a long passphrase
sudo cryptsetup open /dev/sdX3 kali-persist
lsblk                                    # /dev/mapper/kali-persist should now exist

sudo mkfs.ext4 -L persistence /dev/mapper/kali-persist
sudo mount /dev/mapper/kali-persist /mnt/kali-persist
echo '/ union' | sudo tee /mnt/kali-persist/persistence.conf
sudo umount /mnt/kali-persist
sudo cryptsetup close kali-persist

Two details silently disable persistence if you get them wrong: the filesystem label must be exactly persistence (lowercase — the boot scripts match on it), and persistence.conf must sit at the root of that filesystem containing the single line / union, which means "overlay the entire root filesystem."

Reboot, pick the persistence entry in the live boot menu (wording varies by release), and enter the passphrase. From then on, everything you write — home directory, /etc edits, tool caches — lands on the encrypted partition.

Why LUKS instead of per-file encryption

You could encrypt individual folders with something like gocryptfs or a VeraCrypt container, but every tool that writes state — shells, browsers, scanners, report templates — would need its own configuration, and something would be missed. LUKS draws one boundary around the whole partition: caches, history, temp files and reports are covered by default. The cost is concentration. One passphrase and one flash device now carry everything, so passphrase length and backup discipline matter more, not less.

Trust and data boundaries

The design treats the host as untrusted, and it is worth being precise about what that means:

• Protected: data at rest on the persistence partition. Lose the stick and its contents stay unreadable without the passphrase.
• Not protected: your keystrokes and screen on the host. The passphrase is typed on the borrowed machine's keyboard; a keylogger or compromised firmware sees it.
• Not protected: the decrypted data while the system is running. Once unlocked, a compromised host can read everything the overlay exposes.
• Not protected: network traffic. Nothing here touches VPN or transport encryption.

The encryption protects data, not authorization — running offensive tooling against systems you lack written permission to test is a legal problem no partition scheme solves.

Operational checks before you rely on it

1. Confirm the boot menu actually offers a persistence entry on your hardware. With Secure Boot enabled, the live bootloader may be refused; Kali's Secure Boot handling has changed across releases, so check the current documentation or disable Secure Boot for the test.
2. Verify the LUKS header on the intended partition: sudo cryptsetup luksDump /dev/sdX3 should print header metadata (version, cipher, keyslots). An error means you are pointing at the wrong thing.
3. Run a write-reboot-read test before field use:

   echo "persist-check $(date -u +%FT%TZ)" > ~/marker.txt
   sync && sudo reboot
   # boot the same stick, choose the persistence entry, unlock:
   cat ~/marker.txt
   findmnt /                        # expect an overlay-style root
   mount | grep -i persistence      # encrypted partition should be mounted

4. Record what you built: the Kali release and ISO build date, plus the luksDump output (LUKS version and cipher). cryptsetup defaults differ between releases, and you will want those parameters if the volume ever needs recovery elsewhere.

The mount point path for the persistence partition differs between releases, so look for the device and the overlay root rather than one specific directory in the output.

Failure modes and first checks

Symptom	Likely cause	First check
No persistence entry in the boot menu	Wrong image variant, or menu wording changed in your release	Re-image from the official live ISO; check current docs for the entry name
Passphrase prompt appears, but changes vanish after reboot	persistence.conf missing, misplaced or misspelled; label not exactly persistence	Unlock and mount the partition; confirm / union at its root and the label in lsblk
cryptsetup errors on the partition	Wrong device, or no LUKS header present	luksDump on the intended partition; re-check lsblk sizes
Stick never boots at all	Secure Boot or unusual firmware rejecting the bootloader	Try the release's documented Secure Boot path, or disable it in firmware
Everything is painfully slow	USB 2.0 port or slow flash media	USB 3 drive and port; expect flash wear to accumulate over repeated writes
Stick lost or dead	Single device carrying everything	Copy engagement data elsewhere once authorized; treat the stick as disposable, the data as not

When to change the design

• You need kernel or driver updates. The live kernel comes from the ISO; persistence holds data and most package state, but a full upgrade on a live stick will not give you a new kernel and can break boot. Move to a full install on dedicated hardware.
• The engagement runs for weeks, or needs long-lived services and snapshots. A Kali VM with encrypted disks handles state better than any removable media.
• One stick is shared between operators. Build separate encrypted volumes per operator rather than a shared overlay.
• The mission outgrows the medium. Flash wear and a single device make this a short-mission pattern, not a workstation.

Even in its sweet spot, live persistence is not a backup. Copy reports and evidence off the stick once you are authorized to move them — the LUKS volume protects against loss of the drive, not against the drive dying.

Version assumptions

This follows Kali's documented live-USB-with-encrypted-persistence workflow on its rolling release; boot menu wording, Secure Boot behavior and cryptsetup defaults shift between releases. Before field use, re-check the steps against the current official documentation and re-run the marker test after any ISO update — the design is only as good as its last verified boot.