Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: Why Is Hashcat Soooooo Slow
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Howdy All,

I am trying to crack an iTunes backup file for a friend that swears black and blue he never set a password on it. Unfortunately it contains all the photos,videos of his new born Sad 

I am running the following command.
hashcat hash.txt -m 14800 -a 6 dict.txt ?d?d?d?d --session 4Digits

I have prepared a word list of all his common passwords in the various combinations uppercase, lowercase, sentence case, reverse sentence case etc and this is saved in dict.txt. 

I am running it on my MAC mini and it is slow as hell! I thought this was because it only has an embedded Intel HD Graphics 4000. I created a Nv6 VM in Azure which runs the Nvidia Tesla card and loaded the GRID drivers and still the speed was slow extremely slow (a 90 day attack dropped to 30 days). 

When I start HashCat it states the following 

Filename: dict.txt
Password: 24
Bytes:163
Keyspace: 240,000


The wordlist or mask that you are using is too small. 

It doesn't seem to matter what I do to the mask or word list it still throws the wordlist too small error. According to hashcat.net/faq/morework I am suppose to use rules? 

./hashcat64.bin --stdout wordlist.txt -r rules/best64.rule | ./hashcat64.bin -m 2500 test.hccapx

What I can't figure out is which rule I am suppose to use? I presume my command would look something like
hashcat --stdout dict.txt -r rules/somerule | hashcat -m 14800 -a 6 ?d?d?d?d hash.txt --session 4Digits

I have read and reread the morework faq but I find it very confusing and can't work out if the speed is because the algorithm is simply slow or if it's because my word list is quote small (just 24 words) which I would have thought would made it faster and simpler to crack. 

Any help would be greatly appreciated. 

Thanks,
Chipper
the pipe (|) aka stdin mode only works with -a 0 in hashcat.

That means that you would need to use something like this:

Code:
-r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule

to chain 4 rule files to end up adding 4 times ?d.

The right part can only use rules in -a 0 mode.

You could use something like this:
Code:
./hashcat64.bin --stdout -r rules/hybrid/append_d.rule wordlist.txt | ./hashcat64.bin -m 14800 -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule hash.txt

or similar to end up adding 4 times the digits (1+3, 2+2, 3+1 all make 4), but the cracking part (right part) should (in general !) do also a lot of work and therefore use rules for acceleration. There is a little "exception" here, because the itunes hashing algorithm is using a so-called "slow hash" (this is the term used in hashcat internally, or we say that it is using this approach: attack outside kernel) and therefore the (password candidate generation)/acceleration part matters much less if we compare this to fast hashes such as MD5, SHA1, NTLM etc... But still, you shouldn't give hashcat too little work to do... it should have maximum acceleration and utilization of the resources.

An alternative could be to use -S (also test with rules or -a 6 alternatively).

The main problem here is also that you are trying to crack a very slow hash with very bad hardware (mac mini without any cooling system i.e. blowers/coolers/fan, or alternatively a very slow virtualized system with bad GPUs i.e. poor tesla). This doesn't mean that you could brute-force a hash easily with modern RTX 2080 Ti or similar. it's just the algorithm that is designed to be very slow and should be attacked more cleverly e.g. dedicated dict + dedicated rules instead of a "brute force" attack. Oftentimes a better approach is the key to success and avoids wasting time and resources, this also holds especially when it comes to hash cracking.
Hi Phil,

Thanks for the explanation it's starting to make some sense now Wink Making those changes has improved the speed. Now performing at 1H/s (1.68ms). I presume that if we want to guard against a power outage we could add the --session to the first hashcat statement? I also notice their is no progress % indicator so no way to really estimate how much faster it is and if it's worth investing in some better hardware?

I understand brute force is inefficient and that's why we have built the wordlist. I have already exhausted the wordlist with a custom character set and the only thing we can think of now is either the word list plus a pin no or possibly just the pin number which I guess is basically brute force but not sure their is any more efficient way to solve than what we are doing?