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 ()).
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:
Code:
./hashcat -m 99999 --outfile-format 2 dict.txt dict.txtand 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:
Code:
./hashcat -m 99999 --username wrong_potfile.txt dict.txtAlternatively, 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 ()).