10.12 Sierra Disque dur externe crypté reformaté

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
J'ai réussi à récupérer des données sur d'autres disques dur mais les années 2001 à 2006 + 2010 à 2012 (enfants), j'a rien.. Quelle misère. J'avais pourtant recopier ces données partout, j'ai même scanné le disque dur de la freebox en vain...
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
88 074
26 953
Forêt de Fontainebleau
Quand je vois ce pied de disque valide -->
Bloc de code:
   218562968  1640203880      3  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  1858766848      262144      4  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1859028992  2047737992      5  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  3906766984      262144      6  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  3907029128           7      
  3907029135          32         Sec GPT table
  3907029167           1         Sec GPT header

  • où l'on note 2 paires de partitions : CoreStorage chiffré (3 & 5) et booter (4 & 6) qui s'alignent sans aucun bloc de séparation > la fin de la dernière partition booter à 7 blocs libres du 1er bloc de la sauvegarde de la GPT (Secondary GPT table)
  • et quand je contemple ce pied de disque recréé de ton DDE amoché -->
Bloc de code:
   2725767480  1181640636      4  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  3907408116      262144      5  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  3907670260  1952600720      6  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  5860270980      262144      7  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  5860533124           7      
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header

  • je note une congruence formelle du dispositif sur ce dernier disque : 2 paires de partitions CoreStorage chiffré (4 & 6) et booter (5 & 7) qui s'alignent sans aucun bloc de séparation > la fin de la dernière partition booter à 7 blocs libres du 1er bloc de la sauvegarde de la GPT (Secondary GPT table)

J'en conclus que la recréation des partitions sur le disque amoché est "canonique" au bloc près.

----------
 
Dernière édition:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
88 074
26 953
Forêt de Fontainebleau
Pourquoi alors les partitions 5 > 6 > 7 (booter > CoreStorage > booter) ne permettent-elles pas le remontage de volumes sur le disque amoché ? --> manifestement > parce que le bloc 0 (1er bloc) de ces partitions --> ne récupère pas le super-bloc de systèmes de fichiers toujours inscrits sur les blocs (jhfs+ > CoreStorage > jhfs+). Or > si les emplacements des partitions sont "canoniques" (formellement parlant) --> leur bloc 0 devrait à toute force avoir récupéré le super-bloc des systèmes de fichiers inscrits et permis le remontage des volumes.

Pourquoi donc n'est-ce pas le cas ? - je conjecture que le logiciel Linux n'a pas commencé sa tâche de "zéroïsation" par le 1er bloc absolu du disque > mais par les blocs 0 d'une série de partitions adressées simultanément. Il a donc eu le temps d'effacer le super-bloc de la partition EFI1 > une partie du système de fichiers de la partition CoreStorage2 > rien du booter3 > rien de la partition CoreStorage4 > le super-bloc du booter5 > le super-bloc de la CoreStorage6 > le super-bloc du booter7.

- c'est la seule conjecture qui me paraisse rendre raison de partitions "canoniques" par leurs emplacements > mais vides de systèmes de fichiers

=> j'en conclus (en ce qui me concerne) --> qu'il n'y a plus rien à faire. Sans systèmes de fichiers valides dans le conteneur des partitions --> aucun remontage de volumes n'est envisageable. En ce qui concerne la partition CoreStorage 6 de pied de disque --> ses blocs sont chiffrés par FileVault. En l'absence du mécanisme logique de déchiffrement et remontage d'un volume lisible > aucun logiciel de récupération de données ne peut lire les blocs chiffrés.
 
Dernière édition:
  • J’aime
Réactions: Mc kintosh

SyMich

Membre actif
13 Février 2018
278
49
55
Les meilleurs chirurgiens perdent parfois leur patient.
Je suis impressionnée par la rigueur de l'analyse qui a été faite et des tentatives de résurrection de ce disque dur ayant tout de même permis de récupérer l'une des partitions.
Vraiment du beau travail Monsieur Mac'o'Maniac!
 
  • J’aime
Réactions: litobar71

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
Ok. C'est décevant mais je ne peux m'en prendre qu'à moi même. J'ai joué avec le feu en reformatant sous linux sans connaître.

