+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Developer (https://hashcat.net/forum/forum-39.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-40.html)
+--- Thread: long mask issue (/thread-6293.html)
Pages:
1
2
long mask issue - PePPeRmix - 02-11-2017
Hello, any one can help me with long mask issue?
i need randomize all digits from 0 to 9.
Input.Mask.......: 0.?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d [32]
but result not randomized fully
Candidates.#3....: 0.129461124331111618461843184318 -> 0.857047602131111618461843184318
Candidates.#3....: 0.146613091498989618461843184318 -> 0.832427614298989618461843184318
as you can see i got last 10 digits not randomized '1843184318'
some one can help me?
ps
ha224
RE: long mask issue - royce - 02-11-2017
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.
RE: long mask issue - Ahmed18 - 02-12-2017
Hello,
I have the same problem
i want to add a mask for brute force attack a 32 Hex input
to crack a hash like this :
"81725FB90FA20BFEAA3690A180173D33BF48C21F93DC68DCB39D7ACFA8EDC206"
and i used --hex-charset --hex-salt in my command
but hashcat mask maximum length is 31 HEX input !!
RE: long mask issue - devilsadvocate - 02-12-2017
(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.
RE: long mask issue - royce - 02-12-2017
(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.
RE: long mask issue - royce - 02-12-2017
Ah, and to be precise even further ... it would never exhaust, because it's not controlled.
RE: long mask issue - devilsadvocate - 02-12-2017
(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.
RE: long mask issue - royce - 02-12-2017
(02-12-2017, 05:44 AM)devilsadvocate Wrote: Generating random input to hashcat has its uses despite what you may think.
Only in the same sense that a starving man might find it "useful" to watch a cooking show on TV.
It will briefly distract him from reality ... but he will then be worse off than when he started.
RE: long mask issue - epixoip - 02-12-2017
This approach is only advantageous if you know e.g. the exact algorithm used to produce the random numbers and know the algorithm has some flaw you can exploit to attempt to predict the numbers. Otherwise the keyspace is still the same, except now you're just pissing in the wind. Well, you're pissing in the wind regardless since the keyspace is impossible. But the probability of you "getting lucky" is not any more likely than going sequentially or using markov chains or something.
Also ?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d isn't even a valid mask for Hashcat, as it's greater than 2^64 - 1. So in one regard, streaming candidates into hashcat is a valid approach to work around the uint64 limitation. But on the other hand, it's fruitless to even attempt to brute force this keyspace since it's impossibly large. So the workaround is still for naught.
This thread is braindead no matter how you slice it.
RE: long mask issue - PePPeRmix - 02-12-2017
(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.
Thanks for reply, yes i know, it's extremely big, and i have ~ 30sec to crack it, i need a luck to find correct number, because it's not single number, i got new number every 30sec.
I have ~ 5pc with 6GPU which gives me 45Gh/s(1,5Gh/s*6*5)
that's why i don't need to brute-force it, i need randomize every digit over and over until i find correct hash