iTunes backup crack too slow

[Drshu]

I used the latest Hashcat (V5.1.0) and try to crack iTunes backup password. I found the speed of benchmark is too fast :

Code:

 hashcat -w 3 -m 14800 -b                                                
hashcat (v5.1.0-617-g512b8ed5) starting in benchmark mode...

OpenCL Platform #1: Apple
=========================
* Device #1: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz, skipped.
* Device #2: Intel(R) HD Graphics 630, 384/1536 MB allocatable, 24MCU
* Device #3: AMD Radeon Pro 560 Compute Engine, 1024/4096 MB allocatable, 16MCU

Benchmark relevant options:
===========================
* --workload-profile=3

Hashmode: 14800 - iTunes backup >= 10.0 (Iterations: 999)

Speed.#2.........:      988 H/s (8.23ms) @ Accel:2 Loops:250 Thr:8 Vec:1
Speed.#3.........:     8554 H/s (4.40ms) @ Accel:2 Loops:250 Thr:64 Vec:1
Speed.#*.........:     9542 H/s

But when I used the real key to crack, the speed only have 10 H/s  even use straight mode.

Code:

 hashcat  -m 14800 -a 0 -w 4 Path/iTunesKey.txt  Path/testDic.dict  -o Path/iTunesKeyword.txt

Is that have any problem?Thx

[atom]

I've fixed this on GitHub master and created a new beta on https://hashcat.net/beta/

Thanks for reporting!

[Drshu]

I've fixed this on GitHub master and created a new beta on https://hashcat.net/beta/

Thanks for reporting!

Unfortunately, I tried to compile by my self with the lasted version[6e0ef6984c1a595b668d042139727d59262ea792] code. When I run 

Code:

./hashcat -m 14800 -b

 , I got a fatal info 

Code:

[1]    46437 segmentation fault  ./hashcat -m 14800 -b

My OS is macOS 10.14.3. BTW, after compiling, I got some permission issue.I had to use 

Code:

chmod -R 777

to up its permission.

[Drshu]

I've fixed this on GitHub master and created a new beta on https://hashcat.net/beta/

Thanks for reporting!

I used another computer to compile and it worked. But the test speed still twice fast than real crack. 

Code:

hashcat (v5.1.0-719-gd6f21b08) starting in benchmark mode...

Benchmarking uses hand-optimized kernel code by default.
You can use it in your cracking session by setting the -O option.
Note: Using optimized kernel code limits the maximum supported password length.
To disable the optimized kernel code in benchmark mode, use the -w option.

/Users/Shu/Develop/macOS-Dev/hashcat/bin/usr/local/bin/OpenCL/m14800-optimized.cl: Optimized OpenCL kernel requested but not needed - falling back to pure OpenCL kernel
OpenCL Platform #1: Apple
=========================
* Device #1: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz, skipped.
* Device #2: Intel(R) HD Graphics 630, 384/1536 MB allocatable, 24MCU
* Device #3: AMD Radeon Pro 560 Compute Engine, 1024/4096 MB allocatable, 16MCU

Benchmark relevant options:
===========================
* --optimized-kernel-enable

Hashmode: 14800 - iTunes backup >= 10.0 (Iterations: 9999999)

Speed.#2.........:        3 H/s (55.39ms) @ Accel:128 Loops:64 Thr:8 Vec:1
Speed.#3.........:       19 H/s (81.68ms) @ Accel:256 Loops:64 Thr:64 Vec:1
Speed.#*.........:       22 H/s

[philsmd]

in this case it depends heavily on the iteration count. this information is stored/present within the hash itself.

the hash used within the benchmark uses 10000 iterations (iter) and 1000 iterations (dpic)

the format of the hashes is:
$itunes_backup$*10*WPKY*ITER*SALT*DPIC*DPSL

your ITER or DPIC numbers could be different from the benchmark (ITER = 10000, DPIC = 1000).

what are your numbers ?

btw: it's also important that you do not use multiple hashes, since the speed will decrease depending on the number of salts (of course!). benchmark uses a single hash

