Why does emulating hybrid attack with rules skip some rules/ignore numbers?

[maymay]

Hi,

I'm learning about hashcat rules and recently noticed an issue where some of my rules are apparently being skipped (not tested). I created a simple rules file to append a three-digit number to the end of a dictionary, super simple, beginning like this:

Code:

$0 $0 $0
$0 $0 $1
$0 $0 $2
$0 $0 $3
$0 $0 $4
$0 $0 $5
$0 $0 $6
$0 $0 $7
$0 $0 $8
$0 $0 $9
$0 $1 $0
$0 $1 $1
$0 $1 $2
$0 $1 $3
$0 $1 $4
$0 $1 $5
$0 $1 $6
$0 $1 $7
$0 $1 $8
$0 $1 $9

and going all the way to

Code:

$9 $9 $9

. The idea here is to mimic a mask like

Code:

?d?d?d

as part of a combinator attack. I expected the intended result to be a two-word combination from the dictionary followed by a three-digit number (000 to 999). However, when I test these rules, some numbers are skipped. Here's the command I used:

Code:

hashcat --stdout -a 1 -r custom.rule my-capture.hccap dictionary.txt

and notice that in this snippet of the output, there are several numbers missing, such as "971" (it goes from "widesky970" to "widesky972") and numerous others.

Code:


widesky970
widesky972
widesky973
widesky974
widesky976
widesky977
widesky978

Why is this happening?

Also, after adding a few more rules to the beginning of my rule file (like

Code:

:

"do nothing" and reverse case/upper-case, etc.), then *different* numbers are skipped. Am I doing something wrong? Is this a bug?

Thanks for your help.

[undeath]

can confirm

Code:

./hashcat-cli64.bin /tmp/t -r /tmp/test -a1 /tmp/t --stdout | wc -l
500

a0 works

Code:

./hashcat-cli64.bin /tmp/t -r /tmp/test --stdout | wc -l          
1000

[maymay]

can confirm

Code:

./hashcat-cli64.bin /tmp/t -r /tmp/test -a1 /tmp/t --stdout | wc -l
500

a0 works

Code:

./hashcat-cli64.bin /tmp/t -r /tmp/test --stdout | wc -l          
1000

Sorry undeath, I don't understand your reply. Are you saying you can confirm my issue or asking me for some more information?

In case it's the latter, here's my setup. For testing purposes, my dictionary is tiny (four lines). My rules file is as described above, intending to append a three digit number (rules like $0 $0 $0 through $9 $9 $9). When I use -a1 (combinator attack), then if my math is correct, I should expect to get 16,000 password candidates because 4^2=16 possibilities, each of which has 1,000 variants, so 16 * 1000 = 16000.

Here's where the problem comes in. Even though I do see 16,000 attempts when I test with --stdout:

Code:

maymay$ hashcat -a1 --stdout -r custom.rule my-capture.hccap dictionary.txt | sort | wc -l
16000

the actual password candidates themselves have skipped some possibilities:

Code:

maymay$ hashcat -a1 --stdout -r custom.rule my-capture.hccap dictionary.txt | sort | uniq | wc -l
10000

My question is, given that I have defined no reject rules, why does hashcat ignore or fail to test every permutation of the rules defined?

Thanks again for your quick reply.

[maymay]

Bump…?

[epixoip]

undeath already said he could confirm it, so did you open a ticket on Trac to report the bug?

[maymay]

undeath already said he could confirm it, so did you open a ticket on Trac to report the bug?

Ah, I didn't understand that that's what undeath was saying. I'll open a Trac ticket now: https://hashcat.net/trac/ticket/654

Thanks for prodding me in the right direction.

[atom]

fixed in latest beta