Missing drive encryption context plist

[joachimmetz]

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 #2 (comment)

[joachimmetz]

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

[anon8675309]

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]

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]

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]

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.

[jaspervanveghel]

To tack on to this — I've also followed down the same route for an SD card with CS encryption:

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 66DF949D-A6B3-4592-97E6-738ECA37BFA3
    =========================================================
    Name:         Database
    Status:       Online
    Size:         127521480704 B (127.5 GB)
    Free Space:   18964480 B (19.0 MB)
    |
    +-< Physical Volume A2FC4FC3-65B4-4EAA-A803-42986FE82258
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk4s2
    |   Status:   Online
    |   Size:     127521480704 B (127.5 GB)
    |
    +-> Logical Volume Family ACE9803B-79A2-4382-A03E-E24E97FAC968
        ----------------------------------------------------------
        Encryption Type:         AES-XTS
        Encryption Status:       Locked
        Conversion Status:       Complete
        High Level Queries:      Fully Secure
        |                        Passphrase Required
        |                        Accepts New Users
        |                        Has Visible Users
        |                        Has Volume Key
        |
        +-> Logical Volume 415D1992-7365-4CD4-8D04-B4FD0362495F
            ---------------------------------------------------
            Disk:                  -none-
            Status:                Locked
            Size (Total):          127150194688 B (127.2 GB)
            Revertible:            Yes (unlock and decryption required)
            LV Name:               Database
            Content Hint:          Apple_HFS

As per the above 0x0019 also contains LVFwiped and no data. I've checked with mmls / fls for EncryptedRoot.plist but haven't found one which is in line with this being external media (SD card).

Presumably since diskutil cs list indicates "Has Visible Users" there should be metadata somewhere present on the volume. Could it be that the encryption context is stored somewhere other than in 0x0019? Any pointers for where to look are welcome and I can see if I can come up with a patch or solution.

[holly-o]

I also have the same issue on a removable drive where all metadata blocks of type 0x0019 have "LVFwiped" in the header and no data in these blocks. Is it possible the encryption context is elsewhere or that it has no encryption context?

[jaspervanveghel]

@joachimmetz I've managed to solve this issue for my case by improving empty block marking in libfvde_encrypted_metadata.c. Presently when it detects an empty block it will set empty_block_found = 1 once which then stays set for all subsequent blocks. In my case the non-LVFwiped 0x0019 block came after an empty block, as did a number of other blocks, e.g. 0x0405 with updates to the logical volume layout. I've created PR #68 with a fix.

I noticed that there were quite a few additional blocks after the empty block; it seems that CoreStorage (or the version my volume was created with) retains all previous block versions. In case the blocks are versioned and inserted out-of-order then this fix could conceivably lead to regressions for volumes which presently do work.