6.4 ARM Installations
Key Takeaways
- Kali publishes prebuilt, device-specific images for ARM single-board computers — there is no installer ISO for boards like the Raspberry Pi (the arm64 installer ISO targets UEFI ARM machines such as Apple Silicon VMs)
- Images come in arm64 (64-bit) and armhf (32-bit hard-float) variants matched to the board
- Write images to SD cards with dd/xzcat, balenaEtcher, or Raspberry Pi Imager, exactly like writing the amd64 ISO to USB
- Each device needs its own kernel and bootloader (usually u-boot), which is why one image cannot boot every ARM board
- First boot uses the kali/kali credentials, the root filesystem should be expanded to fill the card, and network services like SSH stay disabled until you enable them
6.4 ARM Installations
Quick Answer: Kali supports a wide range of ARM single-board computers — the Raspberry Pi family being the most popular — through prebuilt, device-specific images, not an installer. Download the image that exactly matches your board, write it to a microSD card with dd or an imager tool, boot it, log in as
kali/kali, and expand the root filesystem to fill the card.
Kali's ARM support is one of its distinguishing features: a pocket-sized Raspberry Pi running Kali makes a portable drop box, a wireless assessment platform, or a cheap sensor. But the ARM world works differently from the PC world, and the differences are exam material.
No Installer ISO for ARM
On amd64 you boot an ISO and run an installer. For ARM single-board computers there is no installer ISO — Kali instead publishes ready-to-boot images, each built for one specific device or device family. The reason is architectural: a PC has standardized firmware (BIOS/UEFI) and a generic kernel can find the hardware, but every ARM board has its own boot chain. Each board needs a device-specific kernel and bootloader — usually u-boot — plus the right device tree describing its hardware. One generic image cannot boot every board, so Kali's ARM page lists images by device: Raspberry Pi models, and various other supported boards.
When you download, match two things:
- The exact device. An image for one board family may not boot a different board, even from the same manufacturer. Download the image that names your device.
- The architecture variant. Kali offers arm64 (64-bit) builds for boards with 64-bit processors and armhf (32-bit ARM hard-float) builds for older or smaller boards. Modern Raspberry Pi models run the arm64 image; legacy models need armhf.
As with the amd64 ISO, verify the image's SHA256 checksum against the published value before writing it.
Writing the Image to a microSD Card
The images are distributed compressed (.img.xz). Writing one is the same raw-copy operation as writing the amd64 ISO to USB, and the same tools work — balenaEtcher on any platform, Raspberry Pi Imager on Raspberry Pi hosts, or dd on Linux/macOS:
xzcat kali-linux-2026.2-raspberry-pi-arm64.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
Here xzcat decompresses the image to standard output and pipes it straight into dd, so you never need the multi-gigabyte uncompressed file on disk. The dd safety rules from section 6.1 apply with full force: identify the card with lsblk, write to the whole device (/dev/sdX or /dev/mmcblk0), never a partition, and double-check the target because dd will happily overwrite your laptop's drive. Use a card of at least 16 GB from a reputable brand; SD card quality is the single biggest reliability factor on Pi builds.
First Boot and Expanding the Root Filesystem
Insert the card, connect power (a proper 5V supply — underpowered Pis corrupt cards and crash mysteriously), and the board boots straight into Kali. Log in with the default credentials kali / kali, the same non-root model as the desktop images since 2020.1.
The image is sized to be as small as possible for fast downloads, so the root partition occupies only a few gigabytes regardless of card size. On recent Kali ARM images the root filesystem expands to fill the card automatically on first boot; on older images you grow it manually — extend the partition with a partitioning tool, then grow the filesystem into the new space:
sudo resize2fs /dev/mmcblk0p2
(resize2fs can grow a mounted ext4 filesystem, so this works on the running system; the partition itself must already have been enlarged first.) Check the result with df -h / — you should see the full card capacity.
ARM-Specific Caveats
These differences from the amd64 world are the facts that tend to be tested:
- Per-device kernel and bootloader. Upgrades come through Kali's packages like anywhere else, but the boot chain is u-boot plus a board-specific kernel, not GRUB. Do not expect the amd64 GRUB/MBR discussion to apply.
- No live mode, no installer. The image is the installed system. There is nothing to click through; configuration happens after first boot.
- Network services are off by default. As on all Kali images, SSH and other services are disabled until you start them. To enable SSH persistently:
sudo systemctl enable --now ssh— change the default password first. Host keys are not baked into the images: since Kali 2022.1 theregenerate-ssh-host-keyssystemd service creates them on first boot if they are missing, so verify they exist rather than assuming every copy of the image shares one. - Headless operation. Many ARM deployments run without a display. You can configure Wi-Fi credentials and enable SSH by editing files on the card's boot partition from another machine before first boot.
- Performance expectations. An SD card is slow storage and a Pi has modest RAM. The default toolset runs fine, but treat heavyweight tasks — big password-cracking jobs, full desktop plus Burp — with realistic expectations, and prefer the arm64 images on boards that support them.
Once expanded and updated (sudo apt update && sudo apt full-upgrade -y), the ARM system pulls from the same signed kali-rolling repositories as any other Kali install, so the toolset is identical — only the boot process and hardware support differ.
What is the correct way to deploy Kali Linux on a Raspberry Pi?
Why does Kali publish a separate image for each supported ARM device instead of one universal ARM image?