14.2 Recompiling the Kernel

Why You Usually Do Not Need to Recompile

The Kali team ships a custom-patched kernel precisely so you do not have to. The most important patch set for a penetration tester enables wireless packet injection — the ability for compatible Wi-Fi adapters to transmit crafted frames, which tools like aircrack-ng require. On a mainstream distribution you would have to patch and rebuild the kernel yourself to get reliable injection; on Kali it works out of the box. The stock kernel also tracks recent upstream releases because Kali is a rolling release based on Debian Testing, so hardware support stays current.

For the exam, the expected answer to 'should you recompile the kernel to get injection working' is no — Kali's kernel already includes those patches. Recompilation is reserved for edge cases:

• Enabling support for unusual hardware that the stock config leaves out
• Removing features to shrink the kernel for an embedded or ARM target
• Applying a very specific experimental patch
• Learning how the Debian kernel packaging works

Getting the Kernel Source

There are two canonical routes, and you should know both.

Route 1: apt source linux. With deb-src entries enabled (see Section 14.1), run:

apt source linux

This downloads the full Debian/Kali kernel source package — the upstream tarball plus all of Debian's packaging, patches, and feature sets — and extracts it with dpkg-source -x. Note the source package is named linux, not linux-image or linux-headers. This tree is large (well over a gigabyte extracted), so ensure you have disk space.

Route 2: the linux-source binary package. Install it like any other package:

sudo apt install linux-source

This drops a compressed tarball such as /usr/src/linux-source-6.x.tar.xz which you extract yourself:

tar -xaf /usr/src/linux-source-*.tar.xz -C ~/kernel-build --strip-components=1

Either way, you end up with a source tree you can configure and build.

Starting From the Running Configuration

Never configure a kernel from scratch. The running Kali kernel's build configuration is published at /boot/config-$(uname -r). Copy it into your tree as .config:

cp /boot/config-$(uname -r) ~/kernel-build/.config
make oldconfig

make oldconfig walks the copied configuration and prompts only for options that are new in your source version, letting you accept defaults for each. If you want to browse and change options interactively, use make menuconfig (needs libncurses-dev) or make xconfig. A related helper, make localmodconfig, disables modules for hardware not currently loaded — useful to shrink build time, risky if you later plug in new hardware.

Building With make deb-pkg

Because Kali is Debian-based, the correct way to build a custom kernel is not make && make install — it is the kernel's own Debian packaging target:

make deb-pkg -j$(nproc)

make deb-pkg compiles the kernel and modules, then packages them as .deb files written to the parent directory of the source tree. A typical build produces:

The -j$(nproc) flag parallelizes the compile across all CPU cores; even so, a full kernel build can take tens of minutes to hours depending on hardware. When it finishes, install the image and headers:

sudo dpkg -i ../linux-image-*.deb ../linux-headers-*.deb

Installing the linux-image package automatically builds an initramfs and updates the GRUB configuration via Debian's kernel hooks, so the new kernel appears in the boot menu. Reboot, confirm with uname -r, and keep the stock kernel installed as a fallback — GRUB's advanced-options menu lets you boot the old kernel if the new one fails.

Risks and Trade-offs

Running a self-compiled kernel changes your maintenance posture:

• No automatic security updates. APT will keep offering the stock linux-image packages, but your custom build never receives Kali's kernel patches. You must rebuild for every security fix.
• DKMS breakage. Out-of-tree modules (some Wi-Fi drivers, VirtualBox, ZFS) may fail to build against your custom tree if headers or configs diverge.
• Misconfiguration risk. Dropping a driver or a security feature (for example, disabling the wrong hardening option) can leave the system unbootable or less secure than stock.
• Support burden. Bug reports against custom kernels are yours to diagnose.

Verifying the Build and Rolling Back

After rebooting into the new kernel, verify three things before trusting it: uname -r shows your custom version string, dmesg is free of new hardware errors, and any adapter you rely on still injects packets (a quick aireplay-ng test on a lab network). If anything fails, reboot, open GRUB's 'Advanced options for Kali' submenu, and select the stock kernel — it remains installed because your custom linux-image package used a different version string rather than replacing the stock one. To remove the custom kernel entirely, purge it like any package:

sudo apt purge linux-image-<your-version> linux-headers-<your-version>
sudo update-grub

This rollback path is why building .deb packages with make deb-pkg beats a manual make install: the custom kernel stays a managed, removable package instead of untracked files scattered through /boot and /lib/modules.

Exam Angle: Commands and Rationale

The exam tests this topic at the level of workflow and justification, not kernel internals. Lock in this sequence and the reasoning behind each step:

1. Prefer stock — injection patches are already in Kali's kernel
2. apt source linux or sudo apt install linux-source to get source
3. cp /boot/config-$(uname -r) .config then make oldconfig
4. make deb-pkg -j$(nproc) to build Debian packages
5. sudo dpkg -i ../linux-image-*.deb and reboot, keeping the stock kernel as fallback

If a question frames recompilation as required for aircrack-ng or injection, that framing is the trap.