Disque externe illisible

[Thoms1231]

D’accord, oui je comprends : nous aurons certes donné les consignes à la MBR d’amorcer sur le bloc 256 mais nous n’aurons pas pour autant recréé ce bloc de tête.

S’il est possible que nous l’ayons supprimé via les précédentes manipulations, en créant une table GPT notamment, est-possible de recréer ce « header » en position 256 ?

Je peux sinon continuer mes recherches en utilisant la commande que tu m’as donnée hier.

 

[Membre supprimé 1060554]

Un descripteur de partition déclare qu'une partition commence logiquement au bloc n°256 (par exemple). Si par ailleurs un système de fichiers se trouve toujours inscrit sur les blocs du disque > avec pour super-bloc (bloc où se trouve inscrit son header ou initialisateur) le bloc n°256 => il s'ensuit une coïncidence : bloc de tête de la partition logique = super-bloc du système de fichiers. Quand cette coïncidence à lieu > le kernel (moteur du Système démarré) > en lisant le descripteur de partition => découvre que le bloc de tête = un super-bloc de système de fichiers. Cela lui permet d'activer le système de fichiers => et de monter le volume formé (défini) par ce système de fichiers.

En recréant une GPT (même vide de partition principale) => il y a eu définition d'une partition EFI par un descripteur automatiquement créé dans cette table + formatage de la partition par un système de fichiers FAT-32 formateur d'un volume EFI. Le bloc de tête de la partition EFI est toujours le n°40 (en computation de blocs de 512 octets) ou le n°6 (en computation de blocs de 4096 octets). L'extension de la partition EFI est de 409600 blocs (de 512 octets = 209,7 Mo) ou de 76800 blocs (de 4096 octets = 314,6 Mo). Mais le système de fichiers FAT-32 inscrit sur les blocs de tête à partir du super-bloc n°40 (512 octets) ou 6 (4096 octets) => ne doit occuper qu'une suite continue limitée de blocs. Je ne sais pas si cette occupation de blocs par le FAT-32 aurait pu venir effacer le super-bloc n°2028 (computation de 512 octets) = n°256 (computation de 4096 octets).

 

[Thoms1231]

Ok, d'accord, ta logique est claire et je comprends.

En reprenant ta commande et en l'appliquant avec skip=10000, puis en effectuant CTRL + F "NTFS" je ne trouve aucun résultat.

Par contre, à partir d'environ 1/8e de l'affichage, j'ai la même ligne pour chaque octet et cela jusqu'à 10000 :

0031c000  19 72 32 b6 ee d8 7e cc  dc 7e cc 62 8d 6b be c3  |.r2...~..~.b.k..|

Et comme je te le montrais dans mon avant-dernier post, j'ai juste avant ces lignes identiques une autre ligne qui mentionne "EFI" :

