这是用于创建 Kali Linux 虚拟机 (VM) 镜像的构建脚本。
目前有两种构建方法：
build.sh - 直接从你的机器构建build-in-container.sh - 在容器（Docker 或 Podman）内构建无论采用哪种方式，实际构建都发生在由构建工具 debos 即时创建的虚拟机内。 Debos 底层使用 fakemachine，而它又依赖于 QEMU/KVM。
确保 git 仓库已在本地克隆：
$ sudo apt install -y git
$ git clone https://gitlab.com/kalilinux/build-scripts/kali-vm.git
$ cd kali-vm/
由于 QEMU/KVM 的要求，你必须是 kvm 组的成员。
你可以通过以下方式检查：
$ # Not apart of the group
$ grep kvm /etc/group
kvm:x:104:
$
$ # In the group
$ grep kvm /etc/group
kvm:x:104:kali
如果你的用户名没有出现在返回的行中，则表示你不在该组中，你必须将自己添加到 kvm 组：
$ sudo adduser $USER kvm
然后注销并重新登录以使更改生效。
如果使用 build.sh 直接从你的机器构建，你需要安装 debos：
$ sudo apt install -y 7zip debos dosfstools qemu-utils zerofree
然后使用脚本 build.sh 直接在你的机器上构建 VM 镜像。
如果你更喜欢在容器内构建，你需要在机器上安装并配置 docker 或 podman。
然后使用脚本 build-in-container.sh 构建镜像。
build-in-container.sh 只是 build.sh 之上的一个包装脚本。
它会检测要使用哪个符合 OCI 标准的容器引擎，负责在缺少时创建容器镜像，最后启动容器在其中执行构建。
docker 要求用户被添加到 Docker 组，就像上面 KVM 的情况一样，或者使用 root 账户（例如 $ sudo ./build-in-container.sh）。
podman 已测试支持 rootful（例如 $ sudo ./build-in-container.sh）和 rootless（例如 $ ./build-in-container.sh）两种模式。
根据你的偏好使用 build.sh 或 build-in-container.sh。
为简洁起见，从现在开始我们将使用 build.sh。
一如既往，最好的起点是用法信息：
$ ./build.sh -h
Usage: build.sh <options> [-- <debos options>]
Build a Kali Linux VM image
Build options:
-a ARCH Build an image for this architecture, default: amd64
Supported values: amd64
-b BRANCH Kali branch used to build the image, default: kali-rolling
Supported values: kali-dev kali-last-snapshot kali-rolling
-f FORMAT Format to export the image to, default depends on the VARIANT
Supported values: hyperv ova ovf qemu raw vagrant virtualbox vmware
-k Keep raw disk image and other intermediary build artifacts
-m MIRROR Mirror used to build the image, default: http://http.kali.org/kali
-r ROOTFS rootfs to use to build the image, default: none
-s SIZE Size of the disk image in GB, default: 86
-v VARIANT Variant of image to build (see below for details), default: generic
Supported values: generic hyperv qemu rootfs virtualbox vmware
-x VERSION What to name the image release as, default: rolling
-z Zip images and metadata files after the build
Customization options:
-D DESKTOP Desktop environment installed in the image, default: xfce
Supported values: e17 gnome i3 kde lxde mate xfce none
-H HOSTNAME Set system host name, default: kali
-K KEYBOARD Set keyboard layout, default: us
Refer to the README.md for more details
-L LOCALE Set locale, default: en_US.UTF-8
-P PACKAGES Install extra packages (comma/space separated list)
-T TOOLSET The selection of tools to include in the image, default: default
Supported values: default everything headless large none
-U USERPASS Username and password, separated by a colon, default: kali:kali
-Z TIMEZONE Set timezone, default: America/New_York
The different variants of images are:
generic Image with all virtualization support pre-installed, default format: raw
hyperv Image pre-configured for Hyper-V "Enhanced Session Mode", default format: hyperv
qemu Image with QEMU and SPICE guest agents pre-installed, default format: qemu
rootfs Not an image, a root filesystem (no bootloader/kernel), packed in a .tar.gz
virtualbox Image with VirtualBox guest utilities pre-installed, default format: virtualbox
vmware Image with Open VM Tools pre-installed, default format: vmware
The different formats are:
hyperv VHDX disk image, powershell install scripts
ova streamOptimized VMDK disk image, OVF metadata file, packed in a OVA archive
ovf monolithicSparse VMDK disk image, OVF metadata file
qemu QCOW2 disk image, no metadata
raw sparse disk image, no metadata
virtualbox VDI disk image, .vbox metadata file
vmware 2GbMaxExtentSparse VMDK disk image, VMX metadata file
Supported environment variables:
http_proxy HTTP proxy URL, refer to the README.md for more details
Most useful debos options:
--artifactdir DIR Set artifact directory, default: images
--memory, -m SIZE Limit amount of memory to build VM in GB, default: 4G
--scratchsize SIZE Limit amount of HDD to build VM in GB, default: 45G
--debug-shell Get a shell on the VM
--help, -h See the complete list of options for debos
Refer to the README.md for examples
默认选项将为 AMD64 架构构建一个 Kali rolling 镜像、默认桌面环境和默认工具集。
这是一个原始磁盘镜像，即磁盘的纯二进制镜像（可以使用 QEMU 启动）。
示例：
$ ./build.sh
构建一个为 VMware 定制的 Kali Linux 镜像。 这意味着它预装了 Open VM Tools，生成的镜像可以直接"原样"导入 VMware。
此外，我们将从 Kali 的最后一个稳定版本构建它，并且将使用 GNOME 作为桌面环境，而不是通常默认的 Xfce：
./build.sh -v vmware -b kali-last-snapshot -D gnome
构建一个为 VirtualBox 设计的 Kali Linux 镜像。 它预装了 VirtualBox 客户机工具，镜像可以"原样"导入 VirtualBox。
此外，我们想要一个 150 GB 的虚拟磁盘，并且我们将安装"everything"工具选择：
./build.sh -v virtualbox -s 150 -S everything
构建一个轻量级 Kali 镜像，没有桌面环境，也没有默认工具集。 这是一个通用镜像，支持市面上大多数 VM 引擎。 我们将其导出为 OVA 格式，适用于 VMware 和 VirtualBox。
你可以使用 -P 选项安装额外的软件包。
可以多次使用该选项（例如 -P pkg1 -P pkg2 ...），或提供逗号/空格分隔的值（例如 -P "pkg1,pkg2, pkg3 pkg4"），或两者混合使用。
让我们也安装软件包 metasploit-framework：
./build.sh -v generic -f ova -D headless -P metasploit-framework
当构建一系列镜像时，将构建分成两部分可能会更方便（也更快）：首先构建一个 rootfs，然后通过重用此 rootfs 作为起点来构建镜像。
在下面的示例中，我们首先构建了一个 kali-rolling rootfs，然后构建了一系列 Vagrant 镜像：
./build.sh -b kali-rolling -v rootfs
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v hyperv
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v qemu
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v virtualbox
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v vmware
要设置键盘设置，请使用选项 -K。
该设置的形式为 <layouts>/<models>/<variants>/<options>。每个设置都可以省略（在这种情况下使用默认值），也可以有多个用逗号分隔的值。在最简单的情况下，你可能只想更改键盘布局，因此可以为美式键盘布局设置 us，为德式键盘布局设置 de，依此类推。更详细的说明和示例可以在 keyboard(5) 手册页中找到。
有关支持值的列表，你可以参考文件 /usr/share/X11/xkb/rules/xorg.lst（由 Debian 及类 Debian 系统上的 xkb-data 软件包提供）。此文件有不同的部分（! layout、! model、!variant 和 !option），列出了每个设置的可能值。
你也可以使用 cat /etc/default/keyboard 查看系统上的配置。
还有一个快捷方式 -K same 可以匹配宿主机系统（即 /etc/default/keyboard 文件中的设置）。
要设置区域设置，请使用选项 -L。
在 /usr/share/i18n/SUPPORTED 的第 1 列中选择一个值，或使用 grep -v ^# /etc/locale.gen 查看系统上的配置，或者简单地使用 echo $LANG。
还有一个快捷方式 -L same 可以匹配宿主机系统。
要设置时区，请使用选项 -Z。
查看 /usr/share/zoneinfo，选择一个目录和一个子目录。
如有疑问，运行 tzselect 来指导你，或使用 realpath /etc/localtime 查看系统上的配置。
还有一个快捷方式 -Z same 可以匹配宿主机系统。
要为非特权用户设置名称和密码，请使用选项 -U。
该值是一个字符串，: 用于将用户名与密码分开。
在这里，我们将构建一个 Kali 镜像，并将其配置为模仿宿主机系统：相同的区域设置、相同时区以及相同的用户名（密码为 password）：
./build.sh -K same -L same -Z same -U $USER:password
可以构建不同变体的镜像，具体取决于你想在哪个 VM 引擎中运行 Kali 镜像。 VARIANT 主要定义在镜像中安装哪些额外的软件包，以添加对特定 VM 引擎的支持。 FORMAT 则定义虚拟磁盘的格式，以及生成哪些额外的元数据文件。
如果未设置，格式（选项 -f）会根据变体（选项 -v）自动设置。
并非每种变体和格式的组合都有意义，因此下表总结了最常见的组合。
| 变体 | 格式 | 磁盘格式 | 元数据 | 打包 |
|---|---|---|---|---|
| generic | raw | raw（稀疏文件） | 无 | |
| generic | ova | streamOptimized VMDK | OVF | OVA |
| generic | ovf | monolithicSparse VMDK | OVF | |
| qemu | qemu | QCOW2 | 无 | |
| virtualbox | virtualbox | VDI | VBOX | |
| vmware | vmware | 2GbMaxExtentSparse VMDK | VMX |
generic 镜像预装了 QEMU、VirtualBox 和 VMware 的虚拟化支持软件包，因此得名 "generic"。
而其他针对特定 VM 引擎的镜像，仅带有对该特定虚拟化引擎的支持。
只有 ova 格式定义了容器：构建的结果是一个 .ova 文件，它只是一个 tar 归档。
对于其他格式，构建会产生单独的文件。
它们可以使用选项 -z 打包到一个 7z 归档中。
还有一种 rootfs 类型：这不是镜像。
它只是一个 Kali Linux 根文件系统树，不包含内核和引导加载程序，并打包在 .tar.gz 归档中。
主要用途是将其作为构建操作系统镜像的输入来重用，不打算在构建系统之外使用。
在构建操作系统镜像时，建立一个缓存机制是很有用的，可以避免一次又一次地从互联网下载所有软件包。
为此，构建脚本会尝试检测可能在本地主机上运行的已知缓存代理。它首先参考本地 APT 配置 Acquire::http::Proxy。如果未设置，它会通过检查服务是否在其默认端口上监听来尝试检测 apt-cacher-ng 和 squid-deb-proxy。此机制不适用于 approx（一个知名的 APT 缓存代理），因为它是按需自动启动的。
要覆盖此检测，你可以自己导出环境变量 http_proxy。
但是，你应该记住构建发生在 QEMU 虚拟机内，因此构建环境中的 localhost 指的是 VM，而不是宿主机。
如果你想从 VM 访问宿主机，你可能需要使用 http://10.0.2.2。
例如，如果你想使用在机器上以端口 9876 运行的代理，请使用：export http_proxy=http://10.0.2.2:9876。
如果你想确保不使用任何代理，请使用：export http_proxy=。
或者，你可以设置一个本地镜像。
可以将构建分成两步。
你可以先用 ./build.sh -v rootfs 构建一个 rootfs，然后用 ./build.sh -r ROOTFS_NAME.tar.gz 基于此 rootfs 构建镜像。
例如，如果你计划构建多种镜像类型，这是有意义的。
当暂存区域已满（即 --scratchsize 值太低）时，构建可能会失败并出现此类错误消息：
[...]: failed to write (No space left on device)
[...]: Cannot write: No space left on device
解决方案：增大 --scratchsize 的值。
你可以在特殊字符 -- 之后将参数传递给 debos，因此如果你需要例如 50G，可以执行 ./build.sh [...] -- --scratchsize=50G。
在调试构建失败时，能够直接进入构建所在的 VM 中的 shell 是很方便的。
通过向 debos 提供选项 --debug-shell 可以实现：./build.sh [...] -- --debug-shell。
这是一个已知问题，请参阅 https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132 获取解决方法。