Properly installing and configuring Kali Nethunter on an android-based mobile device might seem easy at first. Installing the NH store as well as the various applications it offers, after all, is a piece of cake—even on a device that isn’t rooted. The unfortunate reality is a lot of the functionality offered by Nethunter requires a lot more effort than installing a few APK files. In most cases, it’ll be necessary to unlock the bootloader, install custom recovery, root the device, flash a custom kernel, flash a kali chroot specific to your device’s architecture + wireless firmware, disable verity & force-encrypt, and tweak a handful of configurations on the command line.
This post offers insight into that process. It’s not really a tutorial as each and every android device is different, and the truth is your mileage will vary based on the hardware found within your device. It is written in a noob-friendly way. Think of it as a guide to reference. The goal is to understand the bigger picture and clear up some common mistakes. I’ll be using the hardware below in this post. Part 2 will go into the nitty-gritty details of compiling a Wi-Fi driver with custom kernel headers.
| Hardware |
Make / Model |
Chipset |
Driver |
| Mobile Device |
Google Pixel 4a / Sunfish |
Snapdragon 730G SoC |
(built-in) |
| External Wi-Fi |
Alfa AWUS036NHA |
Atheros AR9271 |
ATH9K_HTC |
| External Wi-Fi |
Linksys WUSB6300 V2 |
Realtek RTL8812BU |
88x2bu |
| USB-C OTG Y-Cable |
Anker Powerline+ |
— |
— |
The end game should look something like this:
Alfa adapter in monitor-mode test
Airodump-ng capture in progress
Kali chroot
The purpose behind Kali Nethunter is to port Kali Linux and its tool-set to mobile devices. This is achieved by installing a copy of Kali on the device in what is known as a chroot, along with other modifications enabling these devices to utilize the tools, internal, and external hardware in ways outside the norm. You can think of Nethunter (and its applications) as a means of communicating with and configuring the Kali chroot on Android.
Chroot stands for change root, and is a standard operation found on Unix and Unix-like operating systems, allowing commands and processes to run in a modified environment. Any commands or processes within the chroot environment will not have access outside of it, and for this reason it is often called a chroot jail. You may have heard the term “jailbreaking” in the context of Apple iPhone devices. That process refers to exploiting the system hardware/software to break free of the chroot jail which all Apple iPhones place on end users.
Unlike this example, the goal here is to create a chroot environment into which Kali can be installed. To get full functionality, the device should be rooted. However, with that said, it is still possible to create a chroot environment for Kali without being rooted—just expect a lot of lost functionality.
That’s not a typo. Before moving forward, it’s a good idea to understand the device you are working with. This can be achieved using Google, but the best way is to get the information directly from the device itself.
It is highly recommended you flash a stock ROM if you are currently using a custom one. If headstrong on using a custom ROM, you’ll want to do a bunch of homework ahead of time. Chances are if it’s not AOSP, things will break.
To start, download a copy of Termux. Don’t use the Play Store—the version found there is deprecated and you’ll end up pulling your hair out. There are two reputable sources you can safely obtain an updated copy of Termux:
I recommend turning Google Play Protect off during installation. When you open the APK, you’ll likely be asked to enable installations from unknown sources as well as grant your browser or file manager permission to install the APK. Just attempt to install it; Android will prompt for the required permissions.
III. Termux CLI
You’ll notice both apt and apt-get work in Termux, but sticking to the pkg wrapper keeps things cleaner and prevents mixed-repo headaches. My two cents.
Run a quick hardware scout:
getprop ro.product.cpu.abi
arm64-v8a # CPU architecture
getprop ro.product.name
sunfish # Product code-name
getprop ro.build.version.release
12 # Android version
Armed with that info, let’s prep the device itself.
Android Developer Options
Navigate to Settings → About Phone → Build Number and tap it seven times. You’ll see a toast counting down until Developer Options are enabled.
Inside Settings → System you’ll now find Developer Options. Toggle:
- OEM Unlocking (if offered)
- USB Debugging
- Under Networking → Default USB Configuration, choose File Transfer / Android Auto
- (Optional) Disable Verify apps over USB and Verify bytecode of debuggable apps—they sometimes interfere with Magisk patches.
On your host computer, install ADB and Fastboot:
- Debian / Ubuntu:
sudo apt install android-tools-adb android-tools-fastboot
- macOS:
brew install android-platform-tools
- Windows: grab the minimal ADB & fastboot package from XDA or Google’s SDK platform-tools.
Quick sanity check:
adb devices
If the phone prompts for trust, accept; your serial should appear.
Unlocking the Bootloader
Every manufacturer is different—some hand out unlock codes, others hide test-points on the PCB—but Pixels are straightforward:
adb reboot fastboot
fastboot flashing unlock
NOTE: Depending on the device manufacturer, or even the device itself, this step is not always so cut and dry. To even attempt to discuss all the different bootloading unlock methods would be implausible. Some devices, like my LG Thinkq G7 can’t seemingly have its bootloader unlocked, as LG had a webpage to request the unlock codes however that service no longer exists. There are methods to modify your phone in these cases (such as flashing crossed firmwares, or unlocked firmwares), but it extends this article. It’s important you check how to unlock your bootloader for your specific device make and model.
WARNING: unlocking wipes userdata; back up first.
Booting Custom Recovery (TWRP)
Boot, don’t flash, the image first:
fastboot boot twrp-3.7.0_12-sunfish.img
Reasons to boot before flashing:
- If it soft-bricks, a normal reboot fixes it.
- Slot-A/B devices can be weird—booting lets you pick the correct slot later.
- You can flash TWRP from within TWRP once you know it works.
Inside TWRP: Advanced → Flash current TWRP. Now recovery persists across reboots.
Rooting with Magisk & Disabling dm-verity
Download and push everything beforehand:
| File |
Purpose |
| Magisk v26.3 ZIP |
Root + Magisk Manager |
| Disable_DmVerity_FEncrypt.zip |
Turns off kernel verity & forced encryption |
| BusyBox arm64.zip |
Classic BusyBox utilities |
| Alynx12_Pixel4a_kernel.zip |
Custom kernel with USB dongle support |
| kali-arm64.zip |
Official Kali rootfs (sunfish) |
Inside TWRP choose Advanced → ADB Sideload, then on the host:
adb sideload Magisk.v26.3.zip
adb sideload Disable_DmVerity_FEncrypt.zip
adb sideload BusyBox_arm64.zip
Reboot system (not recovery). A warning splash will note the unlocked state; Android will optimize apps and boot. Install the Magisk APK (same ZIP, rename to .apk) if it hasn’t auto-installed. Open Magisk—both Magisk and MagiskSU should show Installed (26.3). Grant Termux root to confirm:
NOTE: Ensure ‘tsu’, which stands for Termux Super User is installed. You can install it by running the command ‘apt install tsu’. You will want to use tsu instead of the su binary.
tsu
id
uid=0(root) gid=0(root) groups=0 context=u:r:init:s0
IV. UID
Flashing a Custom Kernel
Stock Pixel kernels lack drivers like ATH9K_HTC and 88x2bu. Flashing Alynx12’s kernel adds:
- USB OTG charge-through quirks fixed
- Monitor mode & injection for AR9271 / RTL88xx
- WireGuard, full iptables, HID gadget patches
Back in TWRP:
adb sideload Alynx12_Pixel4a_kernel.zip
Reboot system again; root and dm-verity stay intact.
Installing the Kali RootFS (chroot)
The NetHunter Store offers a GUI installer, but manual flashing guarantees the proper architecture.
Boot to TWRP.
System → Mount / data.
ADB Push the Kali tarball:
adb push kali-arm64.tar.xz /data/local/tmp/
In TWRP’s Terminal:
mkdir -p /data/local/kali
tar -xJf /data/local/tmp/kali-arm64.tar.xz -C /data/local/kali
Still in Terminal, bind-mount essentials so the rootfs can reach Android’s kernel interfaces:
mount -o bind /dev /data/local/kali/dev
mount -o bind /proc /data/local/kali/proc
mount -o bind /sys /data/local/kali/sys
Chroot in:
chroot /data/local/kali /bin/bash
If you see root@kali-arm64:~#—mission accomplished. Update & install NetHunter meta-packages:
apt update && apt full-upgrade -y
apt install kali-linux-nethunter -y
External Wi-Fi Validation
Plug the Alfa NHA into the powered OTG Y-cable—your phone battery will thank you. In Termux (with su):
dmesg | tail
ip link set wlan1 up
airmon-ng start wlan1
airodump-ng wlan1mon
You should see channel-hopping and beacons. Repeat for the RTL8812BU after modprobe 88x2bu. If the Realtek dongle fails, confirm the kernel module loaded:
lsmod | grep 88x2bu
- NetHunter-Kex: full XFCE desktop via VNC—install with
apt install kali-win-kex.
- HID Keyboard attacks: NetHunter App → HID – push scripted keystrokes to victim PCs.
- BadUSB: emulate network adapters for reverse shells.
- USB-OTG Y-Cable Tweaks: enable Disable USB charging in Developer Options to avoid power-draw brown-outs during heavy packet injection.
Common Pitfalls
- Bootloops after flashing Magisk → Forgot to disable verity & force-encrypt. Re-flash Disable_DmVerity.
- No Wi-Fi dongle power → Cheap OTG cable; use a powered hub or Y-cable.
- Chroot segfaults → Wrong rootfs architecture. Re-download the correct
kali-arm64 or kali-armhf.
- Magisk app hidden after reboot → Enable Zygisk inside Magisk, then Re-install Magisk app from settings. Pixel 4a sometimes hides the stub.
Legal & Ethical Reminder
If you stick antennas and Alfa stickers on your phone, congratulations—people will assume you’re the villain in a hacker movie. Only audit networks you own or have explicit written permission to test. Unauthorized interception of traffic is illegal in most jurisdictions. Logs live forever; don’t give future-you a courtroom headache.
Conclusion
With an unlocked bootloader, TWRP recovery, Magisk root, a hardened custom kernel, and the Kali chroot in place, your Android has gone full-send from consumer gadget to pocket-sized penetration-testing workhorse. Part 2 will dive into compiling Wi-Fi drivers against your own kernel headers, enabling SDR on the Pixel’s USB-C port, and automating NetHunter updates via Termux-API scripts. Stay tuned—and hack responsibly.