Geekly Articles each Day
📜 ⬆️ ⬇️

Kali Linux: Configuring and building ISO images

Downloading Kali Linux from removable media is useful in many situations. In the simplest form, such a medium, in the format of a DVD or flash drive, is created using a standard ISO image of the system. However, much more features are provided by assembling your own images and creating bootable media with a permanent data storage. In addition, sometimes images of a system that are configured in a special way can be useful. The third and fourth sections of the ninth chapter of the book “ Kali Linux Revealed ”, the translations of which we publish in this material, are devoted to all this.



9.3. Build your own Kali Linux ISOs


The standard version of Kali Linux is flexible and has many features. Immediately after its installation, you can begin to solve many difficult problems. Of course, some level of knowledge of the tools included in the distribution, creativity, patience and experience will not hurt here. However, the image of Kali can be customized, including in it what is needed, or removing the excess, to set automatic execution of any actions during the system boot.

Among the examples of such special images are the Kali ISO of Doom and Kali Evil Wireless Access Point , the most interesting projects that rely on custom-made Kali Linux implementations. Take a look at the process of creating your own Kali Linux ISO images.
')
The official images of Kali are collected using live-build . This is a set of scripts that allows you to fully automate and customize all aspects of creating ISO images. The live-buid uses, when forming its configuration, the directory structure. This configuration and some related helper scripts can be found in the live-build-config Git repository. We will use this repository as a basis for building images that are configured in accordance with special requirements.

Before proceeding, you should be aware that the commands shown in this section are designed to run in the current version of Kali Linux. If you try to use them in an OS other than Kali, or in the outdated version of Kali, they most likely will not work properly.

9.3.1. Install the necessary software


The first step in building your own ISO image is to install the necessary packages and download the Git repository with the Kali live-build configuration:

 # apt install curl git live-build [...] # git clone git://git.kali.org/live-build-config.git [...] # cd live-build-config # ls auto  build_all.sh  build.sh  kali-config  README

After that, you can already create updated (but unmodified) Kali ISO images. To do this, simply use the command ./build.sh --verbose . The assembly will take a lot of time, because in its course all the packages that need to be included in the image will be loaded. After completing this process, you can find a new ISO image in the images directory.

9.3.2. Build a Live Image with Different Desktop Environments


The standard build.sh script from the live-build kit is responsible for preparing the config directory. Her presence is expected to live-build . The script helps to set different configurations, depending on its option --variant .

The script creates the config directory by combining files from kali-config/common and kali-config/variant-X , where X — the name of the variant specified using the --variant parameter. When this option is not specified explicitly, the default name is used as a variant name.

The kali-config folder contains directories for the most popular desktop environments:


The light option is a special case. It is based on XFCE and is used to create an official lightweight ISO image that contains a reduced set of applications.

Here, for example, how to create a Kali Live image using KDE as your desktop environment:

 # ./build.sh --variant kde --verbose

The above concept of options allows you to perform a general system configuration, using a set of standard presets. However, in fact, the images are amenable to much deeper customization. You can read about it in the Debian Live System Manual . There you will find many other ways to customize the images, which are to change the contents of the corresponding subdirectories in kali-config . Below we look at a few examples.

9.3.3. Change the set of installed packages


