hashcat Forum

Ran into this oddity during a password audit. The "--show" option seems to fail to match when the password contains a colon character. Here's a simple recreation of the issue:

Contents of test.pot:

Contents of test.hash:



If the .pot file is hex-ified everything works as expected:

 

If a hex-ified .pot is a requirement is there an option to combine --show and outfile-format 2 with dehexify? 

-Dave

hmm, this is an interesting case and the reason why it's behaving like this is that hashcat only checks for the last "separator" in the potfile, see: https://github.com/hashcat/hashcat/blob/...ile.c#L538

In very older versions of hashcat it was different (it looped over all separators to test each and every substring splitted on the separator), but the reason why it's not looping anymore is that the $HEX[] format which is ALWAYS used for the potfile does already care about this and "encodes" every password containing colons with $HEX[].

My guess is that your pot file doesn't originate from hashcat (or a very, very old version of hashcat)... or it isn't really a pot file but a normal output file.

I'm not sure if we should do anything here. of course we could loop again over all separators within each line, but it is kind of useless in most of the cases (because hashcat doesn't write such pot files).

You could also use the very fast -m 99999 = Plaintext mode of hashcat to convert your non-hashcat pot passwords into valid hashcat pot passwords, something like this:

and the output will automatically contain the $HEX[] converted version of the passwords. Of course the output of this will only contain the passwords themself, not the combination of hash:password.

to have the hash:pass output you would probably need to re-crack the hashes or externally convert the pot file into $HEX[] whenever needed by splitting the hash from the password and only converting the pass part to $HEX[] if needed (passwords containing the separator).
You could also use -m 99999 for this, but you need to have a dict file that only contains the passwords, something like:
The --username flag here can be misused to get rid of the hash part in wrong_potfile.txt. Again, this only works if the dict.txt file only contains the password part (without hashes).

Alternatively, for a quick fix you could change the source code to either loop or to use the FIRST instead of the LAST separator (by using strchr () instead of strrchr ()).

Thanks for the response, that makes sense. The test pot file was generated by hashcat v4.2.1 but with the --outfile-autohex-disable option. For my particular case I've removed the 'autohex-disable' from my workflow and instead wrote a simple 'dehexify' python script so that I can pipe passwords to analysis tools, like so:

I think you are mixing up the outfile (--outfile or short -o) with the hashcat.potfile. The former will change whenever you use --outfile-autohex-disable, but for the latter the --outfile-autohex-disable will change nothing and the output should still be in $HEX[].

Therefore, I think you used the outfile (-o) instead of the .potfile, because the .potfile should always "encode" the passwords with colons.

I just retested to verify it wasn't a typo on my part. This command produces both a .dic and .pot that are not hexified:

I think you indeed found the main root of the problem.
The potfile read/write functions should ignore the --outfile-autohex setting.
See https://github.com/hashcat/hashcat/blob/...ile.c#L278

if not, it could lead to problems like you experienced.

I think we should open a github issue and continue the discussion on https://github.com/hashcat/hashcat/issues