0031bc00  45 46 49 20 20 20 20 20  20 20 20 28 00 00 00 00  |EFI        (....|
0031bc10  00 00 00 00 00 00 28 82  02 41 00 00 00 00 00 00  |......(..A......|

Voilà, tout cela est peut-être inutile mais si ça peut aider je préfère en parler.

 

[Membre supprimé 1060554]

Tu peux utiliser une commande telle que :

sudo dd if=/dev/disk2 bs=4096 skip=1 count=100000 of=~/Desktop/fichier.bin

• où tu remarques que : bs (blocksize : taille du bloc) = 4096 > skip (échappement de blocs à partir du n°0 compris) = 1 > count (nombre de blocs à cloner par dd) = 100000 > et au lieu de re-diriger la sortie du clonage sur un affichage à l'écran du terminal par hexdump => tu as une sortie classique de dd (indiquée par of=....) créant un fichier : fichier.bin sur ton Bureau de session.

Cela fait tu vas à cette page : ☞Hex Fiend☜ et tu télécharges l'éditeur d'hex code : Hex Fiend. Tu peux le déplacer dans les Applications.

- en le lançant (interface en Anglais) > tu peux ouvrir le fichier : fichier.bin du Bureau par ⌘N et navigation au fichier. Puis en faisant ⌘F tu lances sa commande Find (trouver) > tu choisis Text comme mode de sélection > tu saisis :​

.R.NTFS

• dans le champ de sélection et tu presses la touche "Entrée" pour voir si une écriture correspondante est trouvée dans les 100 000 blocs.

 

[Thoms1231]

Ok très bien, je vais appliquer cela. Merci !

Juste, quelle est l'intérêt d'effectuer le ⌘F dans Hex Fiend plutôt que dans le Terminal ?

 

[Membre supprimé 1060554]

Hex Fiend travaille ici à partir d'un fichier. Qui pourrait inclure des millions de blocs si tu voulais (tu fais varier la valeur de count=...). Ça me paraît plus confortable qu'avec une sortie dans le terminal.

 

[Thoms1231]

Ok, très bien. Je te tiens au courant quand j'aurais effectué la manip.

Encore une fois merci pour ton aide !

 

[Thoms1231]

Bonjour @macomaniac

Pas de résultats en appliquant ta commande et en recherchant via Hex Fiend ".R.NTFS" dans le fichier .bin.

Par contre, j'ai effectué cette même manip avec le nouveau disque dur, voici ce que j'obtiens à 1044480 octets soit le bloc 256 si on ne compte qu'à partir du bloc 2 et avec 4096 octets par bloc.

ÎRêNTFS    ¯?ˇ

Sur mon ancien disque, les écritures ne commencent qu'à partir de l'octet 3260416 (bloc 797). Je pense qu'on peut en conclure que le bloc de tête a été effacé par nos précédentes manipulations.

Je suis peut-être naïf, mais ne peut-on pas essayer de copier-coller du nouveau disque vers l'ancien tout le contenu des blocs jusqu'au numéro 256 ?
Cela intégrerait la table MBR, le bloc de tête NTFS et permettrait de créer un volume avec mes données encore présentes sur le disque.

 

[Membre supprimé 1060554]

Oui : je pense que le système de fichiers NTFS a été effacé de ton ancien disque.

- le problème en ce qui concerne cloner les blocs 0 => 256 du nouveau sur l'ancien => c'est qu'il faudrait que les blocs suivants le n° 256 sur l'ancien contiennent bien la suite des écritures du système de fichiers NTFS. Dont les composants gérant les fichiers écrits sur les blocs (catalogue). Mais est-ce que les blocs 257 et suivants ne sont pas vides d'écriture aussi sur ton ancien disque ?​

Tu veux passer la commande :

sudo dd if=/dev/disk2 bs=4096 skip=256 count=20 | hexdump -Cv

• qui affiche les 20 blocs à partir du n°256 inclus dans hexdump (fenêtre du terminal)

=> est-ce que les blocs ne sont pas vides ?

 

[Thoms1231]

Je vais passer ta commande et te donner le retour mais, d’après l’expérience du précédent post, les écritures sur mon ancien disque ne commencent qu’au bloc 797.

Je n’avais pas connaissance de ce catalogue et je pensais que toutes les infos du volume résidaient dans le super-bloc... dommage.

 

[Membre supprimé 1060554]

Le super-bloc est le bloc d'intialisation du système de fichier. Mais le système de fichiers occupe encore une série d'autre blocs sur lesquels il y a ses composants opératoires.

 

[Thoms1231]

Ok, nous sommes donc dans une impasse...

J'ai entendu parler des "backup boot sectors" situés en milieu ou fin de partitions NTFS. Mais, par définition, ils ne contiennent qu'une copie des informations du super-bloc ? Pas de copie des composants opératoires dont tu parles ?

En mode avancé, et à 27% du processus Testdisk me trouve des partitions, mais les tailles sont invraisemblables. Sauf une qui ne dépasse que légèrement la capacité du disque.

Je suis à cours d'idées ... Ça me paraît fou que les données soient sur le disque, intactes, sans pouvoir les lire.

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <[email protected]>
https://www.cgsecurity.org

Disk /dev/disk2 - 3000 GB / 2794 GiB - 732558336 sectors

The harddisk (3000 GB / 2794 GiB) seems too small! (< 32 TB / 29 TiB)
Check the harddisk size: HD jumper settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
   HPFS - NTFS           3100227412 5152499006 2052271594
   HPFS - NTFS           3100228451 5152500045 2052271594
   FAT16 <32M            3103259919 4661595627 1558335709
   FAT16 LBA             3126149827 6731700259 3605550433
>  HPFS - NTFS           3145422403 3897758403  752336001
   FAT12                 3148711906 5899150319 2750438413
   FAT32 LBA             3160597093 4505254661 1344657568
   FAT32                 3188365927 3455935352  267569426
   HPFS - NTFS           3207990494 6969273805 3761283312
   FAT32 LBA             3222567623 4442569696 1220002074

[ Continue ]
3081 GB / 2869 GiB

 

[Membre supprimé 1060554]

Essaie un logiciel de récupération de données.

 

[Thoms1231]

Tu en aurais quelques uns à me recommander ?
J'ai téléchargé Photorec de Christophe Grenier et Remo Recover.

Si dans ton avant-dernier message c'était de MFT dont tu voulais parler, alors j'ai lu qu'il y avait quelque part sur la partition un MFT mirror permettant de réparer un MFT corrompu.

J'imagine que recréer une table MBR, cloner un bloc de tête en position 256, et restaurer un MFT ça fait trop de variables et qu'à ce point il ne faut plus espérer recréer ce volume ?

 

[Membre supprimé 1060554]

Dès qu'il s'agit d'un système de fichiers NTFS > son super-bloc = le MFT (Master_File_Table). C'est-à-dire que le 1er bloc d'inscriptions du NTFS porte le catalogueur des fichiers du volume de la partition. Donc on pourrait envisager de cloner sur le bloc vide n°256 (computation 4096 octets) un bloc de sauvegarde du MFT. Mais où est-il ce bloc de sauvegarde en ce qui concerne ton ancien disque ? - et comment concevoir que ce bloc unique suffirait à reformer un volume sans les autres composants du NTFS ?

- tu peux essayer la démo de Data Rescue pour voir si des fichiers sont vus comme récupérables.​

 

[Thoms1231]

Oui en effet, trop de suppositions. Et nous en avons déjà beaucoup fait, en vain, et malheureusement à cause du boîtier de remplacement qui a faussé la taille des secteurs.

Merci vraiment pour ton aide et le temps passé.

Je teste Data Rescue et je te tiens au courant !

 

[Membre supprimé 1060554]

Comme disait Hegel : "La chouette de Minerve prend son envol le soir". Métaphore du constat : c'est toujours après qu'on sait ce qu'on aurait dû faire avant. Effectivement : si on s'était rendu compte que le boîtier défecteux avait fonction d'émulateur de blocs physiques de 4096 octets en blocs logiques de 512 octets & si j'avais eu l'idée d'utiliser le couplage des commandes : dd | hexdump pour explorer les écritures des blocs du disques => alors le résultat aurait pu être différent.

- tu n'auras qu'à dire ce que donne Data Rescue.​

 

[Thoms1231]

L'outil Data Rescue n'a sorti que quelques fichiers et ils sont tous illisibles. Je vais essayer avec d'autres programmes au cas où le résultat soit plus concluant.
Mais, comme tu le disais, il doit manquer tous les fichiers intelligibles du système NTFS.

 

[Membre supprimé 1060554]

Essaie avec la démo de Disk Drill alors.