libyal / libfvde

Library and tools to access FileVault Drive Encryption (FVDE) encrypted volumes
GNU Lesser General Public License v3.0
339 stars 34 forks source link

4096 bytes per sector support? #23

Closed w3aryb0arpig closed 2 years ago

w3aryb0arpig commented 7 years ago

I have a dd physical image of a 250GB SSD (OS Sierra) from a FV2 encrypted Macbook Pro 2016. The block size for this device is 4096 bytes per sector.

I run mmls on the dd file and it shows the Start sector for my encrypted partition as being 0000076806 and Units are 4096-byte sectors.

I run the following command:-

*fvdemount -e EncryptedRoot.plist.wipekey -o $((768064096)) -p secret_password my_dd_image.dd /mount/point**

This seems to work with no errors and when I run file /mount/point/fvde1, it shows information as being a Macintosh HFS Extended version 4...... with block size 4096 and number of blocks as 60956672. Multiplying the block size by the number of blocks, this equates to 232GB (which is correct I believe for a 250GB HDD).

When I then seek to run mount -o loop,ro /mount/point/fvde1 /new_mount_point, it returns an error:

"mount: wrong fs type, bad option, bad superblock on /dev/loop1 ....... ......."

I then ran fvdeinfo my_dd_image.dd to see what info showed to see what the problem may be and this also returned an error:-

"Unable to open my_dd_image.dd libfvde_io_handle_read_volume_header: unsupported core storage signature libfvde_volume_open_read: unable to read volume header libfvde_volume_open_file_io_handle: unable to read from file IO handle info_handle_open_input: unable to open input volume."

libfvde has worked without any problem on other FV2 encrypted Macbooks with sector sizes of 512 bytes but I'm struggling with this one that has sector sizes of 4096bytes.

Is this a known issue?

I have made a dd image of /mount/point/fvde1 and the outputted file is 18GB in total which isn't consistent with the expected filesize

Looking at the sourcecode for the libfvde_io_handle.c, although I am not a C programmer, am I correct in thinking that the sector size is hard-coded as 512 bytes?

joachimmetz commented 7 years ago

Can you provide me with verbose and debug output: https://github.com/libyal/libfvde/wiki/Troubleshooting#verbose-and-debug-output

The reason why you cannot mount the HFS volume might be different then the sector size.

w3aryb0arpig commented 7 years ago

Hi @joachimmetz. FYI, I edited the libfvde_io_handle.c code, replacing the two entries of '512' with '4096' and it worked perfectly :). I think the problem lies in that a sector size of 512 is hardcoded in the libfvde_io_handle.c file from what I can tell and the latest Macbooks have a sector size of 4096

joachimmetz commented 7 years ago

Thanks I'll have a look at populating this from the CS volume header then. Could you confirm the number of bytes per sector in the debug output is 4k ?

w3aryb0arpig commented 7 years ago

@joachimmetz, do you want me to check the number of byters per sector in the debug output for your original code or for my compiled code in which I have changed the sector size in the _libfvde_iohandle.c code to 4096?

I have checked the debug output for the compiled code with the changes made to _libfvde_iohandle.c and the output does show:

_"libfvde_io_handle_read_logical_volumeheader: block size: 4096"

joachimmetz commented 7 years ago

block size is logical block size not bytes per sectors, at the top of the debug output the Core Storage volume header is printed. If you can provide me with a copy of that, that would be useful. E.g.

libfvde_io_handle_read_volume_header: unknown3c             : 0x00000000
libfvde_io_handle_read_volume_header: bytes per sector          : 512
libfvde_io_handle_read_volume_header: unknown4a             : 0x00000000
w3aryb0arpig commented 7 years ago

As request @joachimmetz

screen shot 2017-05-15 at 19 31 38

libfvde_io_handle_read_volume_header: bytes per sector : 512 libfvde_io_handle_read_volume_header: unknown4a : 0x00000000 libfvde_io_handle_read_volume_header: unknown4b : 0x00000000 libfvde_io_handle_read_volume_header: physical volume size : 250035572736

joachimmetz commented 7 years ago

@w3aryb0arpig thanks, I'll have a look as soon as time permits if I can add 4k sector support

w3aryb0arpig commented 7 years ago

Thanks @joachimmetz. One of my colleagues is also actively looking at this issue and a solution. If we do manage to resolve it prior to you, we will share our solution with you

edp05373 commented 6 years ago

Hi everyone. Any updates? I am also coming across issues with a 4k byte sector image.

Unfortunately I am not a coder and rather not screw this up.

Thanks!

w3aryb0arpig commented 6 years ago

Hi @edp05373. Only just seen this. Have you identified a solution or do you still require support?

edp05373 commented 6 years ago

Hello. I found a workaround.

Thanks for checking in!

mlen commented 6 years ago

@edp05373 could you share your workaround?

lotusamurai commented 6 years ago

I was having a similar odd problem where fvdemount was giving me a logical file that was much smaller than my expectation. I ended up with a 3.3GB fvde file while my partition was actually around 230GB. My mount command was throwing the same as in the OP for this topic.

It might not be applicable to every case, but in the event you need to access the contents of a raw image and don't really care how you get there, it is helpful.

I noticed that the code has a specific point where it sets the size of the logical volume. Specifically, in the libfvde_volume.c file. Line 1571:

internal_volume->io_handle->logical_volume_size = internal_volume->primary_encrypted_metadata->logical_volume_size; Since my logical file was just too small to interact with, I just increased the size of the internal_volume->io_handle->logical_volume_size variable by adding the following line immediately after the above:

internal_volume->io_handle->logical_volume_size = 250140434432;

You could likely increase that integer to something ridiculous like 5TB to be safe. After altering that line and rebuilding the code, my mount gave me a fvde1 that was large enough to contain the end of the HFS+ filesystem, and thus was mountable.

I hope this is helpful to anyone else out there that runs into a similar problem.

joachimmetz commented 6 years ago

@lotusamurai your issue is more related to https://github.com/libyal/libfvde/issues/2

I have a 4k storage media image now with a FVDE volume, having a look what I can find.

joachimmetz commented 6 years ago

My initial findings are that bytes per sector internally libfvde works when it is 512 (even for 4k sector storage media), however the initial offset needs to be sector x 4k. The incorrect volume sizes are like due to lacking format support.

joachimmetz commented 2 years ago

Closing in favor of https://github.com/libyal/libfvde/issues/2