Back to Home

Kali Linux: exercises on modifying packages, building the kernel and creating ISO images / RUVDS.com blog

administration · Linux · Kali Linux · package modification · kernel assembly · ISO image

Kali Linux: exercises for modifying packages, building the kernel, and creating ISO images

Original author: Collective of authors
  • Transfer
Today we publish a translation of the completion of the ninth chapter of the book “ Kali Linux Revealed ”. It will summarize topics such as modifying packages, building the kernel, and creating your own ISO images. In addition, here you will find exercises for this chapter, on which, we hope, it will be interesting to try your hand both for those who are already familiar with Kali, and those who have just started to master this distribution.

image

9.5. Summary


In this chapter, you learned how to modify source packages, which are the basic building blocks of all Kali applications. In addition, we talked about how to configure, build, and install your own Kali kernels. Next, we talked about the environment live-buildand how to create your own Kali ISOs. Also in this chapter we talked about preparing bootable flash media with support for persistent information storages, which can be either encrypted or unencrypted. Now we systematize the main provisions of this chapter and offer you a set of exercises.

9.5.1. Package modification


Modifications of Kali packages are usually done by developers, and those who are responsible for maintaining and developing the system, however, it may happen that you will not have enough opportunities provided by official package assemblies.

Therefore, knowing how to build a modified package can be very useful, especially if you want to share a new package with someone, deploy it on many machines, or, after installing a new package, return the system to its previous state without any problems.

When you need to modify a certain program, it is very tempting to download the source code, make changes to it and use this modified version. However, if the program needs to be installed, after which it is available throughout the system (that is, usingmake install), then such an installation will contaminate the file system with files unknown dpkg, which will soon lead to problems that cannot be identified based on analysis of package dependencies. In addition, with this approach to modifying packages, what happened is harder to share with other users.

When creating a modified package, the general sequence of actions always turns out to be the same: downloading the package with the source code, extracting its contents, making changes, and then building the package. There are many tools that can solve each of these problems.

In order to start rebuilding Kali packages, you first need to download the source package, which includes the main * .dsc file (Debian Source Control) and additional files that are referenced in the main file.

Source packages are stored on HTTP mirrors. The most efficient way to load them is to use a view command apt source source-package-name. For its successful execution, you need to add a line deb-srcto the file /etc/apt/sources.listand update the index files with the command apt update.

In addition, you can use the dget command (from the package devscripts) to directly download the .dsc file and related materials. In the case of packages prepared specifically for Kali, the source code of which is stored in the Git repository ongit.kali.org, you can download the source code using a command of the form git clone git://git.kali.org/packages/source-package(if after executing such a command nothing is loaded, try switching to a branch kali/masterusing the command git checkout kali/master).

After downloading the source code, install the packages listed in the package build dependencies with the source code using the command apt build-dep ./. It must be run from the package directory in which the source code is located.

Making changes to the package with the source code consists in performing the necessary actions from the following list:

  • The first step that you must always perform is to change the version number of the package. This is required so that the system can distinguish a new package from the original one. This is done using a view command dch --local version-identifieror by modifying other information about a package using a utility dch.
  • Applying a patch using a view command patch -p1 < patch-fileor modifying a series of patches quilt.
  • Configuring assembly parameters, which can usually be found in a file debian/rulesor in other files from a directory debian/.

After modifying the source package, you can build the binary package using the command dpkg-buildpackage -us -uc -bcalled from the source directory. This command will create an unsigned binary package. The resulting package can then be set with the following command: dpkg -i package-name_version_arch.deb.

9.5.2. Kernel assembly


Advanced system users sometimes need to recompile the Kali kernel. You may need this in order to reduce the size of the standard kernel, which, by default, contains many features and drivers. Building a new kernel may be necessary to add non-standard drivers or capabilities to it, or to install kernel patches. It is worth knowing that an incorrectly configured kernel can make the system unstable, and you should understand that the Kali team cannot provide security updates for the kernels that users build themselves.
In most cases, to make changes to the kernel, you will need to install some packages using the command apt install build-essential libncurses5-dev fakeroot.

Commandapt-cache search ^linux-sourceshould list the latest kernel versions created by the Kali support team. The view command apt install linux-source-version-numberinstalls a compressed archive with the kernel source code in /usr/src.

