Falta GPT principal y también volumen de FileVault

Había un iMac con un solo HDD con cifrado de FileVault de disco completo habilitado. Algunos "administradores de sistemas" con una competencia cuestionable intentaron acceder a los datos sin una contraseña de FileVault, ni un conocimiento requerido, y dejaron el disco inválido.

Por las escasas y esporádicas explicaciones que dio, se puede suponer que desordenó la estructura del disco con algún editor HEX, sin embargo, se sabe que el uso de tales herramientas ensuciará la suma de verificación CRC32, lo que incluso Wikipedia dice claramente . Supuestamente eso es lo que sucedió.

Entonces, lo que tenemos ahora es un disco sin particiones:

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

Entonces, solo lo que queda son la tabla secundaria GPT y el encabezado.

gdisk establece claramente que el GPT primario está dañado y ofrece restaurarlo desde una copia de seguridad, pero la estructura de partición restaurada parece extraña:

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):

Y aquí está la fdisksalida:

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>

La búsqueda rápida por testdiskdos particiones principales reveladas, la primera es de tipo MS Data, previamente detectada también por gdisk, pero parece que es la segunda, lo que puede ser de interés, ya que es de un tipo Mac HFSy su tamaño de aproximadamente 650 MB indica que falta Recuperación HD. Entonces ahora necesito encontrar los límites de la partición de datos protegida por FileVault principal:

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

testdiskBúsqueda más profunda, desafortunadamente no he encontrado ninguna partición grande:

La pregunta es si es posible restaurar la estructura de particiones desde la tabla / encabezado GPT secundario . Supongo que si estos están presentes, puede haber algún uso de ellos. ¿Y qué más puedo tratar de recuperar la ubicación de la partición de datos principal ?

Bueno, la respuesta directa a mi propia pregunta original del título es bastante sencilla y en realidad se responde en el cuerpo de la pregunta: sí, es posible restaurar particiones de disco a partir de datos secundarios de tabla / encabezado GPT , se hace con lo gdiskque automáticamente sugiere realizar el procedimiento de restauración una vez que se inicia, pero en mi caso la estructura del volumen restaurado era basura.

También puedo responder mi próxima pregunta sobre la ubicación de la partición de datos principal. Sí, su ubicación se puede calcular después de conocer la forma en que OS X crea volúmenes durante su instalación . Por lo tanto, el volumen perdido se puede restablecer, suponiendo que se creó con la configuración predeterminada (instalación predeterminada de OS X, sin particiones de datos adicionales). Y así fue como lo hice.

Solo para aprender un patrón OS X prepara el disco de arranque, instalé Yosemite (afortunadamente, El Capitan no había cambiado nada con esto) en una unidad de 320 GB de repuesto. Con esta información a mano, logré restablecer la partición FileVault en el disco en cuestión con estos simples comandos:

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

El primer comando destruyó mi GPT inútil defectuosa. El segundo creó uno nuevo. El tercero marcó un volumen. No se creó de nuevo, sino que simplemente marcó que hay un volumen de un tipo dado que abarca exactamente estos sectores. Un sector es 512 bytes en este caso, por cierto.

¿Cómo supe 409640 -b eginning y 1951845952 -s ize? Bueno, el sector 409640 es un comienzo estándar de la partición de datos 2 que se extiende después de la EFIpartición, que OS X siempre crea al comienzo del disco, por lo que es una apuesta segura. EFISiempre termina en el sector 409640. Y el tamaño de 1,951,845,952 sectores es solo el tamaño total de mi disco en sectores ( 1,953,525,168 ) menos el Recovery HDtamaño ( 1,269,536 ) menos el umbral de 40 sectores al final del disco menos 409,640 sectores antes de esta segunda partición de datos. El resultado es exactamente 1.951.845.952 . Divisible por 8, lo que significa que tengo razón.

El misterioso 53746F72-6167-11AA-AA11-00306543ECAC es, bueno, un GUID de tipo partición GPT , que marca este volumen como una partición FileVault. No es el HFS + normal. Marqué este volumen con un índice -i de 2, por lo tanto, es el segundo, pero creo que este parámetro no es crucial, ya que no estoy restaurando otras dos particiones ( EFIy Recovery HD). Honestamente, durante mi investigación he intentado restaurar Recovery HD, solo para comprobar que está allí, y estaba allí, montable, sano y salvo. Esta vez me ignoró, porque ni EFI, tampoco Recovery HDno tiene ninguna utilidad para mí, no planeo para arrancar desde esta unidad, sólo quiero salvar algunos datos.

Inmediatamente después de restablecer los límites de mi volumen FileVault, recibí una solicitud de contraseña de FileVault, que felizmente proporcioné. Significa que los límites que calculé son correctos. Para probarlo, incluso probé diferentes límites y en este caso no hubo ninguna solicitud de contraseña.

Sin embargo, después de que el volumen FileVault se ha desbloqueado con éxito, tengo un famoso

cuadro de mensaje, lo que significa que incluso si tengo mi partición FileVault de nuevo, eso no significa automáticamente que está intacta. Es desbloqueable, pero de alguna manera está roto.

Por lo tanto, ahora voy a averiguar si tengo la oportunidad de reparar este volumen de FileVault o recuperar los datos. La pregunta de seguimiento está aquí .