hashcat Forum - Help with policygen/maskprocessor to create hcmask

Hi,

I've been trying for a while to solve this:

1. 10 chars password using only l and d (Ex: mi54s2tref)
2. max 5 consecutive l or d (Es: not mi546484gt)
3. no consecutive same chars (Es: not sfd31kk2as)

1. Done using policygen
2. modified hcmasks using sed|grep
3. Can't find a way: if I use maskprocessor and filter the output with sed I have a very very very big wordlist (and I have to repeat that for every mask generated from point 1 and 2, around 700).

Anyone?

Thanks for help

maskprocessor has an option for #3, see mp64 --help output:

Code:
-q,  --seq-max=NUM         Maximum number of multiple sequential characters

for #2 instead you need to generate some kind of filtered .hcmask file, you can use maskprocessor or hashcat --stdout for it:

Code:
./hashcat --stdout -a 3 -1 ld ?1?1?1?1?1?1?1?1?1?1 | grep -v dddddd | grep -v llllll | sed 's/\(.\)/?\1/g' > a.hcmask

I would say that it would in theory make sense to loop over all masks from your mask file (.hcmask) for #2 and use maskprocessor to filter it even further. The output of maskprocessor can be piped to hashcat:

Code:
#!/bin/bash

mask_file="a.hcmask"

while read -u 3 line

do

  ./mp64.bin -q 2 ${line} | ./hashcat -m 0 -a 0 -w 3 -O hash.txt

done 3< ${mask_file}

but remember, that each filter (#2 and #3) only filtered/reduced the number of password candidates by a "tiny" amount, e.g. there are 1024 different mask combinations of all ?l and ?d for length 10 (unfiltered ! 2 ^ 10 because of 2 different charsets - ?l and ?d - and 10 because of the 10 char length) and if you run the grep and sed command above the number of combinations is "only" reduced by less than 10 % to 928 ((1024-928)/1024 * 100 ~ 10 %)
also filter #3 does reduce the keyspace, but length 10 is still a lot

most of the time requests like this deal with slow algorithms and most of the time it is -m 2500 = WPA/WPA2 because users think there could never be passwords with 2 identical characters next to each others (even if there is no reason/proof/guarantee for this and indeed some passwords - users discovered later on - have identical chars next to each other because router vendors don't use this strange filter, sometimes it's just a wrong impression like "I have never seen something like this", "never saw a xxx router which uses 2 identical chars in the pass next to each other")

Hi,

thanks for your reply but I was actually requesting a solution for point #3 and, as I forgot to point out, maskprocessor option you refer to has a minimum of two as value.

I know the provider's algorithm and there are no consecutive same letters or numbers.

Anybody know how I can solve this without using a very big wordlist?

Thanks.

I literally just wrote what you should do for point #3

use maskprocessor with -q 2 as explained in my command above.

(01-26-2019, 04:11 PM)philsmd Wrote: [ -> ]I literally just wrote what you should do for point #3

use maskprocessor with -q 2 as explained in my command above.

Yes and thank you.

The minimum value of 2 misguided me. It works telling 'use max 2 consecutive chars that are the same' but it is actually using <2.

I tried putting everything together and it seems it loses around 10% of processing power but I will test it better on Monday.

Anyone good at math can help with 'how many candidates I'm testing from the 36^10 original pool'?
After removing the 5 consec chars (#2 in my first post) I had a hcmask file with around 720 masks.

Thanks again.

P.S.
To hashcat forum admin.. You request password with high complexity to access the forum but send it in plain text if asked to recover it.

the hashcat forum software (CMS) uses mybb. The mybb community/devs implemented the password reset mechanism with a temporary password. It's not your original password. The original password is stored in a strong hashed format and can't be seen in plain text. There are disadvantages and advantages of this temporary password.
I think that the security of URL-based reset tokens and temporary passwords are almost the same as long as the users follow the instruction and change the password (after resetting the account/password) to a secure password that only will be hashed and never be sent via mail.

I'm not sure how you came up with those 720 masks, my command from above:

Code:
./hashcat --stdout -a 3 -1 ld ?1?1?1?1?1?1?1?1?1?1 | grep -v dddddd | grep -v llllll | sed 's/\(.\)/?\1/g'

will have an output of 928 masks. 720 masks is not what I get by applying the #2 filter.

The overall reduction will be tiny as I said, just a few percent !

You can get a feeling by just using maskprocessor with -1 ?l?d and a smaller/growing mask ?1?1?1... e.g.

Code:
mp64 -1 ?l?d ?1?1?1?1

Code:
mp64 -q 2 -1 ?l?d ?1?1?1?1

Code:
mp64 -1 ?l?d ?1?1?1?1?1

Code:
mp64 -q 2 -1 ?l?d ?1?1?1?1?1

etc

with increasing length of the password the percentage between all password candidates without -q 2 and a run with -q 2 filter will increase a little bit (8 % with length 4, 10 % reduction with length 5, etc)

The math behind it is a little bit tricky (combinatoric) because we need to consider all factors
- how many total different chars
- how long are the passwords
- what needs to be removed (length 2 of identical adjacent chars up to length 10 of identical adjacent chars)

the overall formula is just:

combinations = 36 ^ 10 - all_combinations_of_2_or_more_adjacent_chars

I think the correct forumla is something like this: https://link.springer.com/article/10.1007/BF01819761

but I'm pretty sure that it's not that much of the overall keyspace.

of course this needs to be combined with your additional filter #2 (which could have also some overlapping passwords that are filtered out, i.e. filter #2 and #3 if applied individually could remove the same password independently).

You see that the math is a little bit tricky, but overall I guess we are speaking about a few percent (10% + 10-15% I guess).

update: fixed the statement about increasing vs decreasing percentage depending on the password length

(01-26-2019, 11:03 PM)philsmd Wrote: [ -> ]I'm not sure how you came up with those 720 masks

I will check that out again.

Quote:You see that the math is a little bit tricky, but overall I guess we are speaking about a few percent (10% + 10-15% I guess).

update: fixed the statement about increasing vs decreasing percentage depending on the password length

Well almost a quarter less overall is not that bad if someone now for sure he is not removing possible candidates.

Thanks again ..that maskprocessor option's limit fooled me.

(01-27-2019, 11:59 AM)mfoolb Wrote: [ -> ]
(01-26-2019, 11:03 PM)philsmd Wrote: [ -> ]You see that the math is a little bit tricky, but overall I guess we are speaking about a few percent (10% + 10-15% I guess).

update: fixed the statement about increasing vs decreasing percentage depending on the password length

Well almost a quarter less overall is not that bad if someone now for sure he is not removing possible candidates.

Thanks again ..that maskprocessor option's limit fooled me.

I actually tested on a better system and I lose around 20%/25% of performance checking the hashes from the stdin, so the benefit of removing candidates is lost.

I believe it would be nice to solve the 'no same consecutive chars' task using hashcat rules.. that will be a step forward..

rules are for modifying words, not filtering them