Posts: 2
Threads: 1
Joined: Feb 2012
Hi
Dont know much about cmd commands , so the Gui mode is great for me.
I have already cracked some handshakes with dict wordlist.
but some i have that i know are 8 digits (capital letters and numbers) have not been solved .
Is there anyone that can tell me some settings within Oclhashcat plus that may solve these handshakes
Thanks
Posts: 313
Threads: 44
Joined: Aug 2011
oclhashcat-plus -a 3 linksys.hccap -1 ?u?d ?1?1?1?1?1?1?1?1
mind you bruteforcing wpa will take you a few months
Posts: 2
Threads: 1
Joined: Feb 2012
02-23-2012, 11:22 AM
(This post was last modified: 02-23-2012, 11:39 AM by datto.)
Alot of routers have 8 digit passwords from the broadband supplier, so unless the password has been chaged to a dict word , its not going to be cracked unless your prepared to wait a couple of months. ???
do i put this in the mask box ?u?d ?1?1?1?1?1?1?1?1
as i only know how to use the gui version
i know it may take a couple of months , but i trying to understand how this gui fully works
Posts: 5,185
Threads: 230
Joined: Apr 2010
36 ^ 8 = 2821109907456 combinations. if you gpu (like my hd6990) makes ~190 khash/s its 14847946 seconds -> 171 days. if you say chances are 50% percent you crack it before full keyspace was scanned, 85 days are left = ~3 months.
but, usually the key is not fully a-z 0-9, its just a-f 0-9. in this case cracking time reduces to 16 ^ 8 = 4294967296 combinations. so its done in ~6 days.
Posts: 44
Threads: 7
Joined: May 2010
I just had a brain-fart... I wonder if it would be worth it to have the program "jump around" the entire keyspace at pre-defined or "random" intervals... What i mean is a new "feature" where the program could do the following until the whole keyspace has been scanned:
Using 1 to 1000 (for simplicity) we could say that the program would work for a random (or pre-defined) period of time on a chunk of the keyspace and then jump randomly to another...
For example:
works from 1 to 120 (for x hours) then jumps to 700
works from 700 to 815 (for x hours) then jumps to 455
works from 455 to 600 (for x hours) then jumps to 940
works from 940 to 1000 (for x hours) then jumps to............
etc etc.. until the whole keyspace is worked through. Now obviously chunks that have been completed will not be worked on again. I wonder if this kind of randomization would increase "luck" of passwords like "zxxzxxzx" which would be found at the very end of a cracking cycle. If we "jump around" on a hash that would take a total of "5 days" for instance, maybe we could get the thing in 20 hours????
Posts: 5,185
Threads: 230
Joined: Apr 2010
02-23-2012, 05:08 PM
(This post was last modified: 02-23-2012, 05:09 PM by atom.)
omg sl3 techniques
Posts: 44
Threads: 7
Joined: May 2010
(02-23-2012, 05:08 PM)atom Wrote: omg sl3 techniques
It was silly of me to think that someone had not already pondered these thoughts, but sl3?? that was kind of a surprise to hear that. Do you mean that these are currently in-use, or that people have merely proposed them for sl3? I wouldn't know since I've literally never used -m 1900.
Anyways, does that sound like something at-all worthwhile for really brute "resistant" hash types (or any hashtypes for that matter)?
Posts: 5,185
Threads: 230
Joined: Apr 2010
yeah, they do that. its called "random salt" even if this sounds wrong from a hash-crackers view. however, oclHashcat does not support. i do not believe in this technique.
Posts: 6
Threads: 3
Joined: Jun 2010
(02-24-2012, 08:06 AM)atom Wrote: yeah, they do that. its called "random salt" even if this sounds wrong from a hash-crackers view. however, oclHashcat does not support. i do not believe in this technique.
like
Posts: 723
Threads: 85
Joined: Apr 2011
I requested a feature some months ago that would help speed brute forcing 8 character WPA passwords. A type of Markov filter for maskprocessor would be very useful. However now that oclHashcat-plus has a brute force capability without the need for maskprocessor, the Markov filter request would be suitable for oclHashcat-plus alone.
You can see it
here on the features page.
The idea is that it is very unlikely that a random 8 character password would have for example, more than 2 of the same characters concurrently.
Unlikely random passwords. = AAAAEDFT, AAAHBGTP, SDEWZZZZ, ASWZZZZZ ..etc
By allowing the user to select how many times a sequential character can appear would dramatically reduce brute force time. The user could select between 1 (unique characters only) to 8 (meaning that all 8 characters could be sequentially represented. AAAAAAAA.)
I would very much appreciate this feature in oclHashcat-plus as it would save me a lot of time and electricity !! ha ha ! However I have done quite well up to now to restrain my compulsion to “nag†for this to be implemented but I couldn’t hold back when I read this thread.