Files with source code must be unpacked by a command tar -xafinto a directory that differs from /usr/src(for example, c ~kernel).

When it comes time to tune the kernel, keep in mind the following considerations:

  • If you are not a user with vast experience, you should first fill out the kernel configuration file. To do this, it is best to take the standard kernel configuration by copying /boot/config-version-stringto ~/kernel/linux-source-version-number/.config. Alternatively, you can use the command make architecture_defconfigto build the appropriate configuration for your architecture.
  • The text-based kernel configuration tool launched by the command make menuconfigreads the file .configand makes it possible to configure the kernel using an extensive menu system. When you select an item, documentation on it and a list of possible values ​​are displayed, you can immediately enter a new value for it.

If you execute the command make cleanfrom the directory with the source code of the kernel, this will lead to the deletion of previously compiled files. The team make deb-pkgwill create up to five Debian packages. A file whose name looks like it linux-image-version.debcontains a kernel image and its associated modules.

In order to use the new kernel, you need to install the necessary packages using the command type dpkg -i file.deb. You can’t do without the linux-image package. The linux-headers package needs to be installed only if there are external kernel modules for assembly, which happens if you have installed * -dkms packages (you can check if this is the case with the command dpkg -l "*-dkms" | grep ^ii). Other packages, in most cases, are not used.

9.5.3. Build your own Kali ISOs


Kali's official ISOs are compiled using a set of scripts live-buildthat enables complete automation of work and customization of all aspects of creating ISO images.

For use live-build, the system must be updated to the latest version.

Kali live-build configuration data can be downloaded from Kali Git repositories using the command apt install curl git live-buildfollowed by the command git clone git://git.kali.org/live-build-config.git.

To create an updated but unmodified Kali ISO image, just use the team ./build.sh --verbose. The assembly will take a lot of time, since during the execution of this operation all the necessary packages will be downloaded. After the assembly is completed, the new ISO image can be found in the directoryimages. If you use the view option when executing this command --variant variant, the specified version of the image will be collected. The various options are determined by their configuration directories, whose names look like config/variant-*. The main image is created using the option gnome.

