Please bring back the /pentest folder

I don't know about most Kali users but I'm personally not a big fan of using the mouse and clicking stuff. I used to browse through the tools neatly classified in a neat tree structure under the /pentest folder. You had your passive recon tools, your web tools, your dns tools and so on. Arguably they're still classified in that neat menu but will all due respect... it's unusable in some situations. I have to dpkg -L {packagename} to see where I can find its confs. And that's only if I'm lucky and KNOW (or guess) the package name.

Or to give you only the most recent example... I went clickety-click to check out various tools and "hmm.. what does this tool do ?"

http://cl.ly/image/160i2K0M3O2D/Scre...25.34%20PM.png

There's a huge dump of stuff in /usr/share ;(

I am sure muts would have more to say, but I can tell you that is not going to happen. Also, with regards to /usr/share that's by design.

If you want to create a /pentest folder than I say go for it, but I would HIGHLY recommend against it.

Don't ph33r change, embrace it ;) I am sure at one point BT was "foreign" to you as well.

Please read this http://docs.kali.org/introduction/what-is-kali-linux with special attention to the FHS section. It may help shed some light.

Thanks

one of benefit FHS compliant is We will be able to call any tool from anywhere on the system as every application is included in the system path.

Quote:

---

Originally Posted by fl3xu5

one of benefit FHS compliant is We will be able to call any tool from anywhere on the system as every application is included in the system path.

---

I agree with fl3xu5, the FHS also allowing all Linux users to easily locate binaries, support files, libraries, etc. thats good idea to use in KaliLinux. for reference about FHS go HERE

# mkdir /pentest will create a directory named pentest in /, or
# mkdir ~/pentest will create a directory named pentest in your home '~' directory

if you are trying to find something then use the find command. For example

# find / -type f -name apache.pl to search for files, or
# find / -type d -name apache to search for directories.

you also have other basic commands such as # whatis # whereis # which # man # apropos # info # apt-cache search, and of course lets not forget # grep

Quote:

---

# time grep -ran apache.pl /usr/
/usr/bin/apache-users:18:New code base dirived from orginal code apache.pl v1.0 by Doc
/usr/bin/apache-users:69: print "\nUSAGE: apache.pl [-h 1.2.3.4] [-l names] [-p 80] [-s (SSL Support 1=true 0=false)] [-e 403 (http code)] [-t threads]\n\n ";
^C

real 0m8.873s
user 0m0.044s
sys 0m3.088s

---

have a read :- http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE18

some other good commands that may be quicker than 'find' are 'locate' and 'which'

ex:

Code:

---

eric@Mudvayne:~/easy-creds$ which ettercap
/usr/sbin/ettercap

---

Code:

---

eric@Mudvayne:~/easy-creds$ locate ettercap

---

find is good, just takes too long for me...

Guys, don't take offence but you are being a bit pedantic. I'm fully aware of FHS and its benefits. I'm just not entirely sure that its benefits outweigh the drawbacks. The main benefits of FHS are standardization and as a consequence better communication and integration for software running on a machine.
- Kali currently has a considerable amount of tools. Most of them not written with FHS in mind. ****, some of them are simple perl scripts (see the above example). More tools will surely follow
- A lot of them have their own small ecosystem and configs. Is Kali going to store all configs from all tools in the /etc/ folder ? /opt/etc/ maybe ?
- Are the maintainers going to require any submission to Kali linux to be FHS compliant from now on ? Have they reviewed all the current tools ?

I suggest that all tools that ARE compliant (ettercap mentioned above is a very good example) to be installed "system-wide". But all custom stuff to be placed in a separate folder.

And seriously, find and grep in the entire /usr/share to find something when in BT5 I just did 'pwd' ? That is when I actually used the GUI menu.

Jay, I couldn't agree more. Moving to Debian was the best thing that could ever happen to Backtrack, but stuffing in tools everywhere in the system "because it is FHS compliant" seems to me as something an enterprise would ask in order to use Kali as an official security tool.
Now it seems that things are thrown everywhere and it becomes mandatory to use the menu to find something. I don't know about pentesters around the world but, if you're using *NIX to work, you prefer the command-line since it gives you more scripting possibilities and better command tweaking. GUI-lovers should stick to Windows 8 haha :)

For the "embrace the changes" part, moving to Debian is a big one, and for the better (not better, excellent) choice. But still, I have a certain compulsive behaviour to get things organized by functionality, because at the end of the day you need prompt access to loads of different stuff in different places, and merging all apps with the system would make that harder. I've got Kali's kernel and tools and added them to an core Debian install I had and separated tools into my /pentest folder, and it's looking good. Problem is BT was known (IS known, sorry) for being the most out-of-the-box pentesting distro ever because of features such as that, but now that's changing, and at least for me, doesn't feel as sweet as it would be if you guys kept SOME things as they were in BT for Kali.

Still, Kali will continue to be ***-kicking for sure :)

I don't mean any offence but can't you just use BT5 instead?

I don't really see too much of a difference other than the platform and setup. 99% of the tools exist in both distros. If I felt the same as you, I would just go back to using BT5 instead. I love the feel of Kali but that's only because I'm relatively new to linux and certain things are now easier than in BT5.
The guys have done a great job, regardless!

I mostly agree on missing the /pentest folder as well, but with Kali being made with the FHS in mind I think it'll be better in the long run once people adopt it. I loved BT5 over BT4, so hopefully it'll keep this progression.

