Defining character length.

[Rdgeno]

As soon as I finished posting I checked Hashcat and it's doing it again, this time six charterers here's the screen.
Session..........: hashcat
Status...........: Running
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: XXXXXXXX(AP:2c:99:24:55:be:19 STA:94:27:90:09:78:a9)
Time.Started.....: Mon Sep 16 20:30:57 2019 (1 day, 17 hours)
Time.Estimated...: Sat Sep 21 21:12:07 2019 (3 days, 6 hours)
Guess.Base.......: File (BLACKLIST.txt)
Guess.Mod........: Rules (/usr/share/hashcat/rules/best64.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#2.........: 592 H/s (6.10ms) @ Accel:128 Loops:64 Thr:1 Vec:4
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 113902077/282345525 (40.34%)
Rejected.........: 17000445/113902077 (14.93%)
Restore.Point....: 1479010/3666825 (40.33%)
Restore.Sub.#2...: Salt:0 Amplifier:67-68 Iteration:1536-1600
Candidates.#2....: aniani -> beibei

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>

[undeath]

i wonder if this happens when applying rules that shorten the words. Looks very much like the result of applying rule "*05 O03 d '3 p1" from best64.rule

[Rdgeno]

I don't know you would know better than me that's why I'm asking. I didn't want to do something like this by accident, that's why I'm using best64.rule. The thing is when it opens it shows this,
Hashes: 3 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 77

Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Slow-Hash-SIMD-LOOP

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63
It says minimum and maximum as you can see, so it seems to know that's the rule to the game, it's ignoring it though. I have no idea how to fix it I'm still learning Hashcat. Is there a way to edit the rule? I'm using the stored rules until I get a better grasp on how things work. It doesn't make scene to me that someone would make the rule to break the rule. That and why is it showing that it's following the rule? I hope you or someone else can figure this out I'm a bit off from being that advanced any time soon, and it's wasting hours at least ten so far running these passwords. I keep checking it once it starts it just keeps doing it for quite a while. Thank you for your interest and thank you in advance if you can figure it out.

[undeath]

iirc password length restrictions are only enforced on the dictionary word, not the mutated candidate.

[Rdgeno]

Thank you for replying. I have a question about that, I removed all words from the dictionary under eight charters I should have explained that. I got caught up in the problem and wasn't thinking. This password has got me frustrated I have been going at it for quite a while, sorry. Since I removed the words under eight then where is Hashcat coming up with them? Or does that fall under what you said?

[philsmd]

Let's try to verify your claim. you said that the dictionary file does not contain any passwords shorter than 8 characters.

so let's try to run hashcat without any rule file and see how much rejected password candidates you get:

Code:

hashcat -m 2500 -a 0 captures.hccapx BLACKLIST.txt

because somehow this statements are in contradiction with your status display:

Code:

Rejected.........: 9762060/63333900 (15.41%)

15 % rejected means that 15 % of lines in your word list are smaller than 8 characters (or longer than 64, but that's probably less likely)

Let's first verify this claim about the "I removed the words under eight then where is Hashcat coming up with them"

[sono]

He uses a rule, and if we take this into account

iirc password length restrictions are only enforced on the dictionary word, not the mutated candidate.

this could be the rule who makes shorter words.

[philsmd]

yeah, but that's a different story. that wouldn't explain the 15 % rejected with the wordlist where s/he claims "I removed the words under eight".

[Rdgeno]

Let's try to verify your claim. you said that the dictionary file does not contain any passwords shorter than 8 characters.

so let's try to run hashcat without any rule file and see how much rejected password candidates you get:

Code:

hashcat -m 2500 -a 0 captures.hccapx BLACKLIST.txt

because somehow this statements are in contradiction with your status display:

Code:

Rejected.........: 9762060/63333900 (15.41%)

15 % rejected means that 15 % of lines in your word list are smaller than 8 characters (or longer than 64, but that's probably less likely)

Let's first verify this claim about the "I removed the words under eight then where is Hashcat coming up with them"

I'll do that, I still have a while on this list until it's done I'm so far into it I don't want to stop now. One thing though your right about the rejections, but you can see that it's still running the shorter words. I have no idea what it's rejecting if it is still running them. I'm more than happy ti do what you asked I would love an answer to this. This is from about five hours ago.Status...........: Running
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: Quanisha (AP:2c:99:24:55:be:19 STA:94:27:90:09:78:a9)
Time.Started.....: Mon Sep 16 20:30:57 2019 (2 days, 14 hours)
Time.Estimated...: Sat Sep 21 10:30:57 2019 (1 day, 23 hours)
Guess.Base.......: File (BLACKLIST.txt)
Guess.Mod........: Rules (/usr/share/hashcat/rules/best64.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#2.........:      650 H/s (6.15ms) @ Accel:128 Loops:64 Thr:1 Vec:4
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 170166614/282345525 (60.27%)
Rejected.........: 25855830/170166614 (15.19%)
Restore.Point....: 2209680/3666825 (60.26%)
Restore.Sub.#2...: Salt:0 Amplifier:74-75 Iteration:2432-2496
Candidates.#2....: p!io -> Paia

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit => s
It does run the longer words it is now, otherwise I would shut it off and restart it for you now, but it keeps going back to the small words too. I really do appreciate you guys taking an interest and helping.

[Rdgeno]

Let's try to verify your claim. you said that the dictionary file does not contain any passwords shorter than 8 characters.

so let's try to run hashcat without any rule file and see how much rejected password candidates you get:

Code:

hashcat -m 2500 -a 0 captures.hccapx BLACKLIST.txt

because somehow this statements are in contradiction with your status display:

Code:

Rejected.........: 9762060/63333900 (15.41%)

15 % rejected means that 15 % of lines in your word list are smaller than 8 characters (or longer than 64, but that's probably less likely)

Let's first verify this claim about the "I removed the words under eight then where is Hashcat coming up with them"

I'll do that, I still have a while on this list until it's done I'm so far into it I don't want to stop now. One thing though your right about the rejections, but you can see that it's still running the shorter words. I have no idea what it's rejecting if it is still running them. I'm more than happy ti do what you asked I would love an answer to this. This is from about five hours ago.Status...........: Running
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: Quanisha (AP:2c:99:24:55:be:19 STA:94:27:90:09:78:a9)
Time.Started.....: Mon Sep 16 20:30:57 2019 (2 days, 14 hours)
Time.Estimated...: Sat Sep 21 10:30:57 2019 (1 day, 23 hours)
Guess.Base.......: File (BLACKLIST.txt)
Guess.Mod........: Rules (/usr/share/hashcat/rules/best64.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#2.........:      650 H/s (6.15ms) @ Accel:128 Loops:64 Thr:1 Vec:4
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 170166614/282345525 (60.27%)
Rejected.........: 25855830/170166614 (15.19%)
Restore.Point....: 2209680/3666825 (60.26%)
Restore.Sub.#2...: Salt:0 Amplifier:74-75 Iteration:2432-2496
Candidates.#2....: p!io -> Paia

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit => s
It does run the longer words it is now, otherwise I would shut it off and restart it for you now, but it keeps going back to the small words too. I really do appreciate you guys taking an interest and helping.

You where right it was the rule, I took it out and there was no more problem. I'm including best64.rule text file can you please look at it and tell me which part to remove so the problem doesn't happen again. Thank you.
## nothing, reverse, case... base stuff
:
r
u
T0

## simple number append
$0
$1
$2
$3
$4
$5
$6
$7
$8
$9

## special number append
$0 $0
$0 $1
$0 $2
$1 $1
$1 $2
$1 $3
$2 $1
$2 $2
$2 $3
$6 $9
$7 $7
$8 $8
$9 $9
$1 $2 $3

## high frequency append
$e
$s

## high frequency overwrite at end
] $a
] ] $s
] ] $a
] ] $e $r
] ] $i $e
] ] ] $o
] ] ] $y
] ] ] $1 $2 $3
] ] ] $m $a $n
] ] ] $d $o $g

## high frequency prepend
^1
^e ^h ^t

## high frequency overwrite at start
o0d
o0m o1a

## leetify
so0
si1
se3

## simple extracts
D2
D2 D2
D3
D4

## undouble word
'5 D3
'5 $1

## removes suffixes from 'strongified' passwords in dict
]
] ]
] ] ]
] ] ] d
] ] D1 ]

## rotates
+5 ] } } } } '4
O02 { { { { { {
} ] ] {
} } -0 O12
} } }
} } } } '4
} } } } } '5
} } } } } } Y4 '4 d

## unknown
*04 +0 '4
*05 O03 d '3 p1
+0 +0 +0 +0 +0 +0 +0 +0
+0 +0 +0 O12
Z4 '8 O42
Z5 '6 O31 ] p1
Z5 *75 '5 { O02
d O28 Y4 '4 d
f *A5 '8 O14
p2 '7 p1 O58
O14 d p2 '6