+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: iTunes backup crack too slow (/thread-8214.html)
iTunes backup crack too slow - Drshu - 03-11-2019
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/sBut 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.txtIs that have any problem?Thx
RE: iTunes backup crack too slow - atom - 03-11-2019
I've fixed this on GitHub master and created a new beta on https://hashcat.net/beta/
Thanks for reporting!
RE: iTunes backup crack too slow - Drshu - 03-12-2019
(03-11-2019, 11:21 AM)atom Wrote: I've fixed this on GitHub master and created a new beta on https://hashcat.net/beta/Unfortunately, I tried to compile by my self with the lasted version[6e0ef6984c1a595b668d042139727d59262ea792] code. When I run
Thanks for reporting!
Code:
./hashcat -m 14800 -bCode:
[1] 46437 segmentation fault ./hashcat -m 14800 -bMy OS is macOS 10.14.3. BTW, after compiling, I got some permission issue.I had to use
Code:
chmod -R 777RE: iTunes backup crack too slow - Drshu - 03-12-2019
(03-11-2019, 11:21 AM)atom Wrote: 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/sRE: iTunes backup crack too slow - philsmd - 03-12-2019
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
RE: iTunes backup crack too slow - Drshu - 03-13-2019
(03-12-2019, 12:01 PM)philsmd Wrote: 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*f91b9146965b554cfac7e0869b422afe93328e70RE: iTunes backup crack too slow - philsmd - 03-13-2019
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.
RE: iTunes backup crack too slow - Drshu - 03-14-2019
(03-13-2019, 09:47 AM)philsmd Wrote: 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
RE: iTunes backup crack too slow - atom - 03-14-2019
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:
Quote:$ ./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:
Quote:$ ./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:
Quote:$ ./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