Live-build , after launch, installs all the packages listed in the package-lists/*.list.chroot . The standard configuration includes the package-lists/kali.list.chroot , which contains an entry for the kali-linux-full package (this is the basic meta package, which results in the inclusion of all Kali packages in the image). The line with the mention of this package can be commented out and use another meta package or make your own list of other packages. In addition, you can combine both approaches, starting with a meta package and adding additional necessary packages.

Using package-lists , only those packages that are already available in the official Kali repository can be included in the image. However, if you have your own packages, you can include them in the Live image by placing the corresponding .deb files in the packages.chroot directory (for example, in kali-config/config-gnome/packages.chroot , if you, when building, use the GNOME graphical environment option).

Meta-packages are empty packages that are used only because they include many dependencies on other packages. As a result, they simplify the installation of sets of packages that are usually installed together. The kali-meta source package is responsible for building all the meta packages provided by Kali Linux:


You can use these meta packages when creating your own list of packages for live-build . A complete list of the available meta packages and the software they include can be found here .

â–ŤAutomation of customization of installed packages


To automate the configuration of installed packages, you can use Debconf answer files (for more information, see section 4.3.2., “ Creating an Answer File ”), placing them in preseed/*.cfg . They will be used to customize the packages used to create the live image.

9.3.4. Use hooks to fine-tune image content.


Working with live-build , you can use hooks that are performed at various stages of the build process. chroot — hooks/live/*.chroot are executable scripts that are installed as hooks/live/*.chroot in the configuration tree and are executed using chroot . While chroot — a command that allows you to temporarily change the root directory of an operating system to a selected directory, it is also used by live-build to designate a directory containing the full (alternative) tree of the file system. In the case of live-build , the chroot directory is the directory where the file system is prepared for the live image. Since applications running using chroot do not have access beyond the selected directory, the same is true for chroot hooks: you can only use and modify what is available in the chroot environment. We rely on these hooks to perform many Kali-specific settings (take a look at kali-config/common/hooks/live/kali-hacks.chroot ).

Binary hooks ( hooks/live/*.binary Binary) are executed in the context of the build process, at the end of this process. They are not called during assembly using chroot . With their help, you can modify the contents of the assembly ISO image, but not the Live-file system, since at this point it has already been created. We use this feature in Kali to make some changes to the standard isolinux configuration created by live-build . For example, take a look at config/common/hooks/live/persistence.binary , where we add boot menu items to enable the persistent data store.

9.3.5. Adding files to the ISO image or to the Live file system


Another very common way to customize images is to add files to either the live file system or an ISO image.

Files can be added to the file system by placing them where they should be in the includes.chroot configuration directory. For example, there is a standard file kali-config/common/includes.chroot/usr/lib/live/config/0031-root-password , which ultimately turns out to be located in the Live-file system at /usr/lib/live/config/0031-root-password .

â–ŤHooks live-boot


The scripts installed in /lib/live/config/XXXX-name are executed by the init script of the live-boot package. They reconfigure many aspects of the system so that they are suitable for working in live mode. Here you can add your own scripts to customize your Live-system during operation. In particular, they are used, for example, to implement their own boot parameters.

You can add files to the ISO image by placing them in the includes.binary configuration directory where they should be. For example, there is a standard kali-config/common/includes.binary/isolinux/splash.png that overrides the background image used by the isolinux bootloader (it is stored in the /isolinux/splash.png file in the ISO image file system).

9.4. Adding Permanent Storage to Live-ISO using USB Disk


9.4.1. Permanent Storage Features


Here we look at the steps needed to add a permanent storage of information on a USB flash drive with Kali written on it. The essence of a live-file system is its ephemerality. All data saved when working with such a system disappears after a reboot, the same goes for system settings. In order to avoid this, you can use the live-boot feature, called persistence. This feature is activated if the boot options include the persistence keyword.

Since modifying the boot menu is not an easy task, Kali, by default, has two menu items that allow you to enable persistent storage. This is shown in the following figure, Live USB Persistence and Live USB Encrypted Persistence .


Fig. 9.1. Menu items to enable persistent storage

When this feature is enabled, live-boot scan all partitions for file systems marked as persistence (this can be changed using the persistence-label=value boot parameter), and the installer will create a repository for the directories that are listed in the persistence.conf file found in this section (each directory is listed on a separate line). The special option / union allows you to enable full preservation of all directories using cascade-unified mount (union mount). With this approach, an additional file system level is created, in which only changes made to the data of the underlying file system are saved. Directory data that is not lost after a reboot is stored in the file system, which contains the corresponding persistence.conf file.

9.4.2. Create unencrypted storage on a USB drive


It assumes that you have prepared a USB flash drive with a Live system, following the instructions found in section 2.1.4., “ Copying an Image to a DVD-ROM or a USB Flash Drive, ” and that the size of the media is enough to store the image ( about 3 GB) and for storing data directories that fall into the permanent storage. In addition, we assume that Linux sees the USB flash drive as /dev/sdb , and that it contains only two partitions that are part of the standard ISO image ( /dev/sdb1 and /dev/sdb2 ). Doing what is discussed below, be very careful. The fact is that if you accidentally re-partition the wrong disk, this can result in the loss of important data.

In order to add a new partition to the disk, you need to know the size of the image that already exists on the flash drive. This will give you the opportunity to make the new section begin immediately after the Live image. Then you need to use the parted command to create the partition. The following commands analyze the kali-linux-2016.1-amd64.iso ISO image, which is expected to be present on a USB flash drive:

 # parted /dev/sdb print Model: SanDisk Cruzer Edge (scsi) Disk /dev/sdb: 32,0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number  Start   End     Size    Type     File system  Flags 1      32,8kB  2852MB  2852MB  primary               boot, hidden 2      2852MB  2945MB  93,4MB  primary # start=$(du --block-size=1MB kali-linux-2016.1-amd64.iso | awk '{print $1}') # echo "Size of image is $start MB" Size of image is 2946 MB # parted -a optimal /dev/sdb mkpart primary "${start}MB" 100% Information: You may need to update /etc/fstab. # parted /dev/sdb print Model: SanDisk Cruzer Edge (scsi) Disk /dev/sdb: 32,0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number  Start   End     Size    Type     File system  Flags 1      32,8kB  2852MB  2852MB  primary               boot, hidden 2      2852MB  2945MB  93,4MB  primary 3      2946MB  32,0GB  29,1GB  primary

When the new /dev/sdb3 created, format it in the ext4 file system and assign the persistence label to it using the mkfs.ext4 (and its -L options to assign a label). Then the partition is mounted in the /mnt directory and the persistence.conf file is added there. Be careful when formatting any disk. If you format the wrong partition or the wrong drive, you may lose something important.

 # mkfs.ext4 -L persistence /dev/sdb3 mke2fs 1.43-WIP (15-Mar-2016) Creating filesystem with 7096832 4k blocks and 1777664 inodes Filesystem UUID: dede20c4-5239-479a-b115-96561ac857b6 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done # mount /dev/sdb3 /mnt # echo "/ union" >/mnt/persistence.conf # ls -l /mnt total 20 drwx------ 2 root root 16384 May 10 13:31 lost+found -rw-r--r-- 1 root root     8 May 10 13:34 persistence.conf # umount /mnt

Now the USB flash drive is ready so that you can boot from it using the Live USB Persistence menu item.

9.4.3. Creating an encrypted storage on a USB flash drive


If necessary, a permanent data storage can be organized on an encrypted partition, it supports live-boot . This approach allows you to protect data by creating an encrypted LUKS partition, on which they are stored.

Creating encrypted storage begins with the same actions that we performed before. However, now, instead of formatting the partition in the ext4 file system, use cryptsetup to initialize the partition as a LUKS container. Then open this container and configure the ext4 file system as you did when creating unencrypted storage, but instead of using the /dev/sdb3 partition, use the virtual partition created by cryptsetup . This virtual partition is the decrypted content of the encrypted partition, which is available in /dev/mapper under the name you assigned to it. In the example below, we will use the name kali_persistence . Recall that when performing such operations, it is worth being vigilant and not accidentally formatting the wrong disk or partition.

 # cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb3 WARNING! ======== This will overwrite data on /dev/sdb3 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: Command successful. # cryptsetup luksOpen /dev/sdb3 kali_persistence Enter passphrase for /dev/sdb3: # mkfs.ext4 -L persistence /dev/mapper/kali_persistence mke2fs 1.43-WIP (15-Mar-2016) Creating filesystem with 7096320 4k blocks and 1774192 inodes Filesystem UUID: 287892c1-00bb-43cb-b513-81cc9e6fa72b Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done # mount /dev/mapper/kali_persistence /mnt # echo "/ union" >/mnt/persistence.conf # umount /mnt # cryptsetup luksClose /dev/mapper/kali_persistence

9.4.4. Using multiple permanent repositories


If you use the Kali Live image in different situations, you can create several file systems with different labels and, on the boot command line, specify which file system to use in a particular session. This is done using the boot parameter persistence-label=label .

Suppose you are a professional pentester. Working with a client, you use persistent storage located on an encrypted partition. You do this to protect your data in case the USB flash drive is stolen or hacked. At the same time, you want to be able to demonstrate Kali and any advertising materials stored on an unencrypted partition on the same disk. Since you wouldn’t like to manually edit the parameters on each boot, you decide to build your own Live image with separate items in the boot menu.

The first step is to build your own Live-ISO (in accordance with section 9.3., " Building Kali Linux's own ISO images, " and, in particular, with section 9.3.4., " Using hooks to fine-tune the contents of the image "). The most important thing to do at this stage is to modify the kali-config/common/hooks/live/persistence-menu.binary , bringing it to something like this (pay attention to the persistence-label parameters):

 #!/bin/sh if [ ! -d isolinux ]; then   cd binary fi cat >>isolinux/live.cfg <<END label live-demo   menu label ^Live USB with Demo Data   linux /live/vmlinuz   initrd /live/initrd.img   append boot=live username=root hostname=kali persistence-label=demo persistence label live-work   menu label ^Live USB with Work Data   linux /live/vmlinuz   initrd /live/initrd.img   append boot=live username=root hostname=kali persistence-label=work persistence-encryption=luks persistence END

Next, we collect the ISO image and copy it to a USB flash drive. Then we create and initialize two partitions and file systems that will be used to organize permanent data stores. The first section, labeled demo , was created without encryption, the second, labeled work , is encrypted. Here, based on the assumption that the USB disk is visible in the system as /dev/sdb , and the size of our ISO image is 3000 MB, you need to perform the following sequence of actions:

 # parted /dev/sdb mkpart primary 3000 MB 55% # parted /dev/sdb mkpart primary 55% 100% # mkfs.ext4 -L demo /dev/sdb3 [...] # mount /dev/sdb3 /mnt # echo "/ union" >/mnt/persistence.conf # umount /mnt # cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb4 [...] # cryptsetup luksOpen /dev/sdb4 kali_persistence [...] # mkfs.ext4 -L work /dev/mapper/kali_persistence [...] # mount /dev/mapper/kali_persistence /mnt # echo "/ union" >/mnt/persistence.conf # umount /mnt # cryptsetup luksClose /dev/mapper/kali_persistence

That's all. Now you can boot from a USB disk and select the necessary items from the new boot menu.

â–ŤSetting self-destruct password to enhance system security


Kali has a modified cryptsetup to implement a new feature. , (nuke password), , , , .

, . , ( ) .

, .

, , , :

 $ cryptsetup luksAddNuke /dev/sdb4 Enter any existing passphrase: Enter new passphrase for key slot: Verify passphrase:

.

Results


, ISO-, USB-, Live-, , . « Kali Linux Revealed » .

Dear readers! , Kali Linux?

:

→ 1. Kali Linux: ,
→ 2. Kali Linux: netfilter
→ 3. Kali Linux:
→ 4. Kali Linux:
→ 5. Kali Linux:
→ 6. Kali Linux:
→ 7. Kali Linux:
→ 8. Kali Linux:
→ Part 9. Kali Linux: package modification
→ Part 10. Kali Linux: kernel build

Source: https://habr.com/ru/post/341882/

More articles:


All Articles