Primary GPT is missing, and FileVault volume too

Question

There was an iMac with a single HDD with full-disk FileVault encryption enabled. Some "sysadmin" with a questionable proficiency tried to access data without neither a FileVault password, nor a required knowledge and rendered the disk invalid.

From scarce and sporadic explanations he gave, it may be assumed he messed the disk structure with some HEX editor, however it is known that use of such tools will mess CRC32 checksum, what even Wikipedia clearly states. Supposedly that is what is happened.

So what we got now is a disk without any partitions at all:

imac:/ a$ sudo gpt -r show /dev/disk1
       start        size  index  contents
           0  1953525135
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header

So only what is left are secondary GPT table and header.

gdisk clearly states that primary GPT is corrupted and offers to restore it from a backup, but the restored partition structure looks odd:

imac:/ a$ sudo gdisk /dev/disk1
GPT fdisk (gdisk) version 1.0.1

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

Your answer: 1

Command (? for help): p
Disk /dev/disk1: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D5FB3C42-0E3D-4DC5-B4A9-7C97E8704CF5
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 1953262957 sectors (931.4 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34          262177   128.0 MiB   0C01  Microsoft reserved ... 

Command (? for help):

And here is fdisk output:

imac:/ a$ fdisk /dev/disk1
Disk: /dev/disk1        geometry: 121601/255/63 [1953525168 sectors]
Signature: 0x2A74
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: ED  813 202  27 -  321 220  54 [ 783900958 - 3581756343] <Unknown ID>
 2: 7C  724 235  26 -  550 178  18 [1238663544 - 3274878647] <Unknown ID>
 3: F6  189 250  53 -  993 151  48 [2185613635 -  893877749] <Unknown ID>
 4: 2E  201 236  53 -  683  56  37 [  23839636 - 1903113077] <Unknown ID>

Quick search by testdisk revealed two primary partitions, the first is of type MS Data, previously also detected by gdisk, but seems like it is the second, which may be of interest, since it is of a type Mac HFS and its size of roughly 650 MB indicates it is missing Recovery HD. So now I need to find boundaries of the main FileVault-protected data partition:

  Partition Start   End Size in sectors 
P MS Data   1699755823  1702272435  2516613 [ M-:?->M-'` P^C ]
P Mac HFS   1952255592  1953525127  1269536 

testdisk's Deeper Search, unfortunately haven't found any big partitions:

The question is it is even possible to restore partitions structure from the secondary GPT table/header? I assume that if these are present, there may be some use of them. And what else I can try to retrieve the location of the main data partition?

Answer 1

Well, the direct answer to my own original question from the title is pretty straightforward and it is actually answered in the question body: yes it's possible to restore drive partitions from secondary GPT table/header data, it is done with gdisk which automatically suggests to perform the restoration procedure once it is started, but in my case the restored volume structure was garbage.

I am also able to answer my next question regarding the location of the main data partition. Yes, its location can be calculated after learning the way OS X creates volumes during its installation. So the lost volume can be reinstated, assuming it was created with default settings (default OS X installation, no extra data partitions). And that's how I did it.

Just to learn a pattern OS X prepares the boot disk, I installed Yosemite (thankfully El Capitan hadn't change anything with this) to some spare 320 GB drive. With this information on hand, I managed to reinstate FileVault partition on the disk in question with these simple commands:

sudo gpt destroy /dev/disk2
sudo gpt create -f /dev/disk2
sudo gpt add -b 409640 -i 2 -s 1951845952 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk2

The first command destroyed my faulty useless GPT. The second created a new one. The third marked a volume. Not created it anew, but merely marked that there is a volume of a given type spanning exactly these sectors. One sector is 512 bytes in this case, by the way.

How I knew 409640 -beginning and 1951845952 -size? Well, sector 409640 is a standard beginning of the data partition 2 which spans after EFI partition, which OS X always creates in the beginning of the disk, so it's a safe bet. EFI always ends on 409640 sector. And 1,951,845,952 sectors size is just my total disk size in sectors (1,953,525,168) minus Recovery HD size (1,269,536) minus 40 sectors threshold in the end of the disk minus 409,640 sectors before this second data partition. Result is exactly 1,951,845,952. Divisible by 8 which means I'm right.

The mysterious 53746F72-6167-11AA-AA11-00306543ECAC is, well, a GPT partition type GUID, which marks this volume as a FileVault partition. Not the regular HFS+. I marked this volume with an -index of 2, thus it is second, but I think this parameter isn't crucial, since I'm not restoring other two partitions (EFI and Recovery HD). Honestly, during my investigation I've tried to restore Recovery HD, just to check it is there, and it was there, mountable, safe and sound. This time I ignored it, because neither EFI, nor Recovery HD doesn't have any use to me, I don't plan to boot from this drive, I just want to salvage some data.

Immediately after the reinstating of my FileVault volume's boundaries, I've got a FileVault password request, which I happily provided. It means the boundaries I calculated are correct. To prove it, I even tried different boundaries and in this case there was no any password requests.

However, after FileVault volume has been successfully unlocked, I've got a famous

message box, which means, that even if I have my FileVault partition back, that's not automatically means it is intact. It's unlockable, but somehow broken.

Thus now I'm going to find out if I have a chance to repair this FileVault volume or salvage the data. Follow up question is here.