m 14800 (itunes Ver >10), hashcat has a strange behaviour

[Alpensepp]

Hi,
im using hascat for several Years now, but i cant get why hashcat (4.0.1, win 10) behaves strange on this one:

I have extracted a hash from a manifest.plist. I start hashcat (for demo here) with


"hashcat64.exe -w 4 -m 14800 hash.txt -a 3 ?l?l?l"

After that, hashcat starts and shows its status 1 time

Session..........: hashcat
Status...........: Running
Hash.Type........: iTunes backup >= 10.0
Hash.Target......: $itunes_backup$*10*XXXXXXXXXXXXXXXXX...XXXXX
Time.Started.....: Fri Nov 10 10:45:06 2017 (1 sec)
Time.Estimated...: Fri Nov 10 10:45:07 2017 (0 secs)
Guess.Mask.......: ?l?l?l [3]
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:        0 H/s (5.05ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0/17576 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/676 (0.00%)
Candidates.#1....: sar -> sqx
HWMon.Dev.#1.....: Temp: 55c Fan: 33% Util: 45% Core:1000MHz Mem:1425MHz Bus:8

[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>

so far so good, but when i press "s" for an updated status nothing (except the time and H/s) has changed:

Session..........: hashcat
Status...........: Running
Hash.Type........: iTunes backup >= 10.0
Hash.Target......: $itunes_backup$*10*XXXXXXXXXXXXXXXXXXXXXXX...XXXXXX
Time.Started.....: Fri Nov 10 10:45:06 2017 (2 mins, 31 secs)
Time.Estimated...: Fri Nov 10 12:43:15 2017 (1 hour, 55 mins)
Guess.Mask.......: ?l?l?l [3]
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:        3 H/s (5.08ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0/17576 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/676 (0.00%)
Candidates.#1....: sar -> sqx
HWMon.Dev.#1.....: Temp: 59c Fan: 33% Util: 94% Core:1000MHz Mem:1425MHz Bus:8

3 H/s is pretty low ^^ when i press quit after some time it displays the folowing:

Session..........: hashcat
Status...........: Quit
Hash.Type........: iTunes backup >= 10.0
Hash.Target......: $itunes_backup$*10*XXXXXXXXXXXXXXXXXX...XXXXXX
Time.Started.....: Fri Nov 10 10:45:06 2017 (9 mins, 27 secs)
Time.Estimated...: Fri Nov 10 12:09:20 2017 (1 hour, 14 mins)
Guess.Mask.......: ?l?l?l [3]
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:        3 H/s (5.04ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 2028/17576 (11.54%)
Rejected.........: 0/2028 (0.00%)
Restore.Point....: 0/676 (0.00%)
Candidates.#1....: car -> cqx
HWMon.Dev.#1.....: Temp: 62c Fan: 33% Util: 93% Core:1000MHz Mem:1425MHz Bus:8

Started: Fri Nov 10 10:45:02 2017
Stopped: Fri Nov 10 10:54:34 2017

I tried it with different PCs (at work) and at home - all windows 8.1/10 AMD and NVIDIA. The result is always the same.
Does anyone have an idea what the reason of this could be?

[philsmd]

I don't understand what the problem is.

This is perfectly expected behaviour. -m 14800 is a hard/slow hash type.
Everything that you just described seems to be expected.

The only way to fix it is to:
1. use better GPUs and a higher amount of GPUs
2. do not try to attack a slow hash by brute-forcing it (brute-force/mask attack should always be your last and desperate option... this is true for all hash types and especially for slow hashes)

Maybe I just didn't understand what you are trying to say... but if your only "problem" is that it is running with "just" a few H/s than this is not a problem at all, this is just a proof how slow/hard this hash type is.

[GrepItAll]

Out of curiosity, what GPU are you using in those examples Alpensepp?

[Alpensepp]

I am using 2x gtx 970 and on another PC i have a Radeon HD9770
(Isn´t 3 hashes/s too slow then - even in this case?)
What confuses me is, that Passware has a much higher rate (using the same Manifest.plist)

In this case i only have this Iphone without any other hints. I will use a modified rockyou as mask in most of these scenarios.
I again extracted the hash (just to check again if everything is correct with it - although hascat would have stopped if the hash hadn´t the correct structure.

[GrepItAll]

Have you tried using a larger mask or a wordlist yet? It could be that you're not providing enough work to the GPUs. Although as Philsmd pointed out, 14800 is an obscenely slow algorithm. Also, has Passware ever managed to crack an iOS 10 or higher backup encryption password for you? It could be that it's attempting to process it as an iOS 9 backup password, hence the much higher speeds (10,000 iterations of PBKDF2 instead of 10mil)

[Alpensepp]

I have tried "rockyou" as a mask...

Some weeks ago i cracked an itunes Backup with Passware and i repeated it with the same Backup with a wordlist i provided to UFED-analyzer. I will have to look after it was ver. 10 or ver. 9.

Maybe Passware gets it wrong and tries to unlock it with ver. 9.
If i remember this correct - it says "Itunes Backup version 5" ( I will check this Monday).

so few hashes/s require EC2 cloud then i guess...

[GrepItAll]

I wouldn't be surprised if it was version 9, particularly if UFED cracked it too (UFED's cracking performance is much worse than Hashcat's)

Amazon cloud is an option, or just invest in a machine with some beefier GPUs in. Depends how frequently you need to do this kind of cracking.