Closed eternaleye closed 2 years ago
<dict>
<key>com.apple.corestorage.label.sequence</key>
<integer size="32">0x1</integer>
<key>com.apple.corestorage.lvg.uuid</key>
<string>UUID_WAS_SNIPPED</string>
<key>com.apple.corestorage.lvg.name</key>
<string>Macintosh HD</string>
<key>com.apple.corestorage.lvg.physicalVolumes</key>
<array>
<string>UUID_WAS_SNIPPED</string>
</array>
</dict>
This might be related to the array
After patching the library to hardcode the LVF UUID (and skip the related checks), I got it to make progress - However, it now fails in libfvde_io_handle_read_logical_volume_header
. If I add a debug print, I see it's called twice - once on a volume with the signature 0x28ec
, and once on a volume with the signature 0xe33b
.
This is the layout of the (last listing of) volumes, on a 750GB (~700GiB) drive:
libfvde_encrypted_metadata_read_type_0x0405: number of entries : 10
libfvde_encrypted_metadata_read_type_0x0405: unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 000 block number : 0
libfvde_encrypted_metadata_read_type_0x0405: entry: 000 number of blocks : 12066944
libfvde_encrypted_metadata_read_type_0x0405: entry: 000 data type : 0x00000009
libfvde_encrypted_metadata_read_type_0x0405: entry: 000 copy number : 0
libfvde_encrypted_metadata_read_type_0x0405: entry: 000 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 000 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 001 block number : 12066944
libfvde_encrypted_metadata_read_type_0x0405: entry: 001 number of blocks : 65536
libfvde_encrypted_metadata_read_type_0x0405: entry: 001 data type : 0x00000009
libfvde_encrypted_metadata_read_type_0x0405: entry: 001 copy number : 0
libfvde_encrypted_metadata_read_type_0x0405: entry: 001 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 001 unknown2 : 0xfffffffffffffffe
libfvde_encrypted_metadata_read_type_0x0405: entry: 002 block number : 12132480
libfvde_encrypted_metadata_read_type_0x0405: entry: 002 number of blocks : 171049984
libfvde_encrypted_metadata_read_type_0x0405: entry: 002 data type : 0x00000009
libfvde_encrypted_metadata_read_type_0x0405: entry: 002 copy number : 0
libfvde_encrypted_metadata_read_type_0x0405: entry: 002 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 002 unknown2 : 0x00b82080
libfvde_encrypted_metadata_read_type_0x0405: entry: 003 block number : 183191190
libfvde_encrypted_metadata_read_type_0x0405: entry: 003 number of blocks : 6144
libfvde_encrypted_metadata_read_type_0x0405: entry: 003 data type : 0xfffffffffffffffd
libfvde_encrypted_metadata_read_type_0x0405: entry: 003 copy number : 1
libfvde_encrypted_metadata_read_type_0x0405: entry: 003 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 003 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 004 block number : 183197334
libfvde_encrypted_metadata_read_type_0x0405: entry: 004 number of blocks : 6144
libfvde_encrypted_metadata_read_type_0x0405: entry: 004 data type : 0xfffffffffffffffd
libfvde_encrypted_metadata_read_type_0x0405: entry: 004 copy number : 0
libfvde_encrypted_metadata_read_type_0x0405: entry: 004 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 004 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 005 block number : 183203478
libfvde_encrypted_metadata_read_type_0x0405: entry: 005 number of blocks : 1024
libfvde_encrypted_metadata_read_type_0x0405: entry: 005 data type : 0xfffffffffffffffb
libfvde_encrypted_metadata_read_type_0x0405: entry: 005 copy number : 0
libfvde_encrypted_metadata_read_type_0x0405: entry: 005 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 005 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 006 block number : 183204502
libfvde_encrypted_metadata_read_type_0x0405: entry: 006 number of blocks : 1024
libfvde_encrypted_metadata_read_type_0x0405: entry: 006 data type : 0xfffffffffffffffb
libfvde_encrypted_metadata_read_type_0x0405: entry: 006 copy number : 1
libfvde_encrypted_metadata_read_type_0x0405: entry: 006 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 006 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 007 block number : 183205526
libfvde_encrypted_metadata_read_type_0x0405: entry: 007 number of blocks : 1024
libfvde_encrypted_metadata_read_type_0x0405: entry: 007 data type : 0xfffffffffffffffb
libfvde_encrypted_metadata_read_type_0x0405: entry: 007 copy number : 2
libfvde_encrypted_metadata_read_type_0x0405: entry: 007 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 007 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 008 block number : 183206550
libfvde_encrypted_metadata_read_type_0x0405: entry: 008 number of blocks : 1024
libfvde_encrypted_metadata_read_type_0x0405: entry: 008 data type : 0xfffffffffffffffb
libfvde_encrypted_metadata_read_type_0x0405: entry: 008 copy number : 3
libfvde_encrypted_metadata_read_type_0x0405: entry: 008 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 008 unknown2 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 009 block number : 183207574
libfvde_encrypted_metadata_read_type_0x0405: entry: 009 number of blocks : 1
libfvde_encrypted_metadata_read_type_0x0405: entry: 009 data type : 0xfffffffffffffffc
libfvde_encrypted_metadata_read_type_0x0405: entry: 009 copy number : 1
libfvde_encrypted_metadata_read_type_0x0405: entry: 009 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0405: entry: 009 unknown2 : 0x00000000
If I force it to accept either of those volume signatures, then I get a fvde1 volume of no discernible filesystem format, measuring 47901573120
bytes in size. Given the sizes (47901573120 / 4096 = 11694720
), I suspect fvdemount
is deciding that entry 000
is more meaningful than it is, and the solution has something to do with how entry 002
has an unusual unknown2
value (given it's the largest volume, I suspect it's the one that SHOULD be mounting).
Confirming the same non-verbose message as in original post. Receive the same error using 'a full device image with an offset' or using 'the partition image with no offset'.
Same here.
Looks like a multi extent logical volume closing in favor of https://github.com/libyal/libfvde/issues/2
Non-verbose output:
Turning on verbose output yields the following info (with everything before the seeming error removed, and UUIDs snipped out, as I don't know what is/isn't private):