On Linux v.4.0.6. fails to decrypt APFS partition that v.3.17.1 could decrypt - Sleuthkit 4.11.1 issue

[reacan]

Hello!

I tried to process an image of an encrypted macbook using both v.4.0.3 and v.4.0.6 and both failed to decrypt an APFS partition encrypted with File Vault 2.

It appears to be a Sleuthkit related problem because the old version (4.6.5) can decrypt the partition. I tried reinstalling 4.11.1 by cloning the repo as per the instruction (git clone -b release-4.11.1_iped_patch https://github.com/sepinf-inc/sleuthkit), the installation process completed with no errors, but it still fails to decrypt my image.

Am I missing something or is there an issue with the new version of Sleuthkit? Please let me know if you require some additional information.

fsstat -V The Sleuth Kit ver 4.11.1-iped-patch

fsstat -i ewf -o 76806 -B 632365 -b 4096 -f apfs -k password macbook_fv2.E01 General file system error (tsk_apfs_open: APFSBtreeNode: invalid object type)

./fsstat -V The Sleuth Kit ver 4.6.5-iped-patch04

./fsstat -i ewf -o 76806 -B 632365 -b 4096 -f apfs -k password macbook_fv2.E01

FILE SYSTEM INFORMATION File System Type: APFS Volume UUID 89e4887f-4cec-3387-9eba-a10a550e5428 APSB Block Number: 632365 APSB oid: 1027 APSB xid: 1715045 Name (Role): Macintosh HD (No specific role) Capacity Consumed: 45950013440 B Capacity Reserved: None Capacity Quota: None Case Sensitive: No Encrypted: Yes Formatted by: hfs_convert (748.67.14)

Created: 2017-06-02 03:25:11.000000000 (EEST) Changed: 2020-01-31 03:35:16.860098308 (EET)

Encryption Info

Password: password Password Hint: KEK (f9e9f823-18b9-471f-9aed-5cb378b66481): F9 91 48 0C 5D 0B CD A0 EC 47 E3 7F 58 A8 77 DA DB FB 2D 81 54 19 23 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Salt: DC E4 0B CD E3 E7 7C 9D 4C 2B B1 D2 AE 8B 0E 22

Iterations: 86291

Wrapped VEK: FB 10 C0 53 56 78 60 03 F8 C9 A7 A3 38 C0 F6 42 D4 EA 80 2E B0 81 6F 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

VEK (AES-XTS-128): 08 2E D5 15 89 75 CF D8 76 47 E4 A0 9B 20 C4 95 C1 D0 68 67 D9 27 F3 03 77 70 1A 17 E7 DB 23 0C

Unmount Logs

Timestamp Log String

[lfcnassif]

is there an issue with the new version of Sleuthkit?

Probably. Could you run above failing command using verbose (-v) output? And could you also try the official sleuthkit-4.11.1 version instead of our fork to be sure the issue is not related to our patches?

I would also kindly ask you to try previous sleuthkit versions (4.10, 4.9 and 4.8) to try to find when the issue was introduced. Maybe official sleuthkit never worked with your image... Official APFS support was added to sleuthkit-4.8. Because it took too long, we integrated BlackBag APFS implementation in our sleuthkit-4.6.5 fork before them, that seems to work with your image. The official sleuthkit APFS implementation changed many things, so maybe it never worked with your image, not sure... Testing with TSK 4.10, 4.9 & 4.8 would give us an answer about this.

[lfcnassif]

Anyway, although caused by a dependency, this is a regression in our project.

[reacan]

I will try to test different versions of TSK starting from 4.8 and I'll report back.

[lfcnassif]

Thank you. Could you also try to process the image with 4.0.6 on Windows?

[reacan]

Sure thing!

[reacan]

4.0.6 on Windows10 was able to successfully decrypt the image, tested by launching from the .exe and from the .jar. So this is an issue with Sleuthkit's Linux version. I will try different TSK versions and post the output, for now I can add the verbose output of 4.6.5-iped-patch04 and 4.11.1-iped patch. I tried both the EWF and RAW versions of the same image and the error message was the same. It says crypto library not loaded. Maybe I'm missing some sort of a dependancy for Sleuthkit?

The Sleuth Kit ver 4.11.1-iped-patch

./fsstat -v -i ewf -o 76806 -B 632365 -b 4096 -f apfs -k password macbook_fv2.E01

tsk_img_open: Type: 64 NumImg: 1 Img1: macbook_fv2.E01 ewf_open: found 1 segment files via libewf_glob ewf_image_read: byte offset: 314597376 len: 65536 ewf_image_read: byte offset: 1083158528 len: 65536 ewf_image_read: byte offset: 1083224064 len: 65536 ewf_image_read: byte offset: 1083289600 len: 65536 ewf_image_read: byte offset: 1083355136 len: 65536 ewf_image_read: byte offset: 1083420672 len: 65536 ewf_image_read: byte offset: 1083486208 len: 65536 ewf_image_read: byte offset: 1083551744 len: 65536 ewf_image_read: byte offset: 1083617280 len: 65536 ewf_image_read: byte offset: 1083682816 len: 65536 ewf_image_read: byte offset: 1083748352 len: 65536 ewf_image_read: byte offset: 1083813888 len: 65536 ewf_image_read: byte offset: 1083879424 len: 65536 ewf_image_read: byte offset: 1083944960 len: 65536 ewf_image_read: byte offset: 1084010496 len: 65536 ewf_image_read: byte offset: 1084076032 len: 65536 ewf_image_read: byte offset: 1084141568 len: 65536 ewf_image_read: byte offset: 1084207104 len: 65536 ewf_image_read: byte offset: 1084272640 len: 65536 ewf_image_read: byte offset: 2904797184 len: 65536 ewf_image_read: byte offset: 2904764416 len: 65536 ewf_image_read: byte offset: 452866048 len: 65536 APFSFileSystem::init_crypto_info: keybag did not decrypt properlyewf_image_read: byte offset: 2907283456 len: 65536 ewf_image_read: byte offset: 2912026624 len: 65536 ewf_image_read: byte offset: 2905223168 len: 65536 APFSFileSystem::init_crypto_info: keybag did not decrypt properlyapfs: crypto library not loaded ewf_image_read: byte offset: 2904453120 len: 65536 ewf_image_read: byte offset: 2906894336 len: 65536 ewf_image_read: byte offset: 2908168192 len: 65536 ewf_image_read: byte offset: 314957824 len: 65536 General file system error (tsk_apfs_open: APFSBtreeNode: invalid object type)

The Sleuth Kit ver 4.6.5-iped-patch04

fsstat -v -i ewf -o 76806 -B 632365 -b 4096 -f apfs -k password macbook_fv2.E01

tsk_img_open: Type: 64 NumImg: 1 Img1: macbook_fv2.E01 ewf_open: found 1 segment files via libewf_glob ewf_image_read: byte offset: 314597376 len: 65536 ewf_image_read: byte offset: 1083158528 len: 65536 ewf_image_read: byte offset: 1083224064 len: 65536 ewf_image_read: byte offset: 1083289600 len: 65536 ewf_image_read: byte offset: 1083355136 len: 65536 ewf_image_read: byte offset: 1083420672 len: 65536 ewf_image_read: byte offset: 1083486208 len: 65536 ewf_image_read: byte offset: 1083551744 len: 65536 ewf_image_read: byte offset: 1083617280 len: 65536 ewf_image_read: byte offset: 1083682816 len: 65536 ewf_image_read: byte offset: 1083748352 len: 65536 ewf_image_read: byte offset: 1083813888 len: 65536 ewf_image_read: byte offset: 1083879424 len: 65536 ewf_image_read: byte offset: 1083944960 len: 65536 ewf_image_read: byte offset: 1084010496 len: 65536 ewf_image_read: byte offset: 1084076032 len: 65536 ewf_image_read: byte offset: 1084141568 len: 65536 ewf_image_read: byte offset: 1084207104 len: 65536 ewf_image_read: byte offset: 1084272640 len: 65536 ewf_image_read: byte offset: 2904797184 len: 65536 ewf_image_read: byte offset: 2904764416 len: 65536 ewf_image_read: byte offset: 452866048 len: 65536 apfs: skipping unsupported KEK type: ec1c2ad9-b618-4ed6-bd8d-50f361c27507 apfs: skipping unsupported KEK type: 64c0c6eb-0000-11aa-aa11-00306543ecac ewf_image_read: byte offset: 2907283456 len: 65536 ewf_image_read: byte offset: 2912026624 len: 65536 ewf_image_read: byte offset: 2905223168 len: 65536 apfs: skipping unsupported KEK type: ec1c2ad9-b618-4ed6-bd8d-50f361c27507 apfs: skipping unsupported KEK type: 64c0c6eb-0000-11aa-aa11-00306543ecac ewf_image_read: byte offset: 2904453120 len: 65536 ewf_image_read: byte offset: 2906894336 len: 65536 ewf_image_read: byte offset: 2908168192 len: 65536 ewf_image_read: byte offset: 314957824 len: 65536 apfs: skipping unsupported KEK type: ec1c2ad9-b618-4ed6-bd8d-50f361c27507 apfs: skipping unsupported KEK type: 64c0c6eb-0000-11aa-aa11-00306543ecac apfs: skipping unsupported KEK type: ec1c2ad9-b618-4ed6-bd8d-50f361c27507 apfs: skipping unsupported KEK type: 64c0c6eb-0000-11aa-aa11-00306543ecac

FILE SYSTEM INFORMATION File System Type: APFS Volume UUID 89e4887f-4cec-3387-9eba-a10a550e5428 APSB Block Number: 632365 APSB oid: 1027 APSB xid: 1715045 Name (Role): Macintosh HD (No specific role) Capacity Consumed: 45950013440 B Capacity Reserved: None Capacity Quota: None Case Sensitive: No Encrypted: Yes Formatted by: hfs_convert (748.67.14)

[lfcnassif]

Thank you for the tests.

APFSFileSystem::init_crypto_info: keybag did not decrypt properlyapfs: crypto library not loaded

Have you installed openssl (libssl-dev)?

Edit: maybe in TSK building output messages there is some useful info about this.

[reacan]

Have you installed openssl (libssl-dev)?

apt policy libssl-dev libssl-dev: Installed: 1.1.1n-0+deb11u1 Candidate: 1.1.1n-0+deb11u3

I'll test different versions of TSK and that will give a better idea where the problem is at

[lfcnassif]

Thanks. Could you post all output messages printed while building TSK?

PS: We are on a holiday, after I return on Wednesday, I'll try to process an APFS image on Linux.

[reacan]

Happy holiday! I suppose it is hard to stay away from work when you are developing state of the art digital forensics software :P

I tested TSK 4.11.1 Windows and Linux versions and the result was the same, they failed to open the image, output also was the same. For the Linux version I used a clean VM. On that Linux VM I also installed TSK 4.11.1-iped_patch and the result was the same. Most likely this is an issue with the Sleuthkit or Sleuthkit not liking that particular image. I have attached logs from configure, make and make install:

https://pastebin.com/wDKs4Ydg https://pastebin.com/V44VhsqU https://pastebin.com/CAWY4E5T

I also tested the Windows versions of TSK 4.8, 4.9, 4.10 and 4.11.0, none of them were able to open that particular image. I was surprised that IPED 4.0.6 running on Windows was able to decrypt it though.

[lfcnassif]

Thanks for the logs and for all tests. I searched for "ssl" but couldn't find any occurrence. I think the issue could be related to a linking problem to openssl or maybe some #ifdef missing in TSK code or something similar.

I was surprised that IPED 4.0.6 running on Windows was able to decrypt it though.

Sorry, I forgot to say one feature of our TSK fork is that it supports decrypting APFS volumes with non empty passwords. Official TSK just supports the empty string password.

[lfcnassif]

Hi @reacan, @arisjr is kindly investigating this. He proposed a fix here: https://github.com/sepinf-inc/sleuthkit/pull/1

Could you test if it fixes the issue with your image?

[reacan]

Hello! I can confirm that @arisjr proposed solution works with my image. Thank you! Also I noticed that when launching processing, the "-p" argument has to be called last. At first I had it in between "-d" and "-o" and it did not decrypt the partition.

[lfcnassif]

Thank you for testing! The feature was disabled intentionally by TSK because they weren't able to make automatic tests to work properly, but the feature works, I think that was a very conservative decision... I will take a look at the -p position issue.

[lfcnassif]

Also I noticed that when launching processing, the "-p" argument has to be called last. At first I had it in between "-d" and "-o" and it did not decrypt the partition.

Just tested, worked for me on both positions. One detail, not sure if it was your case, if you pass multiple evidences (multiple -d), you have to put the -p password after the APFS image and before the other image, the -o position shouldn't have effect on this.

So, as the fix for the original issue reported was merged in our TSK fork, I'm closing this. Thanks @reacan for reporting and thanks @arisjr for the fix.