Je te remercie déjà immensément de m'avoir aidé à récupéré la partition du boulot.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
88 074
26 953
Forêt de Fontainebleau
Le problème est que les écritures primaires sur les blocs sont toutes chiffrées en ce qui concernent l'emplacement des partitions CoreStorage -->

  • le dispositif du CoreStorage est le suivant : une partition primaire du disque est assimilée à un magasin de stockage physique Physical Volume. À partir de ce Physical Volume > s'effectue la virtualisation d'un espace-disque secondaire appelé Logical Volume. Sur l'espace-disque du Logical Volume le système de fichiers jhfs+ monte le volume terminal.
  • donc le volume terminal monté > exploite uniquement l'espace-disque virtualisé du Logical Volume. À présent > le Physical Volume & le Logical Volume sont comme 2 espaces-disques miroirs l'un de l'autre, le primaire & le secondaire > unis par une transaction : un processus de traduction continue des blocs chiffrés du Physical Volume en blocs virtuels déchiffrés du Logical Volume et vice-versa. Un algorithme assure ces conversions d'écritures.
  • sur la partition CoreStorage du haut de ton DDE --> il ne reste que le Physical Volume primaire. Constitué de blocs chiffrés. Le mécanisme logiciel de virtualisation du Logical Volume > et de conversion de l'espace primaire chiffré du Physical Volume en espace virtuel déchiffré du Logical Volume => a été détruit. Conséquence : impossible d'interpréter les écritures chiffrées primaires en écritures déchiffrées formant des fichiers lisibles.
  • sur la partition CoreStorage du bas du DDE --> il ne reste plus rien des structures CoreStorage. Ce qui revient à dire : il reste uniquement l'espace de blocs primaires portant les écritures chiffrées. Aucune mécanisme logiciel de transposition dans un espace-disque déchiffré n'existe plus.

Dans ce conditions --> aucun logiciel de récupération de données ne peut récupérer de fichiers lisibles. Car ils n'ont affaire qu'à des blocs chiffrés. Si le chiffrement d'une partition était aussi facile à surmonter qu'il suffise de lancer un logiciel de récupération pour scanner les blocs primaires de la partition et lire les fichiers --> FileVault ne sécuriserait rien du tout en terme de données. Mais tel n'est pas le cas : le chiffrement FileVault ne peut pas être surmonté.
 

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
Bon a toujours la famille. Il faudra faire le tour de chacun pour récupérer ce qu'on peut de ces deux années là. Pour le reste on avait eu l'intelligence d'imprimer lors de promos un grand nombre de photos numériques...

Mais c'est une leçon que je ne suis pas près d'oublier.

Ma question est évidente : comment as tu appris une telle expertise ? Quel est on métier si c'est pas indiscret ?
 

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
Je suis stupéfait, je m'attendais à un administrateur réseau ou système.
Tu as raté ta vocation alors.... A ce niveau là tu as intérêt de te rapprocher de réparateur informatiques pour la récupération des disques durs... tu va avoir du travail sans problème !!!
 

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
Sur le scan DiskDrill de la partition de 1To je récupère des fichiers plist.

voilà le contenu, ça n'avance en rien ?

