06-16-2020, 05:48 PM
Hi,
I’m currently working a case where a dd/raw image of a MacBook pro has been acquired and where the FileVault 2 key needs decrypting in order that a forensic analysis of the data on the disk can be undertaken.
I should say that I believe that I have recovered a valid key from the APFS volume encrypted with FileVault 2 and that hashcat is currently attempting to crack the key.
However, in accordance with good forensic practice I was looking for some form of dual verification and thought that this could simply be achieved by validating the recovered hash using john (jtr). Unfortunately, john doesn’t recognise the hash as being valid and I’m now trying to work out why? And what the reason for the anomaly is!
Set out below are most of the steps I have taken together with their results.
Using mmls against the raw image I get:
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Safety Table
001: ------- 0000000000 0000000005 0000000006 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
003: Meta 0000000002 0000000005 0000000004 Partition Table
004: 000 0000000006 0000076805 0000076800 EFI System Partition
005: 001 0000076806 0122138126 0122061321 NoName – (apfs-partition)
006: ------- 0122138127 0244190645 0122052519 Unallocated
Apfs-quick-dump abridged out:
Device /xxxx/xxxxt/xxxxx/xxxx.img opened. Size is 500277788672
Info: Found valid GPT partition table on main device. Dumping first APFS partition.
Found more recent xid 2478513 than superblock 0 contained (2409434).
starting LoadKeybag
all blocks verified
starting LoadKeybag
all blocks verified
Volume Macintosh HD is encrypted.
starting LoadKeybag
all blocks verified
Enter Password:
Dumping Keybag (keys)
…
[KEK]
Unk 80 : 0
UUID : 40541C3D-8F1C-4704-9F8D-3EAF241D90F4
Unk 82 : 00000002 0002 78 169
KEK Wrpd: 3BD8CCACD8A191443F0F7F91EACA443C8056198E166A249900000000000000000000000000000000
Iterat's: 190883
Salt : 275A81922F7B21E8FAD9130F395D8D33
….
Having removed the padding and concatenated the salt, iteration and hash I was left with:
$fvde$1$16$275A81922F7B21E8FAD9130F395D8D33$190883$3BD8CCACD8A191443F0F7F91EACA443C8056198E166A2499.
Running apfs2hashcat produces the same output/ hash result and as can be seen from the following, hashcat seems to accept the hash as valid and attempts to crack the hash.
Status...........: Running
Hash.Name........: FileVault 2
Hash.Target......: $fvde$1$16$275a81922f7b21e8fad9130f395d8d33$190883$...6a2499
Guess.Base.......: File (/mnt/aa_passwd_to_use/allpsswd)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 4185 H/s (11.63ms) @ Accel:128 Loops:32 Thr:64 Vec:1
Speed.#2.........: 4111 H/s (11.85ms) @ Accel:128 Loops:32 Thr:64 Vec:1
Speed.#*.........: 8296 H/s
Recovered........: 0/1 (0.00%) Digests
Progress.........: 0/48637534 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/48637534 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:45728-45760
Restore.Sub.#2...: Salt:0 Amplifier:0-1 Iteration:45024-45056
Hardware.Mon.#1..: Temp: 47c Fan: 26% Core:1366MHz Mem:2000MHz Bus:0
Hardware.Mon.#2..: Temp: 52c Fan: 26% Core:1326MHz Mem:2000MHz Bus:0
I should also mention that I have grabbed a number of example filevault2 hashes from other posts and tried these in both hashcat, john and various ‘hash identifier programmes’.
None of the hash identifiers recognise any of the hashes and john only recognises some. Hashcat recognises all of them!
I have also noticed that some of the hashes, extracted, including mine are one character longer than some of the others. All salts and iterations are the same length.
As a consequnece, I’m now wondering whether the shorter hashes recognised by john, relate to filevault2 hashes acquired, prior to the deployment of APFS and this could be the reason for the anomaly. At present, I have no way of either testing or confirming this theory.
The only other alternative I can come up with, is that I’ve made a complete Horlicks of things and hashcat is doing it’s best to decrypt an invalid hash!
If anyone can shed any light on this it would be much appreciated.
Finally, I should also add that I have recovered other information, which is being used to create dedicated wordlist(s), rules etc, so as to reduce the keyspace as part of this exercise and that any crcaking in earnest will be taking place on a bigger rig.
I simply want to try and understand why hashcat recognises the hash created and john doesn’t.
Thanks in advance
25512
I’m currently working a case where a dd/raw image of a MacBook pro has been acquired and where the FileVault 2 key needs decrypting in order that a forensic analysis of the data on the disk can be undertaken.
I should say that I believe that I have recovered a valid key from the APFS volume encrypted with FileVault 2 and that hashcat is currently attempting to crack the key.
However, in accordance with good forensic practice I was looking for some form of dual verification and thought that this could simply be achieved by validating the recovered hash using john (jtr). Unfortunately, john doesn’t recognise the hash as being valid and I’m now trying to work out why? And what the reason for the anomaly is!
Set out below are most of the steps I have taken together with their results.
Using mmls against the raw image I get:
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Safety Table
001: ------- 0000000000 0000000005 0000000006 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
003: Meta 0000000002 0000000005 0000000004 Partition Table
004: 000 0000000006 0000076805 0000076800 EFI System Partition
005: 001 0000076806 0122138126 0122061321 NoName – (apfs-partition)
006: ------- 0122138127 0244190645 0122052519 Unallocated
Apfs-quick-dump abridged out:
Device /xxxx/xxxxt/xxxxx/xxxx.img opened. Size is 500277788672
Info: Found valid GPT partition table on main device. Dumping first APFS partition.
Found more recent xid 2478513 than superblock 0 contained (2409434).
starting LoadKeybag
all blocks verified
starting LoadKeybag
all blocks verified
Volume Macintosh HD is encrypted.
starting LoadKeybag
all blocks verified
Enter Password:
Dumping Keybag (keys)
…
[KEK]
Unk 80 : 0
UUID : 40541C3D-8F1C-4704-9F8D-3EAF241D90F4
Unk 82 : 00000002 0002 78 169
KEK Wrpd: 3BD8CCACD8A191443F0F7F91EACA443C8056198E166A249900000000000000000000000000000000
Iterat's: 190883
Salt : 275A81922F7B21E8FAD9130F395D8D33
….
Having removed the padding and concatenated the salt, iteration and hash I was left with:
$fvde$1$16$275A81922F7B21E8FAD9130F395D8D33$190883$3BD8CCACD8A191443F0F7F91EACA443C8056198E166A2499.
Running apfs2hashcat produces the same output/ hash result and as can be seen from the following, hashcat seems to accept the hash as valid and attempts to crack the hash.
Status...........: Running
Hash.Name........: FileVault 2
Hash.Target......: $fvde$1$16$275a81922f7b21e8fad9130f395d8d33$190883$...6a2499
Guess.Base.......: File (/mnt/aa_passwd_to_use/allpsswd)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 4185 H/s (11.63ms) @ Accel:128 Loops:32 Thr:64 Vec:1
Speed.#2.........: 4111 H/s (11.85ms) @ Accel:128 Loops:32 Thr:64 Vec:1
Speed.#*.........: 8296 H/s
Recovered........: 0/1 (0.00%) Digests
Progress.........: 0/48637534 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/48637534 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:45728-45760
Restore.Sub.#2...: Salt:0 Amplifier:0-1 Iteration:45024-45056
Hardware.Mon.#1..: Temp: 47c Fan: 26% Core:1366MHz Mem:2000MHz Bus:0
Hardware.Mon.#2..: Temp: 52c Fan: 26% Core:1326MHz Mem:2000MHz Bus:0
I should also mention that I have grabbed a number of example filevault2 hashes from other posts and tried these in both hashcat, john and various ‘hash identifier programmes’.
None of the hash identifiers recognise any of the hashes and john only recognises some. Hashcat recognises all of them!
I have also noticed that some of the hashes, extracted, including mine are one character longer than some of the others. All salts and iterations are the same length.
As a consequnece, I’m now wondering whether the shorter hashes recognised by john, relate to filevault2 hashes acquired, prior to the deployment of APFS and this could be the reason for the anomaly. At present, I have no way of either testing or confirming this theory.
The only other alternative I can come up with, is that I’ve made a complete Horlicks of things and hashcat is doing it’s best to decrypt an invalid hash!
If anyone can shed any light on this it would be much appreciated.
Finally, I should also add that I have recovered other information, which is being used to create dedicated wordlist(s), rules etc, so as to reduce the keyspace as part of this exercise and that any crcaking in earnest will be taking place on a bigger rig.
I simply want to try and understand why hashcat recognises the hash created and john doesn’t.
Thanks in advance
25512