Please note, this is a STATIC archive of website hashcat.net from 08 Oct 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: Packages for Linux distributions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I agree so far with the last summary.
There should not be a mix between shared and static files e.g. the docs should go in /usr/share/doc/hashcat or /usr/share/doc/oclHhashcat/

I am against doing creating ~/.hashcat/rules and ~/.hashcat/masks as default as well as supporting autocomplete for these. This just would confuse the user and custom rules will be kept in specific paths anyway.

A common-package would be nice but may be obsolete anyway before it will enter any stable tree, sounds as too much work for little to none pay.
The reason why I suggested an internal search path is to help keep command lines sane.

Here's an example: I want to run a simple rule-based attack.

oclHashcat64 hashlist wordlist -r /usr/share/oclHashcat/rules/best64.rule

Versus:

oclHashcat64 hashlist wordlist -r best64.rule

And the reason why I suggested paths for rules, hcmask files, etc in the working directory are for similar reasons. If a user creates their own rules, hcmask files, etc., they need a logical place to put them. With the rest of their password cracking stuff makes sense. And similarly, you don't want to have to do this all the time:

oclHashcat64 hashlist wordlist -r ~/.hashcat/rules/my.rule

Instead, it would be much nicer if the user could simply do

oclHashcat64 hashlist wordlist -r my.rule

So having an internal search path that first checks ~/.hashcat then /usr/share/{hashcat,oclHashcat} for things would be really nice.
This thread was been moved to GitHub: https://github.com/hashcat/oclHashcat/issues/20
Pages: 1 2