[BUG] in POT-Parser for specific entries -> hash:salt:pwpart1:pwpart2

[Snoopy]

hello everyone

i found a bug in the potfile-parser for entries like this

Code:

hash:salt:pw-part1:pw-part2

where the : is part of already found/known password

using a potfile eg.  with 100 entries, where this with an entry like this is the last entry, results in hashcat only recognizing 99 entries, resulting in "recracking" the already known password, resulting in a second, third, fourth and so on... entry with the same entry.

my potfile is hashtype specific, so with a little help of

Code:

sort, uniq -c and regex

i can tell you the following, the error (probably) occurs only in this style of entry, described obove because 

: inside/outside a salt seems to work normally because i found this style multiple times (but with uniq entries)
 

Code:

hash:salt-part1:salt-part2:password
hash:salt-part1::salt-part2:password
hash:salt-part1:salt-part2::password
hash::salt-part1:salt-part2:password

Hashtype is 2811, dont know wheter or not the saltsize is fixed for this hash or how your parser splits these specific entries, but the error should be located there?

[Snoopy]

https://github.com/hashcat/hashcat/issues/2686

further explanation and dataset

[Snoopy]

added a simple test with plain md5, test-password was

Code:

test1:test1

same behavior, hashcat cannot recognize this plaintext-password in pot-file, resulting in recracking it again and again

potfile after 3 runs

Code:

723210cefac9372c968e5bfd98cb022b:test1:test1
723210cefac9372c968e5bfd98cb022b:test1:test1
723210cefac9372c968e5bfd98cb022b:test1:test1

md5 and i think all other hashes are fixed in size so everything after the first : should be parsed as password, which doesnt seem to happen

in the code for module0 i found

Code:

  token.len_min[0] = 32;
  token.len_max[0] = 32;

so i think the length of md5 is fixed, but i dont know where to look now (oufile, potfile?)

what i saw in the code, that salt_min and salt_max are set to 0 and 256 which seems to affect global all hashes and so affecting the first hahsmode 2811, dont know wheter this could be fixed by "fixing" the salt size to a const for this/all hashmodes with a salt (variable salt length would be a problem right?)

[Chick3nman]

I'm not sure how you are ending up with this issue, passwords that contain ":" are automatically hex encoded using the $HEX[] notation to specifically avoid issues like this. They should not be ending up in your potfile with ":" in them in the first place. Are you using the most recent version of hashcat?

[Snoopy]

I'm not sure how you are ending up with this issue, passwords that contain ":" are automatically hex encoded using the $HEX[] notation to specifically avoid issues like this. They should not be ending up in your potfile with ":" in them in the first place. Are you using the most recent version of hashcat?

Using the git-version,

and yes this should be the point, i use --outfile-autohex-disable in my batch cause im working afterwards on the pot or hitsfile to build up an specialised wordlist for this particular attack, okay so i need to parse the $HEX[] notation by myself

thanks for the hint

sadly there is no option to just disable autohex for the outfile, not for the pot-file