Yes this seems to be a bug:
see
It's okay that it says that it will be skipped... and it is also okay that the mask within the status screen is shown anyways... but the thing that is not correct is that it seems that hashcat tries to run it anyways and most importantly that the Progress and Restore.Point values are > 0 (this should never happen if something is skipped).
I can reproduce this with a command as simple as this one:
If we run this command above (using only 2 masks) we can see that the first one is run successfully (because >= 8) but the second one is also tried (maybe some variables/buffers are not correctly initialized/reset).
I suggest that we start debugging it from this line in code: https://github.com/hashcat/hashcat/blob/...sp.c#L1298
The return value 0 seems to be kind of ignored in hashcat.c when calling mask_ctx_update_loop: https://github.com/hashcat/hashcat/blob/...#L119-L121 (I think some further actions need to be performed when a mask is skipped, like resetting buffers etc)
see
Code:
Skipping mask '?u?l?l' because it is smaller than the minimum password length.
[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>
Session..........: hashcat
Status...........: Running
Hash.Type........: WPA/WPA2
Hash.Target......: testAP (AP:aa:aa:aa:aa:aa:aa STA:44:44:44:44:44:44)
Time.Started.....: Tue Jan 02 16:44:52 2018 (1 sec)
Time.Estimated...: Tue Jan 02 17:03:48 2018 (18 mins, 55 secs)
Guess.Mask.......: ?u?l?l [3]
Guess.Queue......: 37/837 (4.42%)
Speed.Dev.#2.....: 88053 H/s (9.27ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 30720/100000000 (0.03%)
Rejected.........: 0/30720 (0.00%)
Restore.Point....: 0/10000000 (0.00%)
Candidates.#2....: 023 -> 071
HWMon.Dev.#2.....: Temp: 76c Fan: 46%
It's okay that it says that it will be skipped... and it is also okay that the mask within the status screen is shown anyways... but the thing that is not correct is that it seems that hashcat tries to run it anyways and most importantly that the Progress and Restore.Point values are > 0 (this should never happen if something is skipped).
I can reproduce this with a command as simple as this one:
Code:
$ cat a.hcmask
123,?1?1?1?1?1?1?1?1
?u?l?l
$ ./hashcat -m 2500 -a 3 hashcat.hccapx a.hcmask
If we run this command above (using only 2 masks) we can see that the first one is run successfully (because >= 8) but the second one is also tried (maybe some variables/buffers are not correctly initialized/reset).
I suggest that we start debugging it from this line in code: https://github.com/hashcat/hashcat/blob/...sp.c#L1298
The return value 0 seems to be kind of ignored in hashcat.c when calling mask_ctx_update_loop: https://github.com/hashcat/hashcat/blob/...#L119-L121 (I think some further actions need to be performed when a mask is skipped, like resetting buffers etc)