[Drshu]

in this case it depends heavily on the iteration count. this information is stored/present within the hash itself.

the hash used within the benchmark uses 10000 iterations (iter) and 1000 iterations (dpic)

the format of the hashes is:
$itunes_backup$*10*WPKY*ITER*SALT*DPIC*DPSL

your ITER or DPIC numbers could be different from the benchmark (ITER = 10000, DPIC = 1000).

what are your numbers ?

btw: it's also important that you do not use multiple hashes, since the speed will decrease depending on the number of salts (of course!). benchmark uses a single hash

Thanks for your reply. And this is my key:

Code:

$itunes_backup$*10*89949ce1d6da1d983cabc47a93e651f8e28db12884d44e465e6246fb46b77f5ef1a99d4665c5e980*10000*5e7a8e1f017ff1b133e7cedffef36f1f9e43e71f*10000000*f91b9146965b554cfac7e0869b422afe93328e70

I found the DPIC is 10000000 and ITER is 10000. And is that all iTunes backups after iOS 10 have the same number?If it that, I think we could change the benchmark's DPIC.

[philsmd]

that's interesting.

I'm not sure if we should change it though. One problem of changing a benchmark setting is always that users start comparing apple to oranges after the change (and they say "hey new hashcat version is much slower")

I think we've choosen the default values for good reasons (but I don't remember what the facts were in this case... normally it's a mix of what other crackers use and what the current version of the software/OS uses at the time of implementing the new hash type).

Of course there is a small possibility that the default values are/were just completely wrong from the beginning, but it's not the most likely case. If it is and was completely wrong, then I agree we should change it... but I think at least at the time of implementing this, we should've choosen the correct settings/values.

[Drshu]

that's interesting.

I'm not sure if we should change it though. One problem of changing a benchmark setting is always that users start comparing apple to oranges after the change (and they say "hey new hashcat version is much slower")

I think we've choosen the default values for good reasons (but I don't remember what the facts were in this case... normally it's a mix of what other crackers use and what the current version of the software/OS uses at the time of implementing the new hash type).

Of course there is a small possibility that the default values are/were just completely wrong from the beginning, but it's not the most likely case. If it is and was completely wrong, then I agree we should change it... but I think at least at the time of implementing this, we should've choosen the correct settings/values.

You are right, And I am not totally understand the "Iterations" mean. I mean I know what is it, but I do not know why mode 14800 have  to complete specific number of it. For instance, if we have a small keyspace like 100 word in wordlists. And my computer complete 10000000 times "Iterate" need about 5 mins, and my crack speed is 3 H/s. That's mean I could try 3*60*5 = 900 times in 5 mins or I just need 100/3 =· 33 secs to finish 100 times try. 

But Why we need 5 mins to crack it rather than 33 secs? And I read about https://hashcat.net/faq/morework , still confused. Have any articles to describe this? Thx

[atom]

I'm not sure what's the problem. All numbers match perfectly. I ran this on my rx480 which is the closest I have matching you GPU.

It's 10,000,000 iterations of PBKDF2-HMAC-SHA256. So let's benchmark PBKDF2-HMAC-SHA256 first:

$ ./hashcat -b -m 10900 -w 3 --machine
# version: v5.1.0-720-g4653447d
# option: --workload-profile=3
1:10900:1236:300:96.02:644529

Note the default iteration count of raw PBKDF2 based algorithms is 1000. So we have (644529 * 1000) / 10000000 = 64,45. Now benchmark of itunes 10:

$ ./hashcat -m 14800 -b
...
Speed.#1.........:       65 H/s (56.82ms) @ Accel:256 Loops:64 Thr:64 Vec:1

It couldn't be more exact. The benchmark speed also matches the real cracking performance:

$ ./hashcat -m 14800 hash.txt -a 3 ?l?l?l?l?l -u 64 -n 256 --force 
...
Speed.#1.........:       65 H/s (43.98ms) @ Accel:256 Loops:64 Thr:64 Vec:1