Building a customized Kali Linux image is not as complex as you may be thinking. It is easy, fun, and rewarding! Kali Linux traditionally, has been a Live Image, but since Kali 2020.1 an Installer Image was introduced. Both these images have different functions, and are also built in different ways.
You can configure virtually any aspect of your Kali ISO build, such as adding packages from outside of Kali network repositories, unattended installations to changing the default wallpaper. Our build-scripts provides a framework that uses a configuration set to automate and customize all aspects of building the images. The Kali Linux development team use the same build-scripts to produce the official Kali ISO releases.
Ideally, you should build your custom Kali ISO from within a pre-existing Kali environment, as there is less chance of items going wrong. However, it is possible to generate the images on a Non-Kali but still a Debian-Based system.
We are using the --verbose to output more on the screen rather than it being captured in just the build.log output. If you want even more output, you can use --debug instead, which will then give even more information.
If you want to customize your Kali Linux ISO, this section will explain some of the details. Through the kali-config/ directory, there are a wide range of customization options, which are well-documented for live-build page. Simple-CD is a little more limited with options. For the impatient, here are some of the highlights.
By default, these lists will includes the kali-linux-default metapackage, as well as some others. These can be commented out and replaced with a manual list of packages to include in the ISO for greater granularity.
With Live images, you have the option to include additional files or scripts in your build by overlaying them on the existing file-system, inside the includes.chroot,binary,installer directories, respectively.
For example, if we wanted to include our own custom script into the /root/ directory of the ISO (this would correspond to the chroot stage), then we would drop this script file in the kali-config/common/includes.chroot/ directory before building the ISO.
The Kali Linux i386 ISO has PAE enabled. If you require a default kernel for older hardware with PAE disabled, you will need to rebuild a Kali Linux ISO. The rebuilding process is much the same as described above, except that the 686-pae parameter needs to be changed to 686 in auto/config before building:
You often find that you are waiting on packages to be pulled down. You can either setup a local proxy on the same machine (such as apt-cacher or apt-cacher-ng). Alternatively, you can setup a local network mirror.
Formerly known as Backtrack Linux, Kali is known as a distro for pentest/hackers, so it was never really of interest to me. But I've recently read some articles where folks modify Kali at time of installation, effectively converting it to an everyday distro with rolling release schedule. Now THIS sounds interesting to me! Articles here, for reference:
Considered collectively, I LOVE the idea of a Debian-based distro with rolling release schedule, custom build-up like Arch (without the fine-grained control of Arch, but I don't need that granular level of control), with a healthy community built around a community-supported distro. And with the Kali devs maintaining the Debian Sid/Unstable updates, similar to what Manjaro does to Arch packages for Manjaro distro, this sounds like the perfect sweet spot for me and my custom-brewed Mimetic desktop. I've got Arch, Manjaro, and Siduction in VMs, as all fit my criteria of a rolling release distro with large user base, and community-controlled development. However, all are just a little too close to the bleeding edge for my tastes. I prefer leading edge over bleeding edge. I prefer Manjaro of those 3, as I think the additional layer of packaging/testing is a good thing, rather than bad. I don't care that a Manjaro package is 2-4 weeks older than its Arch counterpart; I'm interested in the extra 2-4 weeks to vet for stability. Coming from an Ubuntu LTS-only background, those packages are new enough for me. But if I can duplicate that model and still stay in the Debian family, that is even better, from my perspective!
I've already installed Kali in a VirtualboxVM (following tutorials above) and will be maintaining and testing to see how it goes, but I was wondering if anyone else had experience with Kali? Other than pentesting? I know we have some Siduction fans on here (sunrat?), so maybe they have thoughts too? In my ideal scenario, I would imagine that Kali is to Siduction as Manjaro is to Arch.
Well Kali is really only useful if you are a pen tester and need some tools preinstalled. Otherwise, it is kind of useless as you will end up spending more time removing stuff that you will never use before being able to actually do some work. The same tools are available on most distros anyway but are not preinstalled.
One of the reasons that Kali is popular is because lots of people think that it is cool or that they will magically become a hacker because they user kali. This becomes a major problem as these are the same people that do not know what they are doing and running a distro as root without a user account gets them into trouble fast. It is not even meant to be an installable distro.
Personally I would suggest a distro that is meant to be used by regular people and that supports actually being installed on hardware. Kali is only meant to be a live environment with security applications preinstalled. I do not even know if they actually have update repos or just updated isos.
At Debian forums a lot of people post about Kali, usually kiddie wannabe hackers. Its popularity rose with the Mr Robot TV series.They get sent back to the Kali forums which are reportedly not very kiddie friendly.
I've tested the Kali Raspberry Pi build with a small TFT touchscreen attached. The 3.5" screen from Adafruit is too small to make it really useable, but the Official 7" touch screen works nicely. The problem with touchscreens is you still need a keyboard for using the terminal. The suggested Linux virtual keyboards leave a lot to be desired from my usage. Perhaps they've improved in the last couple of years since I've used them. It might makea nice portable pentesting tool if that problem was solved for me.. We use it in our labs to teach students pentesting and security. And it looks cool when used in the TV series Mr. Robot.
I've been tinkering with the Kali distro, trying to morph it into an everyday driver. I've finally gotten it to a place where that is workable, but only time will tell us how stable. I must admit, it was a LOT of work, and there's some things that are still buggy, although not necessarily deal-killers. Inasmuch as I have to "undo" some of Kali's configs & conventions, I'd agree with others that there are better choices of Debian distros to start from. To date, I have:
- installed with regular user, root access via sudo; sudo works fine, but too many other programs are cofigured for root access, not regular user; user/group permissions require a LOT of tweaking...still not sure I have them all
- installed LXDE desktop; pulls in a combination of LXDE and LxQT tools...don't like that setup. took forever to figure out MY preferred tools weren't working because invisible LxQT programs/service are running in session
- installed some extras, such as samba, avahi, xfce4 notifications; not sure if needed, but couldn't install printer because couldn't find service; once I solved that, couldn't find printers, so looked into smb.conf; like peeling an onion
- no sound in virtualbox; turns out its a common problem on hardware too; one of Kalis mottoes is "the quieter you are, the more you can hear", so not sure if sound is silent on purpose, or if this is another artifact of the regular user vs root setups; eventually solved by purging and reinstalling PulseAudio, various PA tools, and ALSA and performing some systemctl incantations, and then discovering that Kali boots with ALSA in the muted state. It doesn't appear to be in the ALSA Mixer, but if I toggle the mute ON, then toggle OFF...I have sound. This must be performed every time at boot, if I want sound. I'm sure it's a an ALSA setting somewhere...
- I like desktop notifications and wanted to see how Kali would notify of updates. I could not get xfce4-notifyd to work, nor even configured, as no changes would "stick"; I started to suspect another regular user vs root issue and, sure enough, "sudo xfce4-notifyd-config" allowed the root user to make desired changes regarding notification placement, appearance, timeout, fade, etc... Went looking in user/group permissions and added my user to more groups, but still no change; long story short, lxqt-notifications was running as daemon in background, causing xfce4-notifications to act quirky. What a weird way to do that. LXQT is a desktop choice, as well as LXDE, and I chose LXDE for a reason...don't appreciate the LXQT tool in LXDE. I've never seen that before...didn't even know LXQT had its own notification system. Removed lxqt-notifications and autostarted xfce4-notifyd and tested system with "notify-send 'TEST'" messages and everything behaves as expected now.
- I've also looked for some other software in the Kali repos, but Kali repos aren't nearly as stocked as Debian. Gnome-software is terrible in Kali. No Software Center is available, but at least Synaptic is there. No software updater though. I looked into adding Debian PPAs, but Kali forums are littered with posts admonishing users NOT to add PPAs to Kali, as it WILL break your system at some point. If Kali doesn't have a package I want, and I can't add a PPA, I'm not sure it's worth the trade-off to have Kali manage the updated software in their rolling repo.
- I've also learned their forum is disappointing. Kali is designed as a hacker/pentest distro, so its no surprise their forum primarily consists of hacker/pentest issues. However, while they seem to be attempting to expand their userbase with everyday distros (KDE, Gnome, LXDE, LXQT, XFCE flavors, etc...) and allowing installation, and non-root access, etc... their forums haven't caught up yet. Most of my troubleshooting solutions came from Debian forums and....wait for it...ArchWiki!
d3342ee215