Study guide
14.4 USB Persistence with LUKS Encryption
Kali Linux Certified Professional KLCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path
2 About Kali Linux
2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies
3 Getting Started with Kali Linux
3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations
4 Linux Fundamentals
4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment
5 Permissions and Process Management
5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment
6 Installing Kali Linux
6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations
7 Configuring the Network, Users, and SSH
7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH
8 Configuring Services
8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd
9 Helping Yourself and Getting Help
9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports
10 Security Policy and Network Services
10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services
11 Firewalling and Monitoring
11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging
12 Debian Package Management: APT
12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt
13 dpkg and Advanced Package Management
13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity
14 Advanced Usage
14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption
15 Kali Linux in the Enterprise
15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking
16 Introduction to Security Assessments
16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead
14.4 USB Persistence with LUKS Encryption
Key Takeaways Explain This Topic AI
Write the live ISO to USB with dd, then create a persistence partition in the remaining free space
A persistence store is activated by a persistence.conf file at the filesystem root containing the single line '/ union'
Encrypted persistence wraps the partition with cryptsetup luksFormat and luksOpen before creating the ext4 filesystem
A single USB drive can carry multiple persistence stores — for example an unencrypted work store and a LUKS-encrypted store — selected at boot
Kali's cryptsetup-nuke-password package adds a nuke password, set with dpkg-reconfigure cryptsetup-nuke-password: a special passphrase that destroys the LUKS keyslots instead of unlocking the device
Last updated: July 2026
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:
luksFormat initializes the partition as a LUKS container and sets the unlock passphrase — this destroys existing data on the partition
luksOpen decrypts the container and maps it to /dev/mapper/my_usb, and all subsequent operations target that mapped device, not the raw partition
- The ext4 filesystem and persistence.conf go inside the encrypted container
- 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