That's what's awesome about Kali, its your distro, you can build one exactly the way you want.

Not to beat a dead horse, but embrace the change and you'll find any initial feelings of despair will dissipate.

This is all I am going to say in this thread...

I've read through most of this thread but not every word of every post so I apologize if someone brought this up already....

but would there be a problem with creating a /pentest folder with a bunch of folders for categories and then inside those folders create a bunch of symlinks to the folder of each tool that you would expect to see in /pentest

it seems that this would solve the issue of not being able to easily navigate a nice organized folder with all the tools listed.

As mentioned in the previous posts if anyone wishes to sort their own tools they can do so.
I am not going to talk about the cons and pros of having the /pentest/ directory however keep in mind that while in Backtrack the /pentest/ directory contained a significant amount of tools not all of them were placed there.
As an additional note if you know the tool that you require you can easily find it in both Kali and Backtrack.

Maybe this can help. I've been using i3wm and there is no menu or categorization whatsoever so I made a curses menu based on the Kali gnome menu. Mainly all working with a couple issues mentioned in the readme. Hope it helps.

code: https://gist.github.com/anonymous/5223436

There's also another big problem, when you use the menu to choose a tool you get to execute it but the directory doesn't change to the tool's one.

Example: I want to use sqlmap so I click on sqlmap on the drop down menu, I later get the output for ./sqlmap.py -h which is very informative and nice. But if I try to ./sqlmap.py -u URL I can't because I'm on a different directory so I have to actually grep or find to know which directory sqmlap is in then CD to it and then be able to use it. If I click on sqlmap on BT5 the directory automatically changes to /pentest/database/sqlmap. I think this should really be fixed.

Didn't read everything but I want to add.
One of the reasons I switched to kali from Backbox (I switched to backbox from backtrack) is since it lost it's /pentest folder.

Quote:

---

Originally Posted by mormaii2

There's also another big problem, when you use the menu to choose a tool you get to execute it but the directory doesn't change to the tool's one.

Example: I want to use sqlmap so I click on sqlmap on the drop down menu, I later get the output for ./sqlmap.py -h which is very informative and nice. But if I try to ./sqlmap.py -u URL I can't because I'm on a different directory so I have to actually grep or find to know which directory sqmlap is in then CD to it and then be able to use it. If I click on sqlmap on BT5 the directory automatically changes to /pentest/database/sqlmap. I think this should really be fixed.

---

This problem you're having can be resolved very easily by going about things in a different way (I'll get to it in a minute) and I believe this is the exact reason for the change.

I do want to say before going further that when I first booted kali and saw that there was no /pentest folder I was a bit upset and confused because I didn't (and still don't fully) quite understand what they meant by FHS or whatever, but the whole point of it is that you can access any tool from any directory. I now know the basic idea behind this and it really allows for more freedom when running scripts/commands and it only took a day or two to get used to.

I also want to point out that I still would like to see a /pentest folder built with symbolic links like I described in a previous post, simply because I still have quite a bit to learn and I liked being able to poke around in the folders. find a tool that I haven't used before. and then read its man page or search for a tutorial to learn more about that tool.

So to get back to your issue...

You can run sqlmap from anywhere, when you put ./ in front of something, you're telling the shell to run a file in the current directory, so your command:

Code:

---

root@kali:~# ./sqlmap.py -u 'http://victimmachine/?id=1'

---

tells your shell to run a file in whatever directory you're in (presumably /root) called sqlmap.py and /root/sqlmap.py doesn't exist.

To fix this, remove the ./ and the .py and it will run from anywhere... this should work with any of the tools installed since that's the point of this whole FHS thing as far as I can tell...

so run your command like this instead:

Code:

---

root@kali:~# sqlmap -u 'http://victimmachine/?id=1'

---

Disclaimer: I'm absolutely not trying to sound condescending in any way. Like I said, I like the /pentest folder too but I see the advantages of doing it this way and it doesn't take long to get used to it.

yeah missing the /pentest directory too but hey thats progress id rather run any scripts anywhere than going to a particular directory all the time...:cool:

Quote:

---

Originally Posted by devi1

This problem you're having can be resolved very easily by going about things in a different way (I'll get to it in a minute) and I believe this is the exact reason for the change.

---

Being able to run everything from everywhere is great, but I think you guys miss the point of the pain.

1. what is the #@! app called? As Jay illustrated at the start.. hmm, what does this app do? click.

Code:

---

USAGE: apache.pl [-h 1.2.3.4] [-l names] [-p 80] [-s (SSL Support 1=true 0=false)] [-e 403 (http code)] [-t threads]

---

Great! now where is this app?

Code:

---

# apache.pl
bash: apache.pl: command not found
# updatedb
# locate apache.pl

---

etc etc.

2. Many apps have support files which are in their own directories, so you have to know which directory these files are in anyway. john is an example, as are other apps with wordlists.

You can use simple linux 'find' commands to locate what you want. For instance 'whereis apache.pl' or 'locate apache.pl' will tell you where they are located. It seems that all the tools are in /usr/share anyway (at least I haven't found any that weren't yet) so you could always just cd /usr/share and poke away at all the tools to see what they do.

Hi there,
I made a script that can help you with that pentest folder.
With the script you can filter the tools and even gives you the package version and description.

Quote:

---

git clone git://github.com/Bl4ck5w4n/searchpkg.git
cd searchpkg
sh searchpkg.sh

---

http://vimeo.com/68443845

Hope it helps,

Cheers

how to install pentest directory kali linux