14.1 Modifying and Rebuilding Kali Packages

Why Rebuild a Package Instead of Installing From Source

Everything in Kali is a Debian package, and Kali is FHS (Filesystem Hierarchy Standard) compliant, so the cleanest way to change a tool is to modify its package and rebuild it rather than compiling from an upstream tarball and scattering files across /usr/local. A rebuilt package stays under package-manager control: it can be upgraded, removed, and tracked with dpkg. On the exam, you are expected to know the exact toolchain for this workflow, because it is the foundation of all Kali customization.

A Debian source package is not a single file. It is a set of related files:

• A .dsc file — the control file that names the package, its version, its checksums, and its Build-Depends (the packages required to compile it)
• An .orig.tar.* file — the pristine upstream source tarball
• A .debian.tar.* file (or .diff.gz for older formats) — the packaging layer containing the debian/ directory with build rules and patches

The binary .deb you install with APT is produced from this source package. Rebuilding means repeating that production step yourself after making changes.

Enabling Source Repositories with deb-src

Kali's default repository configuration carries only a binary package line — /etc/apt/sources.list on pre-2026.2 systems, /etc/apt/sources.list.d/kali.sources on newer ones:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

To download source packages you must add a matching deb-src entry:

deb-src http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Then run sudo apt update so APT downloads the source indexes. If you skip this, apt source fails with an 'Unable to find a source package' style error — the single most common exam trap in this topic. The deb-src line must reference the same suite (kali-rolling) and components as your deb line.

Downloading and Extracting the Source

With deb-src enabled, fetch a source package into the current directory:

apt source airbase-ng

You do not need root for this step, and you should not do it as root — build trees belong in your home directory. APT downloads the .dsc, the orig tarball, and the debian tarball, then automatically extracts them by invoking:

dpkg-source -x package_version.dsc

The result is a ready-to-edit tree such as aircrack-ng-1.7/ containing the upstream source plus the debian/ packaging directory. You can also run dpkg-source -x by hand if you downloaded the files separately; -x means extract, and it applies any patches listed in debian/patches/ automatically for packages in the 3.0 (quilt) format.

Installing Build Dependencies

Before you can compile, install everything the package needs at build time:

sudo apt build-dep aircrack-ng

apt build-dep reads the Build-Depends field from the source package's control information and installs the compilers, headers, and -dev libraries it names. This step does require root and does require deb-src entries, because APT needs the source index to resolve the dependencies. Missing build dependencies are the most common reason a rebuild fails, so the exam pairs apt source and apt build-dep constantly.

The debian/ Directory

The packaging layer lives in debian/ and every file there has a defined role:

Understanding this table matters because 'which file sets the package version' (debian/changelog) and 'where do downstream patches live' (debian/patches/) are exactly the kinds of details a multiple-choice question can probe.

Making Changes and Rebuilding

Once the tree is extracted and dependencies are installed, make your change. For a quick hack you can edit upstream source files directly. For a cleaner approach that survives re-extraction, add a patch to debian/patches/ and list it in debian/patches/series. Before building, bump the version with a local suffix so APT can distinguish your build from the official one — the convention is dch --local <suffix>, where the suffix is mandatory: dch --local kali turns 1.7-3 into 1.7-3kali1. Editing debian/changelog by hand does the same job.

Build the package from the top of the source tree:

cd aircrack-ng-1.7
dpkg-buildpackage -us -uc -b

Each flag has a specific meaning you should memorize:

• -us — do not GPG-sign the source package (unsigned source)
• -uc — do not GPG-sign the .changes file
• -b — binary-only build: produce .deb files but skip building the source package

Signing is skipped because you do not hold Kali's archive keys; your local packages do not need signatures. The finished .deb files are written to the parent directory (one level above the source tree), not the current directory — another detail examiners love. Install the result with:

sudo dpkg -i ../aircrack-ng_1.7-3kali1_amd64.deb

or sudo apt install ./package.deb, which also resolves dependencies. To stop APT from overwriting your custom build on the next upgrade, use sudo apt-mark hold <package> or version pinning.

When You Actually Rebuild

Rebuilding is the right tool in a handful of concrete situations:

1. Patching a tool — applying an upstream bugfix or a feature pull request that Kali has not packaged yet
2. Version bump — rebuilding at a newer upstream release before Kali's maintainers publish it (remember Kali is rolling, so the gap is usually short)
3. Changing compile-time options — enabling a disabled configure flag or driver support
4. Customizing metapackages — the flagship example below

Worked Example: Rebuilding kali-meta

The kali-meta source package builds the metapackages that define Kali's toolsets: kali-linux-core, kali-linux-headless, kali-linux-default, kali-linux-large, kali-linux-everything, and the kali-tools-* and kali-desktop-* families. A metapackage contains no software itself — only dependencies. To customize a default install you clone or fetch the kali-meta source, edit the dependency lists in debian/control (adding or removing tools for kali-linux-default), bump the changelog, and run dpkg-buildpackage -us -uc -b. Installing your rebuilt kali-linux-default .deb then pulls in exactly your chosen toolset. This is the same mechanism live-build package lists rely on, which connects this section directly to custom ISO building.

Common Traps Recap

• apt source fails → you forgot the deb-src line or apt update
• Build fails immediately → you skipped sudo apt build-dep
• Cannot find the .deb → look in the parent directory, not the source tree
• APT downgrades your patched tool → you did not hold the package or use a local version suffix