BackTrack Linux was and still is reputedly one of the best security-oriented Live Linux distributions out there, for both offensive and defensive purposes. Packed with tools and affirmed by near-universal acclaim, the veteran BackTrack has seen a whopping 7+ years of active development and explosive community growth.

Originally based on a merger of two earlier established distros, the Slax-based WHAX (formerly Whoppix) and a Knoppix-based LiveCD named Auditor Security Collection, BackTrack saw a switch to an Ubuntu-based system during its later life, mostly to benefit from its Aptitude package management system and wide driver compatibility. But now, faced with an aging tool management architecture for its penetration testing tools, parent company Offensive Security wants to try something new.

Enter Kali Linux. First announced and finalized just a month ago in March 2013, Kali aims to be a complete restructuring and replacing of BackTrack from the software perspective while keeping the philosophy, community, penetration testing options, and even much of the branding intact.

/pentest begone!

Kali’s creation was intended to address a few key points of criticism BackTrack has received over the years. Much of it stemmed from its unorthodox /pentest file hierarchy, a special set of folders used for organizing and storing all the pentesting-specific packages, which had been devised four years ago.

For a long while, the sorting of the hacking programs into categories seemed a rather simple and intuitive concept, and it was decently easy to locate existing binaries on the hard disk as well as install and integrate new ones. Besides, the structure allowed for the programs and their dependencies to remain separate from the system. Wanted to find Metasploit and all of its respective libraries? Just go to /pentest. Looking for the location of Nessus’ daemons? Go to /pentest. It was that simple.

However, this efficiency did not last too long. As BackTrack’s software count grew in size (and it certainly did), certain cases arose where the programs in question either fit into multiple categories or had such a generalized nature that they could not fit into any category. Where would they then be placed? A good example (taken from this Kali news post) was:

[W]hen does a tool go in /pentest, and when should it be placed in the $PATH ? Where should a tool like “sqlmap” be placed? Should it be in /pentest/web, or/pentest/database?

It summarizes perfectly my experiences during my first experience with BackTrack years back when the hierarchy was first released. I had to put up with an unclear, ambiguous file structure something like this:

/pentest        -- Root folder
   ...
   /database       -- Anything database-related goes here, whatever that means. Perhaps SQL injection stuff...
   /exploits       -- Metasploit and Nessus/OpenVAS, probably.
   /passwords      -- I guess password crackers go here.
   /telephony      -- Something to do with telephone communications?
   /voip           -- Wait, what's the difference between this and 'telephony'?
   /web            -- Maybe web pentesting frameworks? No wait, that would go under 'exploits', right?
   ...

In violation of the Filesystem Hierarchy Standard (FHS) adhered to on nearly all UNIX-likes, especially Debian Linux, these pentesting programs are placed in different folders than a vanilla installation, thus making them a hassle to find.

Kali Linux does away completely with the /pentest directory and instead has everything stored where it should be (/bin, /usr/bin/usr/lib, etc.), which is quite a relief for users and developers alike. Now that the filesystem is organized properly and the developers no longer need to maintain /pentest, the Kali development process is simplified dramatically.

Debian chosen as the new base

BackTrack has utilized three major distributions and package management systems as its base over the years: Slax, Knoppix, and (most recently) Ubuntu. Conforming to the FHS standard got them thinking about whether they should jump the Ubuntu ship and switch to something else, especially in light of recent changes such as Unity Next and Mir. After much deliberation, Debian was chosen as the new basis for Kali Linux because of:

  1. Very light system requirements.
  2. Its good reputation for security and stability.
  3. Backwards-compatibility with the APT package management system that Ubuntu shares.

Despite Debian’s different driver compatibility and definitely less than cutting-edge core repositories, the operating system is virtually unchanged from BackTrack, from the user experience point of view (thanks to Debian’s similarity to Ubuntu). The launcher menus’ layouts are nearly identical to BackTrack, the wallpapers and OS branding is largely the same but shifted from a red to a blue color scheme, and the pre-included tool spectrum is largely the same, albeit a bit more updated since BackTrack’s last release in 2012.

What do you think?

Overall, I’d have to say Kali Linux has got a lot going for it. I personally love BackTrack as a good penetration testing distribution that is fun to play around with. Mapping hosts, spoofing MAC addresses, messing about with shellcode – ah, so much fun! It is wonderful to see BackTrack get a system cleanup and a spiritual refresh from its earlier years.

I am quite pleased with the folks at Offensive Security with their new project and their commitment to stick with the community’s wishes and I might just migrate my LiveUSB and frugal installs over to Kali in the near future.

Are you a fan of BackTrack? Have you tried Kali Linux and do you like it?

Learn more about it at:

Kali Linux Homepage
Kali Documentation
Kali Community Page
Offensive Security Homepage

Advertisements

3 thoughts on “Kali Linux: A better BackTrack?

  1. About the /pentest/ issue, people don’t see the generality of how core linux is structured. It is pre-assumed, with the linux in mind that the files that has to be used by the users should be in /usr/bin directory, which are the executables in the form of .py scripts and other scripts, (even .sh). And when you go to these directories and “cat” out the context of the web analysis tool that you need to refer, you will find these tools will usually refer you to the /usr/share directory. So, yes, most of the pentest files are in /usr/share/ directory in Kali linux.

    Learn to *nix !

    1. It’s true. /usr/share is intended to store architecture-independent data files while /usr/bin is meant to store “ready to run” executables and system-specific shell scripts. Python, Ruby, Perl, and system shell scripts are inherently CPU-independent files (a Ruby script can run on 32-bit and 64-bit Linux, for example, unless it references any external CPU-dependent programs), and are thus placed in the /usr/share folder. A good example is nmap, whose executable is commonly stored in /usr/bin while its NSE scripts and OS fingerprinting databases are kept in /usr/share/nmap. Hope this makes sense.

      FHS – /usr/share
      FHS – /usr/bin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s