Switch to full style
Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
Post a reply

APFS Keychain

August 14th, 2018, 5:49

Hello all,

I wondered whether people were getting more experience of APFS, and working with it when there is a failure, or has been altered. In particular, I am uncertain at this stage whether there is a particular LBA location (or range of LBA) for the keychain for encrypted APFS volumes. In this case I am working on a volume which contains the OS after a High Sierra update from HFS+ to APFS.

The case I have relates to a fault where the user was in disk utility and made some type of mistake, he then also ran commands within terminal. He can't recall which. The end result is that from sector 409,640 there are now 200 sectors filled with "00" data, and a GPT reporting a volume at 409,640 called "Customer".

I have been able to locate NXSB 'magic' blocks later in the disk. The first of these was copied and written back to the first 8 sectors at 409,460. It is now possible for OSX / recovery software to recognise the APFS container. It is possible to access the files of the three volumes which are not encrypted (Preboot, Recovery, VM). The encrypted volume "Macintosh HD" is reported as locked within recovery software and within OSX DiskUtil.

Below is a screenshot showing this with R-Studio:

2018-08-14.png


Below is the output from OSX at terminal:

DiskUtil APFS.png
DiskUtil APFS.png (244.96 KiB) Viewed 6214 times


The UUID for the encrypted volume is reported missing from the DiskUtil command line. Attempts to decrypt via the command line fail as a result, even though the passphrase is available.

Within OSX when I attempt to mount the encrypted volume the pop-up box appears asking for the password to be entered. However, it is greyed out and not possible to enter text. The ‘hint’ is also missing. I suspect that the data associated with the keychain is missing/overwritten.

I should also mention that the SSD had been to another data recovery company before getting here. Unfortunately, they are well known in the UK for advertising "No-recovery, no-fee", but then trying to make a large upfront non-refundable fee when the device is received. Consequently, the owner of the disk requested for it to be returned. As a consequence it is not possible to know if any changes have been made to the disk.

Any thoughts?

Best regards,
John

Re: APFS Keychain

August 15th, 2018, 15:29

APFS is not the same as conventional file systems.
In FS like NTFS, FAT or ExtFS you would have a volume that starts on LBA x and goes to LBA y.

In APFS there is a container (the one with NXSB magic) that goes from LBA x to LBA y but there could be several volumes inside the container and they all share this container's space.

So in order to tell what LBA belongs to what Volume you would have to parse all APFS metadata and build a translation table.

Re: APFS Keychain

August 17th, 2018, 3:07

Hello Doomer,

Thank you for your reply.

Yes, APFS is very different to other FS, I am aware that it presents some significant challenges and changes compared with previous FS like NTFS or HFS+. SysDev support (UFS) provided me some useful information about this case when I asked them about their support for APFS in UFS/R-Explorer. There advice proved useful, and this allowed for the results listed above.

With the alterations I made to the disk image, (adding the NXSB magic) to the overwritten sector at 409,640 it has been possible to access three of the volumes in the container. All the files within the Preboot, Recovery and VM are now viewable and OK. So this is positive. The encrypted volume shows with the correct attributes (label, size, etc.) but it is just not possible to unlock the volume. For information the NXSB magic sector I found to copy to sector 409,640 were located just before the start of the 'BootCamp' NTFS partition which exists on the disk.

I wondered from anyone else's experience whether the keychain associated with encryption was likely to located in the first 200 sectors from 409,640. This is where the data on the disk is is filled with "00". Or, whether perhaps as you suggest this keychain data, along with other metadata will be at variable locations in the disk

As a test I took a healthy disk image from a working High Sierra OS, and filled the 192 sectors from 409,648 with “00”. Effectively emulating some of the damage to the customer disk sustained. When remounted, the disk image worked normally and all data could be accessed. It suggest that those sectors are not so important in the test case. Obviously, it is not possible to know what other changes were made to the patient disk.

Best regards,
John

Re: APFS Keychain

August 18th, 2018, 6:07

Hi John
Have you tried recently updated tool: Recovery Explorer Professional (www.sysdevlabs.com), from ufs guys? There is new imporved APFS module in.
Here is changes log:
What's new in version 6.17:

* Update to APFS module:
- Metadata validation;
- Added decryption with FileVault-style keyring;
- Added decryption of APFS volumes, converted from Core Storage FileVault2 (HFS+).
* Support of compressed metadata with Core Storages (FileVault, Fusion Drive, FDE);
* Support of short-form metadata references for Core Storages.

Re: APFS Keychain

August 19th, 2018, 2:22

+1 for Recovery Explorer Pro.

Re: APFS Keychain

August 20th, 2018, 9:52

Yes, I'm using an up to date copy of Recovery Explorer (the 'new' UFS). I got in touch with the SysDev support team of R-Explorer / UFS. They gave some explanation of what is possible, but also some of the limitations in the current version. From SysDev Labs:

"Current version of Recovery Explorer doesn’t scan search encrypted APFS volumes. Reasons for this is requirement for special procedure that pre-scans the storage to find volume ID information and all keychains, then request known passwords to derive all decryption keys and only after this run the scan, trying to decrypt each block with each found key (there is no indication and each single block can be encrypted with different key). We are looking for option to make this “smooth enough” and to develop this procedure soon."


They also provided some useful information about my particular case.

John
Post a reply