(02-12-2017, 05:04 AM)royce Wrote: [ -> ] (02-12-2017, 02:33 AM)devilsadvocate Wrote: [ -> ] (02-11-2017, 11:54 PM)royce Wrote: [ -> ]If you really think that your target plaintext is 32 digits long, you will need more information about digit placement and likelihood to have any hope of cracking it.
To answer the literal part of your question: by default, mask mode used Markov to try common combinations of characters first. There is no way to "randomize" the attempts, but if you want to simply try all combinations, you can use the --markov-disable option.
But that's not really going to make this attack useful. The length of your mask is ... extremely long. 10^32 combinations is not feasible to exhaust.
I beg to differ.
You can get randomized 32 byte numbers by using /dev/urandom.
The command would be:
cat /dev/urandom | tr -cd '0-9' | fold -w32 | ./hashcat64.bin -m <hashtype number> hash.txt <other hashcat options here>
What hash type would this be for anyway? We are assuming that brute forcing a password that long is possible with hashcat. I don't have the list handy, but there is a length limitation for every hash type. Perhaps someone can link to that.
But the odds of getting the right number are WAY worse than winning the lottery. In that respect, you are correct.
You can beg to differ all you'd like, but it does no future reader of this thread any good whatsoever.
No one should ever feed /dev/urandom to a password cracker (unless they're fuzzing it or something). Feeding /dev/urandom to hashcat would be the password-cracking equivalent of Bogosort. Not only is it monstrously inefficient, but because it is uncontrolled, some strings could be skipped and others repeated. It's demonstrably useless.
And to be more precise, what I meant was that there's no way to do what OP was asking for within hashcat. Doing it outside hashcat would also mean slowing down GPU(s) to the rate that a single CPU core can generate randomness.
But a "how to do it faster" discussion is also pretty ridiculous when no one should ever want to do it in the first place. The OP and their grandchildren will die before it exhausts.
Ok, cool. Then I will beg to differ again.
Generating random input to hashcat has its uses despite what you may think. Let's take a WPA2 router key as an example. An ATT router/modem that has the naming convention of ATTXXXX will have a default password of 10 characters that can contain numbers or uppercase characters. Brute forcing the entire keyspace (with current technology available to civilians) would take at least several decades.
36 characters with 10 digits is:
36^10=3656158440062976
Assuming you can brute force 1.5 million WPA2 keys per second (at the present time, what a multiple GPU hashcat rig can do), you might be lucky to crack the key within 77.3 years.
3656158440062976/1500000/60/60/24/365=77.3
This assumes that you can generate 1.5 million random passphrases per second, of course.
Given the fact that a code like this would never be broken within the lifetime of most humans, why not throw spaghetti at the wall to see what sticks? It's better than nothing and maybe you get lucky.
Add to this scenario, doing this in a distributed manner, with multiple rigs trying this 24/7 and all it takes is for one of those rigs to "get lucky" and the password will be found.
Is the entropy perfect? No.
Does this eliminate the possibility of repeated passwords? No.
Is this practical? No.
Is this an efficient use of a hashcat rig? No.
But where is your sense of fun?
For anyone interested in trying this example:
cat /dev/urandom | tr -cd '0-9A-Z' | fold -w10 | ./hashcat64.bin -m 2500 ATTXXXX_wpa2_2_crack.hccapx
As for what the OP wants to achieve, it looks like mission impossible since our universe will probably be a singularity again before a 32 character passphrase is ever cracked via brute force by hashcat.
Also, I acknowledge that using /dev/urandom is probably useless for the OP, but what other options are there? None that are practical or even possible, so far as I can tell.
Footnote: atom, if you are reading this, please consider implementing a custom random character generator from within hashcat.
ha224