14.4 USB Persistence with LUKS Encryption

Live USBs Are Amnesic — Persistence Fixes That

A Kali live USB boots a fully working system, but by default nothing survives a reboot: your files, tool output, wordlists, and settings vanish. Persistence adds a dedicated partition that the live system overlays onto the filesystem at boot, so changes are written to disk and restored next time. This is one of the most exam-relevant 'advanced usage' topics because it combines partitioning, the live boot system, and disk encryption in one workflow.

Step 1: Write the Live Image with dd

Identify the USB device carefully (lsblk — writing to the wrong disk destroys it) and write the ISO to the whole disk device, not a partition:

sudo dd if=kali-linux-2026.2-live-amd64.iso of=/dev/sdb bs=4M status=progress conv=fsync

Key points about this command:

• of=/dev/sdb targets the disk itself (not /dev/sdb1) so the ISO's own partition table and bootloaders land intact
• bs=4M speeds the transfer with large blocks
• conv=fsync flushes writes before dd exits, so it is safe to remove the drive

The ISO is a hybrid image, so after dd the drive boots on both BIOS and UEFI systems. Crucially, the drive also has unallocated free space after the ISO's partitions — that is where persistence goes.

Step 2: Create the Persistence Partition

Boot the live USB (or work from another Linux machine) and create a new partition filling the remaining space, using fdisk, parted, or GParted. Then create an ext4 filesystem labeled persistence:

sudo mkfs.ext4 -L persistence /dev/sdb3

(Partition number depends on the ISO layout; check with lsblk. The label persistence is required, not decorative: live-boot scans every partition for a filesystem carrying that label — overridable with the persistence-label= boot parameter — and only then reads the persistence.conf at its root. Both the label and the file must be present.)

Step 3: persistence.conf — the Activation File

A partition becomes a persistence store only when its filesystem root contains a file named persistence.conf describing what to persist. The standard content is a single line:

mkdir -p /mnt/persistence
sudo mount /dev/sdb3 /mnt/persistence
echo '/ union' | sudo tee /mnt/persistence/persistence.conf
sudo umount /dev/sdb3

'/ union' means: mount this store as a union (overlay) over the entire root filesystem, so every change made during the live session — installed packages, saved files, config edits — is written through to the USB partition. Other mount-point lines are possible (for example persisting only /home), but / union is the standard and the expected exam answer. After creating the file, boot the USB and choose a Live USB Persistence entry from the boot menu; your changes now survive reboots.

LUKS-Encrypted Persistence

A plain persistence partition is readable by anyone who steals the drive — unacceptable when it holds engagement data, credentials, or client reports. Kali's answer is LUKS (Linux Unified Key Setup) encryption, applied to the partition before the filesystem is created. The sequence replaces Step 2:

sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb3
sudo cryptsetup luksOpen /dev/sdb3 my_usb
sudo mkfs.ext4 -L persistence /dev/mapper/my_usb
sudo mount /dev/mapper/my_usb /mnt/persistence
echo '/ union' | sudo tee /mnt/persistence/persistence.conf
sudo umount /mnt/persistence
sudo cryptsetup luksClose my_usb

Understand each stage:

1. luksFormat initializes the partition as a LUKS container and sets the unlock passphrase — this destroys existing data on the partition
2. luksOpen decrypts the container and maps it to /dev/mapper/my_usb, and all subsequent operations target that mapped device, not the raw partition
3. The ext4 filesystem and persistence.conf go inside the encrypted container
4. luksClose seals the container when finished

At boot, selecting an encrypted-persistence menu entry makes Kali's initramfs prompt for the passphrase, open the container, and apply the overlay. The workflow order matters and is a classic exam sequence question: luksFormat → luksOpen → mkfs → mount → persistence.conf.

Multiple Persistence Stores on One Drive

Kali's live boot supports more than one persistence store, and Kali Linux Revealed's canonical example is exactly that: an unencrypted 'demo' store for material you can show anyone, plus a LUKS-encrypted 'work' store for client data, on the same drive. Each store is its own partition (or LUKS container) with its own persistence.conf, and stores are told apart by their ext4 filesystem label, selected at boot with persistence-label=<label>. The two stock menu entries below both look for the label persistence, so a genuine two-store setup needs custom boot-menu entries added through a .binary hook at ISO-build time:

• Live system (no persistence)
• Live USB Persistence (plain store)
• Live USB Encrypted Persistence (LUKS store)

This lets you keep demo or promotional material in the fast plain demo store and reserve the encrypted work store for sensitive engagement data. persistence.conf files can also persist different subtrees, so stores can serve different purposes.

The Nuke Password

Kali ships a cryptsetup-nuke-password package that implements a nuke password. It does not patch cryptsetup itself: it diverts cryptsetup's early-boot askpass helper and stores a hash of the nuke passphrase (/etc/cryptsetup-nuke-password/password_hash) inside the initrd, so that entering it at the unlock prompt destroys all the LUKS keyslots instead of unlocking the device. With the keyslots gone, the encrypted data is unrecoverable even with the real passphrase — a duress feature for situations where you are compelled to unlock the drive. For the exam, know the concept and its Kali-specific nature: it is not a stock upstream cryptsetup feature, it does not erase the whole disk sector by sector, and it is configured with sudo apt install cryptsetup-nuke-password followed by sudo dpkg-reconfigure cryptsetup-nuke-password. It is a last-resort measure, not a substitute for a strong passphrase.

Common Traps Recap

• dd to /dev/sdb1 instead of /dev/sdb → unbootable stick
• Forgetting persistence.conf → the partition is never overlaid; the content must be exactly / union for full persistence
• Running mkfs.ext4 on the raw partition after luksFormat instead of on /dev/mapper/... → data sits outside the encryption
• Assuming persistence works with the plain 'Live' boot entry → you must select a persistence menu entry