Bloc de code:
<plist version="1.0">
<dict>
    <key>Annotations</key>
    <dict>
        <key>Creation_Predicates</key>
        <dict>
            <key>false</key>
            <integer>0</integer>
            <key>fstype.hfs</key>
            <integer>1</integer>
            <key>interconnect.usb</key>
            <integer>1</integer>
            <key>is.alreadyindexed</key>
            <integer>0</integer>
            <key>is.automount</key>
            <integer>0</integer>
            <key>is.backupstore</key>
            <integer>0</integer>
            <key>is.backupvolume</key>
            <integer>0</integer>
            <key>is.bootablevolume</key>
            <integer>0</integer>
            <key>is.cameramedia</key>
            <integer>0</integer>
            <key>is.diskimage</key>
            <integer>0</integer>
            <key>is.dontbrowse</key>
            <integer>0</integer>
            <key>is.ejectable</key>
            <integer>0</integer>
            <key>is.external</key>
            <integer>1</integer>
            <key>is.externalvolumes.defaultoff</key>
            <integer>0</integer>
            <key>is.externalvolumes.ignore</key>
            <integer>0</integer>
            <key>is.filevault</key>
            <integer>0</integer>
            <key>is.forcedefaultindex</key>
            <integer>0</integer>
            <key>is.forcefsonly</key>
            <integer>0</integer>
            <key>is.home</key>
            <integer>0</integer>
            <key>is.internal</key>
            <integer>0</integer>
            <key>is.ipod</key>
            <integer>0</integer>
            <key>is.local</key>
            <integer>1</integer>
            <key>is.lowdiskspace</key>
            <integer>0</integer>
            <key>is.mobilebackups</key>
            <integer>0</integer>
            <key>is.network</key>
            <integer>0</integer>
            <key>is.quarantined</key>
            <integer>0</integer>
            <key>is.readonly</key>
            <integer>0</integer>
            <key>is.removable</key>
            <integer>0</integer>
            <key>is.rootfs</key>
            <integer>0</integer>
            <key>is.safeboot</key>
            <integer>0</integer>
            <key>is.syntheticmount</key>
            <integer>0</integer>
            <key>is.tinyvolume</key>
            <integer>0</integer>
            <key>is.windowsbootablevolume</key>
            <integer>0</integer>
            <key>is.xsan</key>
            <integer>0</integer>
            <key>policy.location.volume</key>
            <integer>1</integer>
            <key>self.appleinternal</key>
            <integer>0</integer>
            <key>self.server</key>
            <integer>0</integer>
            <key>status.neverindex</key>
            <integer>0</integer>
            <key>supports.catsearch</key>
            <integer>1</integer>
            <key>supports.fileids</key>
            <integer>1</integer>
            <key>supports.volfs</key>
            <integer>1</integer>
            <key>true</key>
            <integer>1</integer>
            <key>uuid.fe18b837-7e1d-36a2-b16e-f7dd49cebdba</key>
            <integer>1</integer>
        </dict>
 

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
Bloc de code:
        </dict>
        <key>DebugKey1</key>
        <string>2018-09-26 20:26:27 +0000 3</string>
        <key>DefaultStore_EffectiveSearch</key>
        <integer>3</integer>
        <key>DefaultStore_RequestedSearch</key>
        <integer>3</integer>
    </dict>
    <key>ConfigurationCreationDate</key>
    <date>2018-09-26T20:26:27Z</date>
    <key>ConfigurationCreationVersion</key>
    <string>Version 10.12.6 (Build 16G1408)</string>
    <key>ConfigurationModificationDate</key>
    <date>2018-09-26T20:26:27Z</date>
    <key>ConfigurationModificationVersion</key>
    <string>Version 10.12.6 (Build 16G1408)</string>
    <key>ConfigurationVolumeUUID</key>
    <string>FE18B837-7E1D-36A2-B16E-F7DD49CEBDBA</string>
    <key>ConfigurationWriteback</key>
    <false/>
    <key>Exclusions</key>
    <array/>
    <key>Options</key>
    <dict>
        <key>ConfigurationType</key>
        <string>Default</string>
    </dict>
    <key>Stores</key>
    <dict>
        <key>D0AB9E0C-6029-4DFF-B185-DF5D632380D9</key>
        <dict>
            <key>CreationDate</key>
            <date>2018-09-26T20:26:27Z</date>
            <key>CreationVersion</key>
            <string>Version 10.12.6 (Build 16G1408)</string>
            <key>IndexVersion</key>
            <integer>95</integer>
            <key>PartialPath</key>
            <string>/</string>
            <key>PolicyDate</key>
            <date>2018-09-26T20:26:27Z</date>
            <key>PolicyLevel</key>
            <string>kMDConfigSearchLevelReadWrite</string>
            <key>PolicyProcess</key>
            <string>STORE_ADD</string>
            <key>PolicyVersion</key>
            <string>Version 10.12.6 (Build 16G1408)</string>
        </dict>
    </dict>
</dict>
</plist>
 

Mc kintosh

Membre actif
14 Octobre 2017
152
14
45
Ce qui est étonnant c'est que j'ai précisément 3 fichier plists qui semble correspondre aux 3 partitions du disque dur, ça c'est le troisième fichier

Je fais une pause pour la soirée.