Missing drive encryption context plist

joachimmetz commented 2 years ago

I'd like to help contribute to this issue and it just so happens I have a drive that gets the dreaded "Unable to unlock source volume" error of #34 and #41 fame. I'm not sure what the issue is, but I see that it does have a section 0x0505 and it only has one physical and one logical volume. Below is the output of fvdeinfo and the debug log from fvdemount.

fvdeinfo 20220125

Logical volume: 1 is locked and a password is needed to unlock it.

Password: 

Unable to unlock volume.

Core Storage information:

Logical volume group:
        Identifier                      : ef237066-fea3-4327-8c8a-11735a2b05ad
        Name                            : South America
        Number of physical volumes      : 1
        Number of logical volumes       : 1

Physical volume: 1
        Identifier                      : 16a74bae-2148-458f-9168-0baf6c756509
        Size                            : 3.4 TiB (3800274411520 bytes)
        Encryption method               : AES-XTS 128-bit

Logical volume: 1
        Identifier                      : ec33f8f9-8e80-4e08-8296-46a7be62ad6a
        Name                            : South America
        Size                            : 3.4 TiB (3799903109120 bytes)
        Is locked

fvdetools_south_america.log

Based on the "invalid logical volume - volume is locked" message, it looks like I'm hitting this in libfvde_internal_logical_volume_read_buffer_from_file_io_pool, or this in libfvde_internal_logical_volume_seek_offset. This just looks like a symptom though, and I'm not familiar enough with the code base to figure out the root cause.

If you can point me in the right direction, I can investigate by looking at hex offsets and matching them up to the code and slides linked to in the README file. The quantity of debug information is just a bit overwhelming for me, as I'm just picking up Apple Core Storage and FileVault tonight.

Originally posted by @anon8675309 in https://github.com/libyal/libfvde/issues/2#issuecomment-1101981365

joachimmetz commented 2 years ago

@anon8675309 did you provide a password? I see no unlock attempt in fvdetools_south_america.log

anon8675309 commented 2 years ago

Thanks for the rapid response. I did provide a password, but I redacted it from the log I posted (on line 33764). However, I did some debugging and it looks like you are spot on about it not attempting to unlock anything.

It's worth noting is that this is an external drive and I am not specifying a wipekey (per the documentation on mounting).

I'm not sure if this matters, but another thing that struck me as odd is that I still get prompted for a password even when it was specified on the command line (-p Password). My debugging (below) seems to indicate that the password is being plumbed through properly though.

Debugging:

Using gdb, I can see mount_handle->user_password has my password at fvdetools/mount_handle.c:1045, so I know it's getting in there correctly
At line 1112, result and mount_handle->unattended_mode are both zero
At line 1162, I can see the password was correctly copied to ((libfvde_internal_logical_volume_t *)logical_volume)->user_password
After libfvde/libfvde_logical_volume.c:1313 executes, the result will be 0
It looks like I'm falling through the cracks in libfvde_internal_logical_volume_open_read_keys:
- Line 747: internal_logical_volume->encrypted_metadata->encryption_context_plist_file_is_set = 0
- Line 775: internal_logical_volume->encrypted_root_plist = 0
- Line 804: internal_logical_volume->volume_master_key_is_set = 0
- and now we're basically out of libfvde_internal_logical_volume_open_read_keys
- Line 922, internal_logical_volume->volume_data_handle->encryption_context is NULL

Looking at slide 17, it looks like I should have an encrypted plist, but I think this only applies for internal drives based on the fact that I don't have a "Recovery HD". Here's the output of mmls /dev/sda:

GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Safety Table
001:  -------   0000000000   0000000039   0000000040   Unallocated
002:  Meta      0000000001   0000000001   0000000001   GPT Header
003:  Meta      0000000002   0000000033   0000000032   Partition Table
004:  000       0000000040   0000409639   0000409600   EFI System Partition
005:  001       0000409640   0391034631   0390624992   Frankenstein
006:  -------   0391034632   0391296775   0000262144   Unallocated
007:  002       0391296776   7813707735   7422410960   South America
008:  003       7813707736   7813969879   0000262144   Booter
009:  -------   7813969880   7813969919   0000000040   Unallocated

If there is some way to manually extract this plist from an external drive and then use the -e flag, I'd be happy to give that a try.

BTW those slides are amazingly helpful in understanding the decryption process and matching that up with the codebase. Thank you so much for not only doing the research and publishing and maintaining code, but also presenting your work so clearly and concisely!

joachimmetz commented 2 years ago

it looks like I should have an encrypted plist, but I think this only applies for internal drives based on the fact that I don't have a "Recovery HD".

try if "Booter" contains an external encrypted plist

anon8675309 commented 2 years ago

Booter did contain an encrypted plist, but it did not work to unlock the drive. I believe this disk was in a machine called Frankenstein at one point (based on the output of mmls) and the plist was probably for that partition. The output of fvdemount looks slightly different, but it's still "Unable to unlock volume." I just mounted this drive on a mac to confirm the password I'm using is correct. It can unlock it without any problems, so whatever is needed to unlock the volume must be on there somewhere.

Output from the commands:

# fls -r -o 7813707736 /dev/sda | grep -i EncryptedRoot
+++ r/r 31:     EncryptedRoot.plist.wipekey
# icat -o 7813707736 /dev/sda 31 > EncryptedRoot.plist.wipekey
# ./fvdetools/fvdemount -v -p '[REDACTED]' -e EncryptedRoot.plist.wipekey /dev/sda3 /tmp/mnt 2> fvdetools_south_america-attempt3.log
fvdemount 20220125

Logical volume: 1 is locked and a password is needed to unlock it.

Password: 

Unable to unlock volume.

And the new log with passwords and hexdumps of keys redacted: fvdetools_south_america-attempt3.log

In the debugger:

internal_logical_volume->encrypted_root_plist is non-NULL
libfvde_encrypted_metadata_get_volume_master_key returns 0
in libfvde_encrypted_metadata.c:6043 is non-NULL
- everything in libfvde_encrypted_metadata_get_volume_master_key seems to go okay

joachimmetz commented 2 years ago

the metadata block that typically contains a "removeable" drive encryption context plist is 0x0019. From fvdetools_south_america-attempt3.log

libfvde_metadata_block_read_data: signature                             : LVFwiped
libfvde_metadata_block_read_data: version                               : 1
libfvde_metadata_block_read_data: type                                  : 0x0019
libfvde_metadata_block_read_data: serial number                         : 0x02053201
libfvde_metadata_block_read_data: transaction identifier                : 2
libfvde_metadata_block_read_data: object identifier                     : 9
libfvde_metadata_block_read_data: number                                : 9
libfvde_metadata_block_read_data: unknown5                              : 0x00000009
libfvde_metadata_block_read_data: size                                  : 8192
libfvde_metadata_block_read_data: unknown6                              : 0x00000006
libfvde_metadata_block_read_data: unknown7                              : 0x00000000

libfvde_metadata_block_read_data: data:
00000000: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
...
00001fb0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........

This is empty, so that means internal_logical_volume->encrypted_metadata1->encryption_context_plist_data and internal_logical_volume->encrypted_metadata2->encryption_context_plist_data are not set.

Must be missing part of the puzzle here. I'll have another look when time permits.

libyal / libfvde

Missing drive encryption context plist #55