There are several approaches to configuring an ISO image, which include making changes to the configuration directory live-build:

  • You can add packages to the Live image (or remove existing packages from it) by modifying the files package-lists/*.list.chroot.
  • You can include your own packages in the image by placing the corresponding .deb files in the directory packages.chroot. Their installation can be automated using files preseed/*.cfg.
  • You can add files to the Live file system by placing them from where they should be in a folder includes.chroot.
  • During the process of assembling an image using, chrootyou can execute scripts by installing them as files hooks/live/*.chroot. In addition, scripts can be called at boot time using the created Live-image. They need to be installed at an address that looks like /usr/lib/live/config/XXXX-name, for example, based on the configuration directory includes.chroot.
  • To learn more about configuration and testing live-build, you can use the excellent Debian Live System Manual .

Deploying a Kali ISO image on a USB stick is pretty easy. At the same time, a permanent storage of information can be configured on such a medium. Although this process may seem a bit complicated, a closer look reveals that it is quite easy to create encrypted and unencrypted repositories on portable media. This greatly expands the functionality of such bootable media.

Now we present to your attention the exercises for this chapter.

Kali Kernel Package and Core Building Exercises


Exercise # 1: Creating Kali Pack Forks


  1. Create a fork package kali-meta.
  2. Include a new metapackage that contains 3 of your favorite tools and nothing more.
  3. Create a binary .deb file suitable for future reference.

▍Answers to exercise number 1


1. First, configure the system to work with packages with source code:

apt-get install devscripts #Для установки dch
nano /etc/apt/sources.list
# Раскомментируйте эту строку: deb-src http://http.kali.org/kali kali-rolling main non-free contrib

Now download the source code. Please note that if you follow these instructions, you may encounter other versions of packages:

apt-get update
apt source kali-meta # Установка всех пакетов kali-linux-*.
cd kali-meta-2017.2.0/
ls -l
nano debian/control

2. Change the control file, include your own packages in it:

Package: kali-linux-muts
Architecture: any
Depends: ${misc:Depends},
 kali-linux,
 aircrack-ng,
 nmap,
 sqlmap,
Description: Kali Linux Custom tools for muts
 This is Kali Linux, the most advanced penetration testing and security
 auditing distribution.
 .
 This metapackage depends on few of muts' favorites.

Change the package version number so that the rebuilt packages can be distinguished from the original ones:

root@kali:~/kali-meta-2017.2.0# head -1 debian/changelog
root@kali:~/kali-meta-2017.2.0# dch --local muts -m "Added a new metapackage"
root@kali:~/kali-meta-2017.2.0# head -1 debian/changelog # Проверка того, что изменения были выполнены

And finally, collect the package:

root@kali:~/kali-meta-2017.2.0# dpkg-buildpackage -us -uc -b # Disable signatures (-us -uc), binary-only build (-b)
root@kali:~/kali-meta-2017.2.0# ls -l ../*muts*
-rw-r--r-- 1 root root  6804 Aug 28 13:42 gqrx_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  6948 Aug 28 13:42 kali-desktop-common_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  6972 Aug 28 13:42 kali-desktop-gnome_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  6796 Aug 28 13:42 kali-desktop-kde_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  6920 Aug 28 13:42 kali-desktop-live_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  6812 Aug 28 13:42 kali-desktop-lxde_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  6868 Aug 28 13:42 kali-desktop-xfce_2017.2.0muts1_all.deb
-rw-r--r-- 1 root root  7068 Aug 28 13:42 kali-linux_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  7062 Aug 28 13:42 kali-linux-all_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  7290 Aug 28 13:42 kali-linux-forensic_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  8732 Aug 28 13:42 kali-linux-full_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  6850 Aug 28 13:42 kali-linux-gpu_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  6844 Aug 28 13:42 kali-linux-muts_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  7298 Aug 28 13:42 kali-linux-nethunter_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  7088 Aug 28 13:42 kali-linux-pwtools_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  6864 Aug 28 13:42 kali-linux-rfid_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  6908 Aug 28 13:42 kali-linux-sdr_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  6924 Aug 28 13:42 kali-linux-top10_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  6942 Aug 28 13:42 kali-linux-voip_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  7360 Aug 28 13:42 kali-linux-web_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root  7058 Aug 28 13:42 kali-linux-wireless_2017.2.0muts1_amd64.deb
-rw-r--r-- 1 root root 10312 Aug 28 13:42 kali-meta_2017.2.0muts1_amd64.buildinfo
-rw-r--r-- 1 root root  8343 Aug 28 13:42 kali-meta_2017.2.0muts1_amd64.changes
root@kali:~/kali-meta-2017.2.0# ls -l ../kali-linux-muts_2017.2.0muts1_amd64.deb 
-rw-r--r-- 1 root root 6852 Aug 28 14:05 ../kali-linux-muts_2017.2.0muts1_amd64.deb

Here is the solution on Asciinema (text from a video cannot be copied).

Exercise # 2: Kali Package Update


  1. Prepare the latest version of the SET software suite for use with Kali.
  2. Create a binary file for future reference.
  3. Is it possible, using the same approach, to update a package aircrack-ng?

▍Answers to exercise number 2


1. First, download the Kali version of SET:

apt source set

Next, download the latest version of SET. Here, as in the previous exercise, you may encounter other version numbers:

wget https://github.com/trustedsec/social-engineer-toolkit/archive/master.tar.gz -O set_7.7.1.orig.tar.gz
tar xvf set_7.7.1.orig.tar.gz

In order not to get confused, rename the latest version:

mv social-engineer-toolkit-master social-engineer-toolkit-7.7.1

We copy everything that is related to Debian:

cp -a set-7.7/debian social-engineer-toolkit-7.7.1/debian
rm -rf social-engineer-toolkit-7.7.1/.git

Update version number:

cd social-engineer-toolkit-7.7.1
head -1 debian/changelog
dch -v 7.7.1-0muts1 "New upstream release"
head -1 debian/changelog

2. We collect the package and check its performance:

dpkg-buildpackage -us -uc -b
ls -l ../*muts* # использованный тег версии
dpkg -i ../set_7.7.1-0muts1_all.deb # использованный тег версии

3. In the case of aircrack-ngeverything is done in a similar way:

nano /etc/apt/sources.list
apt-get update
apt source aircrack-ng
wget https://github.com/aircrack-ng/aircrack-ng/archive/master.tar.gz
tar zxpf master.tar.gz 
mv aircrack-ng-master aircrack-ng-1.3
cp -rf aircrack-ng-1.2-0~rc4/debian/ aircrack-ng-1.3/
cd aircrack-ng-1.3/
head -1 debian/changelog 
dch -v 1:1.3 -m "Upstream update"
nano debian/changelog 
dpkg-checkbuilddeps 
apt-get install libgcrypt-dev libgcrypt11-dev libnl-genl-3-dev libpcap0.8-dev libpcre3-dev libsqlite3-dev pkg-config zlib1g-dev
dpkg-buildpackage -us -uc -b

Exercise # 3: rebuilding the kernel


When building a standard Kali kernel, the principle of including maximum functionality in it works. This is necessary to provide support for the widest possible range of hardware platforms.

  1. Install a tool for measuring performance like likwidand run a quick test likwid-bench.
  2. Install the graysky2 Kernel GCC patch to optimize the kernel for your processor.
  3. Recompile the kernel after installing the patch and choosing your processor model.

▍Answers to exercise number 3


1. Install likwid, run the test:

apt-get install likwid
likwid-topology -g | head # выясняем подробности об имеющемся процессоре
likwid-bench -t copy -w S0:100kB:1 # запускаем тест на socket 0

2. A patch for optimizing the kernel for a specific processor can be found here . Install the dependencies necessary to perform recompilation of the kernel. Here, as usual, you may come across other versions:

apt install build-essential libncurses5-dev fakeroot
apt-cache search ^linux-source # выполним поиск текущей версии linux-source package
apt install linux-source-4.9 # загрузим её
ls /usr/src # which gets extracted to /usr/src

3. We will extract the source code of the kernel and copy to where it appears the current configuration file:

mkdir ~/kernel; cd ~/kernel
tar -xaf /usr/src/linux-source-4.9.tar.xz
cp /boot/config-4.9.0-kali3-amd64 ~/kernel/linux-source-4.9/.config # Copy existing config

Run menuconfigon an unpatched kernel configuration:

cd linux-source-4.9
make menuconfig

Let's go through the following menu items and see the type of processor:

Processor type and features  ---> 
  Processor family (Generic-x86-64)  --->

We exit the configuration without saving. Download the optimizing patch and patch the kernel:

cd ~/kernel
wget https://raw.githubusercontent.com/graysky2/kernel_gcc_patch/master/enable_additional_cpu_optimizations_for_gcc_v4.9%2B_kernel_v3.15%2B.patch
cd linux-source-4.9/
patch -p1 < ../enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v3.15+.patch 
make menuconfig

Now again we enter the section of the configuration program that allows you to configure the type of processor. New items should appear here:

Processor type and features  ---> 
  Processor family (Generic-x86-64)  --->



Choose the type of processor you need, save the configuration and exit the program. Now let's build the kernel:

export CONCURRENCY_LEVEL=5 #количество имеющихся CPU +1
make deb-pkg LOCALVERSION=-custom KDEB_PKGVERSION=$(make kernelversion)-1

Run the test:

likwid-topology -g | head # выясняем подробности об имеющемся процессоре
likwid-bench -t copy -w S0:100kB:1 # запускаем тест на socket 0

Have test scores improved? How are you feeling? Maybe something like this happened?


Live assembly exercises


Exercise # 1: Kali Special Live Build


In one of the series Mr. Robot Angela needs to boot from the Kali USB drive and, in order to crack the system, enter a few commands. Can you put together a Kali ISO that will allow her to solve the problem faster? Automate your work so that after loading Kali Angela would not have to touch the keyboard.

▍Answers to exercise number 1


To solve this problem, you need to collect Live-ISO for Angela and give it to her.

# Обновляем систему!
apt-get update
apt-get dist-upgrade
# устанавливаем необходимые инструменты
apt install -y git live-build cdebootstrap curl
# Клонируем конфигурационные файлы Kali live build
git clone git://git.kali.org/live-build-config.git
# Перезаписываем стандартный список пакетов, меняя его на минимально необходимый набор
cd live-build-config/
cat kali-config/variant-default/package-lists/kali.list.chroot
echo cryptsetup > kali-config/variant-default/package-lists/kali.list.chroot
echo openssh-server >> kali-config/variant-default/package-lists/kali.list.chroot
echo nmap >> kali-config/variant-default/package-lists/kali.list.chroot
# Добавляем файлы в live-файловую систему (настраиваем скрипты, выполняющиеся при загрузке)
mkdir -p kali-config/common/includes.chroot/lib/systemd/system/
# Регистрируем собственную службу "Angela" для запуска /usr/bin/startssh
cat << EOF > kali-config/common/includes.chroot/lib/systemd/system/angela.service
[Unit]
Description=Start Custom Script
After=multi-user.target
[Service]
Type=idle
ExecStart=/bin/bash /usr/bin/startssh
[Install]
WantedBy=multi-user.target
EOF
# Создаём /usr/bin (и родительские каталоги) в Live-файловой системе
mkdir -p kali-config/common/includes.chroot/usr/bin/
# Создаём скрипт "startssh", который сделает наше чёрное дело
cat << EOF > kali-config/common/includes.chroot/usr/bin/startssh
#!/bin/sh
echo hola > /root/test.txt
EOF
# Создаём хук, активирующий службу
cat << EOF > kali-config/common/hooks/live/angela.chroot
#!/bin/sh
systemctl enable angela.service || true
EOF
# Делаем его исполняемым
chmod 755 kali-config/common/hooks/live/angela.chroot
# Создаём конфигурационный файл загрузки, настраиваем приглашение, тайм-аут, автозагрузку, и так далее
cat << EOF > kali-config/common/includes.binary/isolinux/isolinux.cfg
include menu.cfg
default vesamenu.c32
prompt 0
timeout 20
ONTIMEOUT live-amd64
EOF
# Собираем ISO!
./build.sh --verbose

Exercise # 2: Automatic Kali Minimalist Live Installer


  1. Create a self-installing ISO image containing as few packages as possible and include only openssh-serverand packages in it salt-minion.
  2. Add your public SSH key to this image to facilitate subsequent access to it.
  3. Check the health of the image.

▍Answers to exercise number 2


The set live-builduses the entire directory structure as input to its configuration. We store this configuration and some helper scripts in the Git repository live-build-config. We will use this repository as a base for building custom images. Install the necessary packages and download the Git repository with Kali live-build configuration:

apt install curl git live-build
git clone git://git.kali.org/live-build-config.git
cd live-build-config

Create a list of packages to be included in the image, starting with salt-minion:

echo salt-minion > kali-config/variant-default/package-lists/kali.list.chroot

And more packages:

echo openssh-server >> kali-config/variant-default/package-lists/kali.list.chroot

Create a directory for the included files and put ours there preseed.cfg:

mkdir -p kali-config/common/includes.installer
wget https://www.kali.org/dojo/preseed.cfg -O ./kali-config/common/includes.installer/preseed.cfg

You can add files to the ISO image by placing them in the configuration directory includes.binary. For example, this install.cfg(boot menu options):

cat << EOF > kali-config/common/includes.binary/isolinux/install.cfg
label install
menu label ^Install
linux /install/vmlinuz
initrd /install/initrd.gz
append vga=788 --quiet file=/preseed.cfg locale=en_US keymap=us hostname=kali domain=local.lan
EOF

There you can add a file isolinux.cfgwith download options:

cat << EOF > kali-config/common/includes.binary/isolinux/isolinux.cfg
include menu.cfg
ui vesamenu.c32
default install
prompt 0
timeout 5
EOF
echo 'systemctl enable ssh' >  kali-config/common/hooks/live/01-start-ssh.chroot

Add to the ISO-image and SSH-key:

ssh-keygen -f /root/.ssh/id_rsa -t rsa -N '' # необязательно в том случае, если это уже сделано
mkdir -p kali-config/common/includes.chroot/root/.ssh/
cat /root/.ssh/id_rsa.pub > kali-config/common/includes.chroot/root/.ssh/authorized_keys

Let's assemble the image:

./build.sh --verbose

Exercise # 3: Build LIve-USB with Multiple Persistent Storage and Self Destruction Password


Create a live flash drive with several permanent repositories of information and enable the LUKS self-destruction password.

▍Answers to exercise number 3


Здесь мы предполагаем, что работа начинается с USB-флэшки, подготовленной в соответствии с инструкциями, приведёнными в разделе 2.1.4., «Копирование образа на DVD-ROM или на USB-флэшку». Подразумевается, что диск имеет размер, достаточный для хранения ISO-образа (около 3 Гб) и данных, которые планируется поместить в постоянное хранилище. Кроме того, мы исходим из предположения, что Linux видит флэш-диск как /dev/sdb, и что он содержит лишь два раздела, которые являются частью стандартного ISO-образа (/dev/sdb1 и /dev/sdb2). Считаем важным напомнить, что выполняя действия, которые будут описаны ниже, нужно проявлять осторожность, так как переразбив не тот диск можно потерять важные данные.

Now we connect the flash drive to the computer (or to the virtual machine) and find out the name of the device using the dmesgor commands fdisk. As already mentioned, it is assumed that this /dev/sdb. If any partitions were mounted automatically, they must be unmounted. Now we start the partitioning process:

umount /dev/sdb1
umount /dev/sdb2
parted /dev/sdb

Here we will create two repositories. One will be encrypted, the other normal.

(parted) print                                                            
Model: SanDisk Ultra USB 3.0 (scsi)
Disk /dev/sdb: 124GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start   End     Size    Type     File system  Flags
1      32.8kB  2794MB  2794MB  primary               boot, hidden
2      2794MB  2794MB  721kB   primary
(parted) mkpart primary 2794 5000
(parted) mkpart primary 5000 100%                                         
(parted) quit                                                             
Information: You may need to update /etc/fstab.

The team mkpart primary2794 5000creates the first new partition (if you count them all, it will be the third), which starts with 2794 MB and ends with 5000 MB. We use exactly this value to indicate the beginning of the section, since the Kali image occupies 2794 Mb on the device. You may need to change these values ​​in order to fit them to the size of your ISO image or flash drive.

After creating two new sections, you can begin to configure them as permanent information stores in our Kali download environment. We begin this process using the name sdb3for unencrypted storage. We first format the section, then give it a labelpersistence. The label should be just that, it is very important. If you skip this step or assign a different label to the partition, the permanent storage of information will not work!

mkfs.ext3 /dev/sdb3
e2label /dev/sdb3 persistence

Then we create a file persistence.confthat indicates which folders we need to keep in persistent storage. In this case, we are going to save the entire file system there:

mkdir -p /mnt/usb
mount /dev/sdb3 /mnt/usb
echo "/ union" > /mnt/usb/persistence.conf
umount /mnt/usb

Next, configure the encrypted persistent storage. To do this, we encrypt the section using cryptsetup, format it, assign a label, check if everything is done correctly and create the file persistence.confin the same way as we did above:

cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb4
cryptsetup luksOpen /dev/sdb4 my_usb
mkfs.ext3 /dev/mapper/my_usb
e2label /dev/mapper/my_usb persistence
ls -l /dev/disk/by-label
mkdir -p /mnt/my_usb
mount /dev/mapper/my_usb /mnt/my_usb
echo "/ union" > /mnt/my_usb/persistence.conf
umount /dev/mapper/my_usb
cryptsetup luksClose /dev/mapper/my_usb

That's all! Now you can boot from a USB drive and choose how to continue the download: without storage, with unencrypted storage, or with encrypted storage.

In order to add a self-destruct password (LUKS Nuke) to the encrypted partition, you need to run the following command:

cryptsetup luksAddNuke /dev/sdb4

Summary


This concludes the publication of the translation of the 9th chapter of the book, Kali Linux Revealed . We hope that these materials helped everyone to master the assembly of Kali packages and kernels, as well as the preparation of their own ISO-images of the system.

Dear readers! Tell us, did you manage to complete the exercises for this chapter on your own?

Previous parts:

→ Part 1. Kali Linux: security policy, protecting computers and network services
→ Part 2. Kali Linux: filtering traffic using netfilter
→ Part 3. Kali Linux: monitoring and logging
→ Part 4. Kali Linux: protection exercises and system monitoring
→ Part 5. Kali Linux: assessment of system security
→ Part 6. Kali Linux: types of checks of information systems
→ Part 7. Kali Linux: formalization of studies and types of attacks
→ Part 8. Kali Linux: security questions on researching system security
→ Part 9. Kali Linux: modification of packages
→ Part 10. Kali Linux: building a kernel
→ Part 11. Kali Linux: setting up and building ISO images

Read Next