Reordering or files to help integration into linux distributions

[jsteube]

Moved from hashcat forum: https://hashcat.net/forum/thread-4891.html

The problem with packaging hashcat right now, as dropdead and I were discussing, is that hashcat doesn't exactly adhere to the FHS. Basically the hashcat directory is a working directory, and that's rather contradictory to the FHS.
Ideally before we go down the road of Linux packaging, we would re-organize the file structure, such that binaries are in /usr/bin; kernels, rule files, etc. are in /usr/share/hashcat; and user files (pot, restore, induct) are in the user's home directory, e.g. ~/.hashcat).
Otherwise, we basically just have to stuff everything in /usr/share/hashcat and have the user run from that directory as root.

We discussed the new "layout", this is the final suggestion:

Have 3 types of folders:

• Install folder
• Profile folder
• Session folder

Since this problem does not affect Windows, there will be no change. Everything will stay inside the Install folder as it is already.

For Linux it's different:

• The Install folder is generally not so important as for Windows, it's usually /usr/bin and /usr/share
• The Profile folder will be: ~/.hashcat
• The Session folder will be: $profile/$session

We'll move files from the source tree to the following destinations (hopefully self-explaining) aka Install folder:

• /usr/bin/*.bin
• /usr/share/doc/oclHashcat/ (stuff from docs/* and example* files)
• /usr/share/doc/oclHashcat/extra/*
• /usr/share/oclHashcat/hashcat.hcstat
• /usr/share/oclHashcat/charsets/*
• /usr/share/oclHashcat/kernels/*
• /usr/share/oclHashcat/masks/*
• /usr/share/oclHashcat/rules/*

The Profile folder will have:

• ~/.hashcat/kernels/4098/*.kernel
• ~/.hashcat/hashcat.pot
• ~/.hashcat/hashcat.dictstat

The Session folder will have:

• ~/.hashcat/$session/hashcat.log
• ~/.hashcat/$session/hashcat.restore
• ~/.hashcat/$session/hashcat.restore.new
• ~/.hashcat/$session/outfiles/
• ~/.hashcat/$session/induct/

[jsteube]

There's one more thing to think about. I just thought about this the first time this morning. Imagine we implement this proposed change, how would the binary distribution look like for linux?

It would either require an install script to move the files to the above folders or it should stay as it is now.

Therefore we should come back to the proposal from @philsmd on the hashat forum. Maybe I just did not realize on the forum that this is what he had in mind when he wrote it.

• If the tool is called from the cwd, then set Install folder, Profile Folder and Session folder to the cwd
• Otherwise use the proposed changes

[unix-ninja]

Binary distribution should be handled by package management. RPM and DEB will tell the OS where to put the actual files.

Personally, I think that the paths for these items should all be constants defined in a header. This way we have two interesting things that can happen:

• Different paths can be used for different OSes (e.g., Windows vs Linux) without changing the main code
• Also, if a package maintainer wants to override the paths for their specific distribution, they can make a patch for this one header and the likelihood of further code changes breaking their patch would be much less. This should make the package maintainers' lives easier.

We could then also make these paths configurable in the Makefile (this should make the BSD and Solaris folks happy)

[jsteube]

Wait, it's important not to confuse the two different binary package we have:

• RPM/DEB
• The .7z for the distribution on hashcat.net

For the source tree, the RPM and the DEB, of course the real paths that I mentioned in the first comment are part of the Makefile so that anyone can change them at compile time. So if the users chooses the install folder /opt/bin then, for example, the oclHashcat binary will move to /opt/bin/oclHashcat. Like you'd expect it.

But, more importantly, we also have to think about the .7z binary package. The most users will use this package. But we don't want to ship an install script for that. We want that the user just unpacks the .7z and is ready to use it. Same way as with windows. But we're looking for a way that we do not have to build two different binaries. So far the idea is that the binary itself finds out on startup that it is used out of the .7z package if the CWD == the folder where the binary itself is lying. We'd just set all the paths, Install folder, Profile folder and Session folder to the CWD.

[unix-ninja]

Another option would be to have hashcat look for a config file on startup. If it finds the config, use the values in there. If it doesn't find the config (or the values aren't present) default to CWD.

/etc/hashcat/hashcat.cfg on Linux, for example

[jsteube]

Maybe later, currently I'm not planing to integrate a config file

[jsteube]

Before we can finalize this enhancement we need to switch to OpenCL fully, also for NVidia. This way we can reduce the number of produced binaries and we do not need to add any code to the Makefile to find out which type of binary needs to be compiled.

I thought hashcat (as a library) should respect the shared_folder argument passed to hashcat_session_init. But it only does so if install_dir is equal to resolved_install_folder, otherwise shared_folder is ignored. Is there any sense to this?

hashcat/src/folder.c

Lines 393 to 415 in 77c9f09

	if (strcmp (install_dir, resolved_install_folder) == 0)
	{
	struct passwd pw;
	struct passwd *pwp = NULL;
	char buf[HCBUFSIZ_TINY];
	memset (buf, 0, sizeof (buf));
	memset (&pw, 0, sizeof (pw));
	getpwuid_r (getuid (), &pw, buf, HCBUFSIZ_TINY, &pwp);
	const char *home_dir = pwp->pw_dir;
	profile_dir = (char *) hcmalloc (HCBUFSIZ_TINY);
	cache_dir = (char *) hcmalloc (HCBUFSIZ_TINY);
	session_dir = (char *) hcmalloc (HCBUFSIZ_TINY);
	get_profile_dir (profile_dir, home_dir);
	get_cache_dir (cache_dir, home_dir);
	get_session_dir (session_dir, profile_dir);
	shared_dir = hcstrdup (shared_folder);

hashcat/src/folder.c

Lines 421 to 427 in 77c9f09

	else
	{
	profile_dir = install_dir;
	cache_dir = install_dir;
	session_dir = install_dir;
	shared_dir = install_dir;
	}