What should be done about the outdated and undeveloped packages?

[ratch3t]

I am comparing BackBox and Kali currently. In both communities I have seen a lot of outdated tools/packages.

As I peruse through the tools to learn more about them and check out some of the source code, some are over 3 years old, not fully developed, or link to malicious sites.

I am curious as to iff all the tools listed are distributed with Kali, is there some sort of "clean up" or poking dead repo's with a stick test?

I understand I could very well just ignore these tools when working but, I would hate to think of the bloat, potential harm and confusion just throwing everything into the distro could cause.

Let me know if there is something I'm missing, thanks.

[sk00ma]

To answer, you questions:

1) Don't think of the pre-installed of tools as "bloat"

Instead think of them as "a reminder of how much you still don't know". The tools in kali have been hand-picked by security experts who know what and why and when to use. The reason every single tool is there is because at some point during a pentest, a real expert needed one of those tools. If you know an exact reason why you don't need a specific program, and are confident that removing it will not impact the host - by all means delete it.

Downplaying the awesomeness of any single tool just because you never heard of them (or even worse - if you don't have any use for it) is a bad idea that will get you nowhere.

2) The date of the tool creation has nothing to do with the value of the tool.

A scenario: A Windows XP vulerability is found in 2006. An exploit attacking that vulnerability is published in 2007. It's 2016, and you find a Windows XP machine with that vulnerability from 2006. You take the exploit you used in 2007, fire it up and it works. It works because the same Windows XP version is running the same code, so the attack code must be the same. Because of this you can find some really old tools in the kali repo's - it's because they get the job done. (Take a look at tool called ""Brutus" - it's super old, but works better then some of the "darknet" equivalents)

3) Libraries, dependencies and system stability

Managing all packages for a distribution isn't easy, especially so when dealing with attack tools. As you said, some of the tools are not finished or outdated, but it's all for the sake of delivaring a reliable quality of overall system. An example: Alice wrote a tool that cracks any FTP server with version 1.2.3. She used some very specific libraries and packages to get the magic of the exploit going. Time goes by and owners of libraries that Alice use develop patches and code that alice uses changes. Exploit no longer works if you upgrade. Now Alice has to use a specific version of an outdated dependency package.

Having all software all of the very latest is risky (although not inherety bad), and there is a chance your prograbs will crash horribly, when you least expect them to. Would you rather spend time learning about how the tool works, or about why the tool is not working...

Bottom Line:
As you outlined - learn the tools. Find out what they do, and when a pentester would need to use it. Understand the capabilities of the tools and practice using the tools in a simulated environment (for example give Maltego Teeth a try on a safe network).

At the end of the day, you will face a situation where you need to do [X]. The only way to do anything in a computer is by using a tool. You can't write the tool to do [X], so you need to get an existing one. And this is where we come to your main question - why are there so many tools, old and new.