All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: APFS Keychain
PostPosted: August 14th, 2018, 5:49 
Offline

Joined: February 18th, 2009, 8:08
Posts: 243
Location: Manchester, UK
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:

Attachment:
2018-08-14.png
2018-08-14.png [ 36.9 KiB | Viewed 1009 times ]


Below is the output from OSX at terminal:

Attachment:
DiskUtil APFS.png
DiskUtil APFS.png [ 244.96 KiB | Viewed 1009 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

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/


Top
 Profile  
 
 Post subject: Re: APFS Keychain
PostPosted: August 15th, 2018, 15:29 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3214
Location: Chicago
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.

_________________
https://www.linkedin.com/in/artemrubtsov/


Top
 Profile  
 
 Post subject: Re: APFS Keychain
PostPosted: August 17th, 2018, 3:07 
Offline

Joined: February 18th, 2009, 8:08
Posts: 243
Location: Manchester, UK
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

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/


Top
 Profile  
 
 Post subject: Re: APFS Keychain
PostPosted: August 18th, 2018, 6:07 
Offline

Joined: March 7th, 2009, 12:43
Posts: 831
Location: Data recovery + remote Raid recovery help
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.

_________________
All kind of RAID recovery remote help
Whatsapp: +971552737521


Top
 Profile  
 
 Post subject: Re: APFS Keychain
PostPosted: August 19th, 2018, 2:22 
Offline
User avatar

Joined: January 28th, 2009, 10:54
Posts: 2770
Location: Greece
+1 for Recovery Explorer Pro.

_________________
Northwind Data Recovery - Greece
WD Trusted Partners
http://www.northwind.gr
SandForce SSD Recovery


Top
 Profile  
 
 Post subject: Re: APFS Keychain
PostPosted: August 20th, 2018, 9:52 
Offline

Joined: February 18th, 2009, 8:08
Posts: 243
Location: Manchester, UK
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:

Quote:
"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

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: Google Adsense [Bot] and 25 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group