Integer overflow error

[inoo]

Hi, everyone

I found some error in hashcat 4.0.1
I'm sure it is bug on 4.0.1 version , is't it?

[hashcat-3.30] ./hashcat64.bin -a 3  ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a --keyspace
13647689206181

[hashcat-4.0.1] ./hashcat64.bin -a 3  ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a --keyspace
Integer overflow detected on keyspace of mask:   ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a

0

[philsmd]

No, this is correct. The number of password candidates is way too huge.
Just do the math ?a has 95 characters. If we have a length of 15, we have 95^15.
The result of 95*95*95*95*....*95 (15 times) is 463291230159753366058349609375 .
This is a very huge number and can't be represented with a 64-bit unsigned integer variable. The hexadecimal equivalent would be 0x5D8F98607A262F810DB9FC19F and this means you would need to have at least 128 bit variables.... but that would not matter/help at all here, because the attack is just infeasible and would not finish within hundreds/thousands of years with a very good setup.

Here you can read about what --keyspace does: https://hashcat.net/wiki/doku.php?id=fre...a_keyspace

... and yes, the value of --keyspace is smaller than the maximum 64-bit unsigned integer number, but still other values like the number of password candidates is too large and can't be represented.

[inoo]

thanks for your quick reply.
I agree that (?a x 15) keyspace is huge value, I agree also that such attack is infeasible
but I think hc 3.30 keyspace calc power is more useful than hc 4.0.1 regardless of infeasible or not
If keyspace calculation is possible in hc 3.30, there is no reason to abandon in hc 4.0.1, I think

[philsmd]

I think it is the other way around.
If we look at the file docs/changes.txt it mentions that the integer overflow check was first introduced with version 3.40 of hashcat. This is why you don't see the warning/error with version 3.30.

- Mask Checks: Added integer overflow detection for a keyspace of a mask provided by user

This implies if you for instance run this with hashcat 3.30:

Code:

./hashcat64.bin -a 3 -m 0 example0.hash ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a

it will overflow and you will see:

Code:

Progress.........: 0/11701187533149815199 (0.00%)

note: the value is not 463291230159753366058349609375 as it should be if 128 bit variables were used, but it shows the bug of an overflowed unsigned integer (64 bit overflow).

This problem was fixed with 3.40 and therefore you see the error/warning message instead of incorrect values.
Now you could say that the value of --keyspace is most of the time much smaller than the total number of password candidates. Which is true. Maybe one could implement a very nasty hack to work around the problem and show the --keyspace value nevertheless even if the number of password candidates are way too huge, but this would be just a complicated hack and doesn't really help much because the number of password candidates is still way too large.

[inoo]

I understand this issue clearly, thanks
I have one question about that in real life doing
if i have to do infeasible huge keyspace task, so i want to devide it by N nodes
(maybe N = 100,000 MANY NODES, for example)
how can i solve this problem?
if hashcat is not support such huge value, I guess someone use Microsoft calculator & hashcat -s -l options

[undeath]

Dividing the work doesn't really matter if the estimated time is beyond the assumed end of the universe.