Logical Volume size 0 bytes

[melts-net]

Hi to give a little background - I'm trying to get data from a macbook air that got rather wet. The PCI-E SSD seems intact, but I doubt it was cleanly shutdown.

using fvdeinfo on the encrypted partition I get this

fvdeinfo 20150222

Core Storage information:

Physical volume: Size: 120472952832 bytes Encryption method: AES XTS

Logical volume: Size: 0 bytes

and fvdemount -X allow_root -e ./EncryptedRoot.plist.wipekey -p user_password -v /dev/sda2 /mnt/container works, but the file /mnt/container/fvde1 is 0 bytes, can't be mounted, etc.

the debug output from fvdeinfo -v /dev/sda2 is 234MB, compressed is 87MB and is available at http://www.melts.net/debug.log.bz2

I'm going to see if I can figure it out myself, via the source - but I'll be honest I'm no programmer. I'm doing it as a favour for a friend who has uni assignments on it, so hoping i can bodge together a fix (i don't care if i overstate the size and can't even mount it, as long as i can scan the unencrypted data with photorec to receive the documents I'd be happy) but hopefully it's something trivial for you to deal with properly too.

[joachimmetz]

Thanks for the feedback and debug info, the quick and dirty way is to hack in the logical volume offset and size, e.g. here. I'll try to have a look at the debug output as soon as time permits, to see if I can find the culprit.

[melts-net]

Thanks for the help - I did provide a value - initially the same as the part size, and then made it a bit smaller, and found in both cases only the first 16781kB can be read. I compiled with just verbose logging and used that when mounting, and got a stream of these errors as I proceeded to go past the limit (with all but the handle_seek_offset numeric values changing) -

libcfile_file_seek_offset: unable to seek offset in file with error: Invalid argument
libbfio_file_seek_offset: unable to find offset in file: /dev/sda2.
libbfio_file_range_seek_offset: unable to seek offset in file IO handle.
libbfio_handle_seek_offset: unable to find offset: -1 in handle.
libfvde_sector_data_read: unable to seek sector data offset: 120568434688.
libfvde_io_handle_read_sector: unable to read sector data.
libfdata_vector_get_element_value_by_index: unable to read element data at offset: 0x1c12705000.
libfdata_vector_get_element_value_at_offset: unable to retrieve element: 219264 value.
libfvde_volume_read_buffer: unable to retrieve sector data at offset: 112263168.
mount_handle_read_buffer: unable to read buffer from input volume.
fvdemount_fuse_read: unable to read from mount handle.

I haven't confirmed the data the does come out is valid, but my cursory look (and mount's attempts) indicated the lead data wasn't a HFS+ superblock.

further to this I used dd without any continue on error and got this output from fvdemount -v ... running;

libfvde_sector_data_read: unable to read sector data.
libfvde_io_handle_read_sector: unable to read sector data.
libfdata_vector_get_element_value_by_index: unable to read element data at offset: 0x1c0cbf6000.
libfdata_vector_get_element_value_at_offset: unable to retrieve element: 32776 value.
libfvde_volume_read_buffer: unable to retrieve sector data at offset: 16781312.
mount_handle_read_buffer: unable to read buffer from input volume.
fvdemount_fuse_read: unable to read from mount handle.
libcfile_file_seek_offset: unable to seek offset in file with error: Invalid argument
libbfio_file_seek_offset: unable to find offset in file: /dev/sda2.
libbfio_file_range_seek_offset: unable to seek offset in file IO handle.
libbfio_handle_seek_offset: unable to find offset: -1 in handle.
libfvde_sector_data_read: unable to seek sector data offset: 120473063424.
libfvde_io_handle_read_sector: unable to read sector data.
libfdata_vector_get_element_value_by_index: unable to read element data at offset: 0x1c0cc11000.
libfdata_vector_get_element_value_at_offset: unable to retrieve element: 32992 value.
libfvde_volume_read_buffer: unable to retrieve sector data at offset: 16891904.
mount_handle_read_buffer: unable to read buffer from input volume.
fvdemount_fuse_read: unable to read from mount handle.
libfvde_sector_data_read: unable to read sector data.
libfvde_io_handle_read_sector: unable to read sector data.
libfdata_vector_get_element_value_by_index: unable to read element data at offset: 0x1c0cbf6000.
libfdata_vector_get_element_value_at_offset: unable to retrieve element: 32776 value.
libfvde_volume_read_buffer: unable to retrieve sector data at offset: 16781312.
mount_handle_read_buffer: unable to read buffer from input volume.
fvdemount_fuse_read: unable to read from mount handle.

the offset appears to be above the partition -

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

	Slot	Start	End	Length	Description
00:	Meta	0000000000	0000000000	0000000001	Safety Table
01:	-----	0000000000	0000000039	0000000040	Unallocated
02:	Meta	0000000001	0000000001	0000000001	GPT Header
03:	Meta	0000000002	0000000033	0000000032	Partition Table
04:	00	0000000040	0000409639	0000409600	EFI System Partition
05:	01	0000409640	0235708375	0235298736	Macintosh HD
06:	02	0235708376	0236978135	0001269760	Recovery HD
07:	-----	0236978136	0236978175	0000000040	Unallocated

The volume is 120472952832 bytes it is seeking to 120473063424 - so it seems like it isn't reading the data in the volume but jumping to the end.

let me know if you need me to provide anything to help. I'm rather curious now on why it doesn't read the volume data. the image is only 113GB - i could upload that from work in a day if you wanted it.

• edited it for formatting

[joachimmetz]

So the library expects that the "com.apple.corestorage.lv.size" in the plist in metadata block data type 0x001a contains the logical volume size. However I don't see this metadata block in your debug output.

the image is only 113GB - i could upload that from work in a day if you wanted it.

Thanks for the offser, yes that is very useful. In the mean time I'll continue looking at the debug information, it "should" contains most of the relevant metadata.

[saizai]

/sub

[eoyslebo]

I have the same issue:

fvdeinfo -v -o 209735680 -e EncryptedRoot.plist.wipekey -p 'workingpassword' filevault.dd

fvdeinfo 20151013 Core Storage information: Physical volume: Size: 250140434432 bytes Encryption method: AES XTS Logical volume: Size: 0 bytes

fvdemount "works" and does not report any issues, but the file in the mounted directory is empty.

[arcticforensics]

I have the exact problem with libfvde 20160108. Is there a solution?

[joachimmetz]

Is there a solution?

not yet, these issues are caused by format changes, I have not found the time to look at them and address the issue

[joachimmetz]

This is due to changes in the format. Closing this issue in favor of https://github.com/libyal/libfvde/issues/2