GPU Cracking Complaints
Wednesday, July 13, 2011 at 10:02AM I've been cracking passwords for a while and use a myriad of tools in a certain order to get the job done. I find that Cain is still my Go-to for allowing me to visualize the process and do some basic sorting (really wish I could search in-app). But I've been asking around on twitter some questions like Why is GPU cracking for 50k hashes faster than Rainbow Tables (most say the bottleneck is the HDD read style and speed) and many asked what all of my compalints are so I figured this would be the best place (vice multiple emails)
DISCLAIMER: I have very little crypto knowledge and even less GPU programming knowledge so I only get to complain as a user and not as someone who can actually fix the things I complain about.
- Lack of LM support. I get that this is a complicated hashing algorithm, but the fact that 90% of companies still have it turned on and cracking any more than a few with Rainbow Tables is impractical unless you have a SSD raid with a GPU based cracker ($$$$$).
- Lack of dictionary support. Right now the best way to crack passwords is with oclhashcat-plus since it is GPU based and supports rules, multiple hashes (hash files) and directories of hashes. However, it has a very limited list of hashes it supports (No LM, SHA1, etc..) and it doesn't support dump formats, so you need to strip the file so it just has the hash (this is more of just a bother than a gripe).
- (2a) I say 'The best way' because anything that has a key space larger than upper-alpha-numeric-32symbol (LM) is just a bit nuts to try and brute force out of the gate unless your goal is to 'crack them all'. Me as a pentester, I want to get as many as possible, as quick as possible, so this means dictionaries are the smarter option. (Maybe later I can do the straight brute if I really need / want to)
- Lack of POT. For some reason every cracking app on the planet, save for JtR, thinks it's a good idea to crack the same hash multiple times. I wish even Cain would keep a secret store of all the hashes it's cracked stripped of anything unimportant (need the salt (username) sometimes) and store it in the background so that if it comes across the same hash it can say "oo oo I know this one" and auto populate it even before I start cracking. Why more cracking software writers don't do this I'll never know (would make their software seem a ton faster the more it is used)
- Lack of formatting documentation (#ripshairout). Rare is the time I've found a cracking program that shows you how it wants to consume a hash. JtR is the most egregious offenders of this but they all do it. One would think people would try and make it easy for people to use their software (give examples of what shit is supposed to look like at least if you don't support standard formats)
Those are my biggest gripes that the moment. If I am wrong on any account, let me know, I would love to know of a better way to do things.
cracking, gpu, password cracking
Reader Comments (6)
If you don't mond actually paying for your password cracking software I've found EGB (from Inside Pro) to work amazingly well.
It accepts dictionary files, and bruteforce masks
It saves output to a .DIC file that includes the password:hash pair
It can be used on multiple GPUs (do not have them in SLI mode)
It supports a couple dozen hash types... all of the ones you mentioned plus many many many more.
It supports a ton of hybrid attack methods
Well worth the 40€ imho.
if the speed issue is that bottle neck couldn't they use the onboard memory of the card then the computers ram as buffers? I feel that if you are using the harddrives as primary storage that you need to load it into something faster to use it. Or if they on the fly generated the table.. With the speed of the gpus I think that could work too. Theoretically slower but might be more stable. And at that point split up how the hash is generated into threads and it could allow you to use the gpu fully and do distributed cracking if you wanted over mutlible cards. I'm going to keep looking at the options and may try to weigh the pros and cons of onfly bruteforcing with gpu
I mean if rainbowtables are already generated they would probably be just as fine versus GPU but RT's wil be MUCH slower. You can crack a 7 character password with a solid GPU cracker in less than a minute which is much faster than cycling through rainbowtables. 8 characters that increases to about 5 minutes, 9 gets significantly larger from a sheer brute force perspective. But regardless if your cracking 1 hash or 32490238922342 hashes the GPU would be significantly faster.
In stating all of this, the main tradeoff with leveraging GPU's is the insane speeds you get in sheer brute forcing or through dictionaries. There has been hundreds of breaches and several million real-world passwords released publicly. This is where GPU cracking starts to shine.
So to your points mubix:
1. LM is a very very easy algorithm
import hashlib,binascii
hash = hashlib.new('md4', "thisismyhashvalue".encode('utf-16le')).digest()
print binascii.hexlify(hash)
The reason its so fast is the hashes are loaded directly into memory and cracked leveraging the hundreds of cores per each GPU, there is very little if any hard-disk activity truly occurring. Time time-trade off of the calculations being made in the GPU's versus through reading in multiple gigabyte files is enormous. LM and MD5 are probably the most simple hashes algorithms to crack, it starts getting significantly more complicated and slower with EAPOL handshakes via wireless.
2. Check out Multiforcer, it has multi-gpu support and supports the algorithms you specified. On the dictionary front, when speaking with LM since the hashes are split 7/7 it's not really needed, they will all crack within a few seconds/minutes. When your talking about WPA(2) handshakes, the only way you'll be successful is through dictionary files. This is where the major breach password lists come into handy, pure_hate has taken every major breach, cracked them and compiled. ISDPodcast has done something similar too as well as have I... These are massive dictionary files with millions on there.
3. Would agree with that, there's nothing like that I'm aware of in ocl or multiforcerer.
4. Check out multiforcerer, the documentation is pretty good and its a really simple tool..OCLHashcat is a bit confusing at first, I think pure_hate explained it to me about 15 times before I got it :P
Hope that helps.....
Dave
Interesting dicussion guys!
Don't mean to highjack this, but if I may interject a side discussion here on NT hash cracking....
I am wondering about the feasibility of using GPU cracking for NT hashes. Ultimately, I'd like to answer the following question: at what password length does it become prohibitively expensive to crack NT hashes (9 chars, 11 chars, 15 chars)? Has anyone tried brute forcing NT hashes? I realize that LM hashes are still quite prevalent, so perhaps not.
Dave to your point about LM being basically just MD4 ... I thought LM used DES and NT hashes use MD4??
I look forward to your responses!
-Erik
The main reason that GPU cracking is faster than rainbowtables when cracking a large number of hashes is that a rainbow table takes approximately twice as long to look-up two hashes as it takes to look-up one hash, (you get some speedup due to only having to access the disk once). This is because the comparison chains for each target hash have to be built independently. These are the chains that assume that the target hash is at position 'n' in the rainbow table. For a RT with a chain length of 1k you would have to build 1k of these comparison chains per target hash. So if you were cracking 50k unique LM hashes you would end up creating 50m comparison chains.
Then you would have to look up the last value of each of these comparison chains in the full RT and calculate all of the false positives chainwalks until you correctly crack the hash each comparison chains is associated with.
Compare this with GPU cracking where you can load all of the target hashes at once, and every-time you make a guess you simply compare it against the entire target list. If you use a halfway smart look-up algorithm, yes you are paying a log(n) time to do a lookup so cracking 50k hashes is more expensive than just one, but still the cost is minimal. Therefore, when cracking a large number of hashes GPU cracking is by far the better way to go. All of the teams at last year's Crack the Hash competition at Defcon found this out firsthand.
I'll agree with you about many of your complaints about password crackers. One of the reasons why you don't see many GPU crackers support LM is that DES is a pain to implement in a GPU. I also assume since LM is already considered broken most coders don't bother with it. As far as dictionary support goes, the main bottleneck is getting the guesses from the CPU to the GPU for fast hashes. It's easy to implement basic brute force attacks in the GPU, but loading large dictionaries in GPU memory often isn't possible, and the transfer speed from the CPU to the GPU is a real killer.
OK, I am developing a GPU hash cracker and I can address some of the points above:
1. Lack of LM support. I get that this is a complicated hashing algorithm, but the fact...
I recently implemented that. It is not a complicated algorithm. However, DES is not that GPU-friendly because of the lookup tables that require dynamic indexing and take up about 4KB. Good news is it fits in fast on-chip memory. Bad thing is that it is not fast enough, as compared to say MD5 (difference being about 4250MH/s for single md5 hash vs 360MH/s for single lm hash on 6870, stock clocks). Bitslice DES could change that up to 2-3x, but it's terribly complicated to do on GPU.
2. Lack of dictionary support.
The biggest bottleneck with dictionary attacks is the filesystem I/O. Remember Amdahl's law. Your GPU would crack those at hundreds of millions/second _once_ you read the dictionary from disk and transfer it to GPU memory. Unfortunately those two are slow. You won't get any benefits really as compared to CPU dictionary attack. Unless you are cracking "slow" iterated hashes of course.
3. Lack of POT. For some reason every cracking app on the planet, save for JtR, thinks it's a good idea to crack the same hash multiple times
Never thought this is an useful idea actually :) It can easily be implemented though.
4. Lack of formatting documentation (#ripshairout). Rare is the time I've found a cracking program that shows you how it wants to consume a hash. JtR is the most egregious offenders of this but they all do it
Yay, we tend to spend sooo much time and efforts into optimizing stuff and implementing new functionality that there is usually not much time for that. Unfortunately.