Hashcat - APFS – FileVault 2 - Looking for assurances!
#1
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
Reply
#2
If I understand it correctly, you have an APFS which is encrypted with Filevault2.
In order to extract the hash, you used apfs2hashcat, which gave you $fvde$1$...

Note that the hash mentions $1$, which means the Filevault was originally from HFS+-filesystem. An original APFS-filevault would have $fvde$2$...

Also, the hash you extracted has a different iterations count, namely 190883, in stead of the "default" 20000. This explains your question why your hash is one char longer.

Imho, JtR isn't compatible with variable iterations, and Hashcat is. But that is a guess.
Other smarter people will confirm this or not.
Reply