Over the past few weeks, I have tried out Ubuntu, Manjaro, openSUSE and the latest Raspberry Pi OS release on the Raspberry Pi 4. I am going to complete this series with a look at Kali Linux, one of my favorite specialist Linux distributions. Kali is specifically made for security analysis and penetration testing, and is preloaded and configured for that purpose. The combination of the inexpensive and portable Raspberry Pi hardware and the Kali Linux distribution has seemed extremely promising to me for several years now, but so far it hasn’t really fulfilled my expectations. Hopefully the more powerful Raspberry Pi 4 and the more mature Kali Linux 2020.4 will remedy that.
Kali Linux for the Raspberry Pi can be downloaded from the Offensive Security ARM Images web page (not the main Kali Downloads page, although there is a link to the correct page there). There are four download images there:
- A 32-bit image which will run on all versions of the Pi 2, 3, 4 and 400
- A 64-bit image which will run on the Pi 2v1.2, 3, 4 and 400
- An image specifically for the Pi Zero and Zero W
- An image labelled ‘Kali Linux RPi’
These are all xz compressed images each about 2GB, which can be expanded and copied to a microSD card with this command:
xzcat kali-linux-2020.4-rpi4-nexmon.img.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress
As always, carefully replace /dev/sdX with the actual device name for your SD card device.
These images uncompress to about 9GB, so you will need at least a 16GB microSD card, and if you are going to do any serious work with it you will almost certainly need an even larger card.
Keep in mind that the image will be written to the card with an 8.5GB root filesystem, and that will be expanded to fill the free space on the SD card during the first boot. So if you want to have a separate home or work partition, you should set that up on the SD card (using gparted or some such partition manager) before booting the first time.
Unlike most other Raspberry Pi Linux distributions, there is no “initial setup/configuration” dialog during the first boot, it just comes right up to the login screen. The default credentials are kali/kali, so once you login with that the all-important first step is to change the password (duh).
Kali Linux 2020.4 on a Raspberry Pi 4.
Image: J.A. WatsonBecause there is no first-boot configuration script, there are a few other things which need to be done manually. None of these are terribly difficult or complex, but they go beyond what is normally necessary for a “user-friendly” (hand-holding) distribution. If you are advanced enough to use Kali (or attempt to use Kali), you should be used to this, or get used to this. If you are just starting out with Kali, I would strongly suggest getting the book Kali Linux Revealed, which can be downloaded from the given link, or if you are a truly dedicated geek like me, purchased in paperback.
First, I verified that the root filesystem had been extended to fill the free space (see screen shot at right), then I copied the contents of /home to the new filesystem, and added a line to /etc/fstab to mount it on boot.
If the desktop wallpaper is not filling the entire display (there is a black band around the edge), go to the file /boot/config.txt and uncomment the line that says
disable_overscan=1
Then reboot, and the image should fill the screen.
If you are using anything other than a US Ascii keyboard, the layout has to be changed. There are two ways to do this: for the GUI-desktop only, go to the desktop menu Settings / Keyboard / Layout, un-check “Use system defaults” and then choose the correct layout in the box at the bottom of the window. To make the change system-wide, including the text-only virtual consoles, edit the file /etc/default/keyboard, and change the value for XKBLAYOUT to the correct value (for example, “de” for German, or “ch” for Swiss German). This change only takes effect after a reboot.
The other thing that I find worthwhile to manually configure is the local timezone. This defaults to UTC, which certainly isn’t correct for Switzerland. I don’t see a way to change this in any of the Settings menu items or the Settings Manager utility, so I just used the command line to change it:
sudo datetimectl set-timezone Europe/Zurich
The value you give has to correspond to an entry in /usr/share/zoneinfo.
After getting this bit of configuration done, I took a closer look at the desktop and applications installed. This is an XFCE (4.14) desktop, with the menus extensively customized for the Kali distribution. The main menu contains the most useful security and penetration testing tools, and the “traditional” xfce menu has been moved to the “Usual Applications” sub-menu.
The default web browser is Firefox ESR, and my first impression is that it starts very quickly for a Raspberry Pi system – even for a Pi 4, in fact. Again, it has been customized for Kali, with a bookmark toolbar containing a useful group of items. I actually used Firefox on the Pi 4 to write portions of this post, and the performance was very good, with none of the lagging or difficulty that I have experienced on earlier Raspberry Pi / Browser combinations. The only problem I ran into here was that audio doesn’t seem to work, which I had already come across with openSUSE on the Pi 4, so I assume this is a more general problem that is likely to be fixed in a future release.
The default terminal emulator in the Favorites section is QTerminal, which is typical for an xfce distribution; but looking in the Usual Applications / System list, I see that the QTerminal drop-down is there, which I prefer so that there is always a terminal available on the F12 key, and UXTerm and XTerm are also included.
A quick check with uname -a shows that the Linux kernel is 4.19.118, and the 32-bit architecture is identified with armv7l.
SEE: An IT pro’s guide to robotic process automation (free PDF) (TechRepublic)
With the 32-bit version working very well, I decided to move on to the 64-bit version. Download, copy to microSD and initial boot were all identical to the 32-bit process. The difference in architecture can be confirmed with uname -a, which says aarch64 this time.
I went through the same checks and tests as I had done for the 32-bit version, with mostly the same results – but two significant surprises. First, keyboard layout configuration is inconsistent. Simply changing the system default in /etc/default/keyboard does not produce the correct layout in the desktop GUI; going to Settings / Keyboard and changing the layout there works, but only until the next reboot; but adding the desired layout twice in the Keyboard Settings causes the setting to be retained across reboots. I know that sounds weird, but I have tried this several times, in several different ways, and it is always like this – and only on the 64-bit version. Very weird.
The second difference, and the much more pleasant one, is that audio works in Firefox! Again, I have tried this several ways, and bounced back and forth between the 32-bit and 64-bit versions, and it is consistent – no audio in the 32-bit version, but it works in the 64-bit version.
With testing done on the Raspberry Pi 4, I moved on to the Pi 400. I took the microSD card with the 64-bit distribution and put it in the Pi 400, and it booted right up. That’s already good news, because at least one of the other Linux distributions I have tested didn’t boot in the 400.
Running through the same few tests as I had done on the Pi 4, everything seemed to be OK, including audio working in Firefox. When I checked the configuration, I found two differences. The first was puzzling, but not particularly serious – the keyboard layout is correct, with none of the quirks that I struggled with on the Raspberry Pi 4. I have no explanation for this, but as long as it works, I don’t particularly care.
Second, and much more serious, the wireless networking adapter is not detected on the Raspberry Pi 400. This worked perfectly on the Pi 4, but it simply doesn’t show up on the Pi 400. There is no wireless adapter or wireless networks shown in the drop-down from the Network Manager applet, there is no wireless adapter shown in the ip address output, there is no wireless device shown in the rfkill output, and there is no wireless adapter shown in the lshw output. (Interesting note: lshw is not installed by default, but it can easily be installed on the 64-bit version with sudo apt install lshw, but not on the 32-bit version – apparently it isn’t in the 32-bit repositories but it is in the 64-bit repositories.) I spent quite a lot of time trying to figure this out, with no success: apparently there is some sort of hardware difference between the Pi 4 and the Pi 400, but I can’t figure out what.
Shutting down and switching from the 64-bit card to the 32-bit card produced results that were consistent with what I have seen so far – it boots and runs, performance is good overall, but Wi-Fi doesn’t work, and there is no audio output.
The results from these tests on the Raspberry Pi 4 and 400 were good (well, except for the Pi 400 Wi-Fi), and the Kali download page says that these images should work on the Pi 3, so I decided to give that a try too. Both the 64-bit and 32-bit version boot and run on any Raspberry Pi 3, and the performance is, at least initially, not bad. It is noticeably slower than the Pi 4, of course, but that is to be expected. The problem comes when you start to run applications – even trying to do something fairly trivial such as display a web page, the system bogs down dramatically, and if you load it a bit more, it simply stops. I strongly suspect the problem is that these Raspberry Pi models have only 1GB of memory, and this problem is compounded by the fact that Kali doesn’t allocate any kind of swap space, so once the system starts to run out of memory, well, you’re basically screwed.
I also tried the Raspberry Pi 2, just for completeness. It booted and ran, but obviously had the same limitations and problems that the Raspberry Pi 3 had, because of the 1GB of memory. As expected, the Pi 2v1.2 ran with both the 64-bit and 32-bit versions, and the performance actually wasn’t noticeably worse than the Pi 3; the Pi 2v1.1 would only boot the 32-bit version, but even at that the performance again was comparable to the Pi 3.
The last member of the Raspberry Pi family to test is the Pi ZeroW. This requires a different Kali image than the others, but it is about the same size, 2GB download and 9GB installed, so again, it requires at least a 16GB microSD card. This might be a bit more of a problem with the Pi Zero, simply because it is old enough and small enough that a lot of them are currently running with 8GB cards.
I used a 32GB card, and the initial boot process took a very, very long time processing the expansion of the root filesystem. It did eventually come up to the login screen (after something like 5 minutes), it was obviously still terribly overloaded, because it took an extremely long time to even register the keyboard input of the login name and password, and after getting through that, it took several more minutes for the desktop display to come up and be ready for use.
SEE: Raspberry Pi 400: Its designer reveals more about the faster Pi 4 in the $70 PC’s keyboard
I didn’t want to be unfair to the Pi Zero, so I shut it down and powered off, and then booted it back up so I could time the boot without the process of expanding the root filesystem. On the Raspberry Pi 4, it takes approximately 30 seconds from power on to the login screen, but on the Pi ZeroW that took about 3.5 minutes. That’s not promising. It took another 5 minutes after entering the login info before the desktop finally came up and was useable. For me, this is very firmly in the “I can’t use anything this slow” category.
I was curious as to why and how the performance could be this bad, so I spent some time investigating. As best as I can tell, the primary problem is the simplest and most obvious one – the CPU is simply overloaded. Although it shows a very low CPU load when the system is idle (which it should, this means the system is not overloaded by the operating system itself), trying to run any application at all causes the CPU use to instantly peg at 100% and stay there. For example, the web browser included in this version of Kali is Midori (obviously because it is much lighter weight than Firefox), and trying to simply display the Kali Linux home page took more than three minutes, with the CPU statistics constantly showing 90%+ user time and 0% idle time.
The secondary performance problem is that the Pi ZeroW only had 512MB of memory, and this is simply not enough. Memory use statistics show that there is 10MB or less free memory even when the system is completely idle. Oh, and one other point about this, for the hard-core geeks who might be reading. The default configuration didn’t have any swap space at all, neither in a partition nor a swap file. I added a 2GB swap partition and activated it, and although that didn’t make a noticeable difference in performance, I did see that when I was running the browser it started to use 150MB or so of the swap area. When I then disable the swap, it took a minute or so to do that, and then the memory use statistics were right back to 280MB used and 145MB allocated for buffers and cache, with only 5MB free.
So, to get to the bottom line. Kali Linux on the Raspberry Pi 4 and Raspberry Pi 400, with 4GB (or more) of memory, is a pleasure. It’s easy to install, it runs very well, and response time is good. There are a couple of minor glitches with sound and wireless networking, but those are very likely to be worked out before long. This system is really what I have been wanting/expecting since the first time I heard about a Kali Linux port to the Raspberry Pi family several years ago. Unfortunately, though, on systems with only 1GB of memory the situation is completely different – and that includes the Pi 4, 3 and 2. It boots and runs, but it is far too easy to slow to a crawl, or actually stop, by running applications that need too much memory. Finally, the Pi Zero/ZeroW family, with only 512MB of memory is, for me, unusable.
