Limiting the consecutive occurrence

[ntk]

for this problem aGia I would use the combinator. You got the half of your password in one file, the second file you can generate via mp64 or mp32. Combinate them, you still have 2billion combined possibilities, then feed it in to oclHashcat+

2billion you can be run in a few hours at speed of 100,000 c/s.

Of course you can filter them so cut down about 28%.

Thanks for opfer the calculation power. which country is it?

[aGia]

for this problem aGia I would use the combinator. You got the half of your password in one file, the second file you can generate via mp64 or mp32. Combinate them, you still have 2billion combined possibilities, then feed it in to oclHashcat+

2billion you can be run in a few hours at speed of 100,000 c/s.

Of course you can filter them so cut down about 28%.

Thanks for opfer the calculation power. which country is it?

Its Greece, the 2.17b passwords will take me a lot of time. My cpu is amd 1100t black edition its a respectable 6 core cpu ,and my gpu is gtx260 low end graphics card. Combined with cuda pyrit i get 16000 pmk/s so it would take me 37 hours to run it so its rendered useless the whole procedure.
But why do u think my compression after filtering would be only 28% ?
To explain my self better for a 6 digit password i don't think one need so many restrictions like the one's you are planning on an 8 digit scale.
For a 6 digit password low-alpha numeric my strategy would be (if i could program it) no more than one instance of 2 consequtive characters
and no more than 2 instances of two characters appearing for a second time.
i.e. 5ebbd5 would be acceptable but not 55ebbd
any help appreciated, just for the fun of it i love this thread and i dont mean to push anyone or anything

[ntk]

@pixel
We have to be careful with insert rule.

the file is too large to check. I would suggest check first without filtering. if we reduce further down and generate only one position, then use your insert rule at beginning and at the end. Do we have a correct file of 3 char passwords, of lower alphabet type?

if you have 17576 lines then you are right. If not need to re-check.

[ntk]

aaeacaec is not acceptable but what about aceacaec?

[d333]

Hi,
I came across your discussion searching for information on how to make a custom 'smarter' brute-force program.
Including prioritized charter set and as discussed here to limit the re-occurrences of the same charter.

And my view of the whole is not to filter but rather to customize a permutation process mathematically (if possible) or by rewriting a simple brute-force program to 'skip-ahead' when re-occurrences occur to avoid testing all those extra useless generated passwords (simpler).

Now I want a mathematical solution so that I can 'reverse it' and later include all those permutations that where skipped IF the brute-force was unsuccessful with the 'optimized' method, so that I wont be forced to retry all those once again. But hey that's just me

/Dan

[atom]

thanks for replying. this is an old thread, i will close it now.

the solution has been made already, see here: https://hashcat.net/forum/thread-1291.html