Support fat32 pour récupérer le MBR d'une clé USB avec la commande dd

Support Debian
#1

Bonjour,

J’ai une clé USB de 32 Go avec un MBR FAT32 altéré. Windows indique une partition RAW inutilisable. J’ai trouvé de nombreuses méthodes différentes sur internet, mais aucune ne fonctionne. Il y a bien des applications Windows soit disant gratuites pour récupérer les fichiers, mais aux finales elles sont payants … et de plus elles ne procèdent en général pas par correction du MBR mais par récupération des fichiers un par un, ce qui pose d’autres problèmes car des fichiers effacés depuis plusieurs années sont aussi récupérés …

J’ai fini par trouver un mini how-to intéressant faisant appel à deux solutions depuis linux : avec la commande dd et avec la commande install-mbr.

J’applique donc la commande suivante, ma clé USB à corriger est en /dev/sdd. Je comprends que le fichier mbr.bin serait un MBR FAT32, mais les commandes suivantes semblent indiquer que ce ne serait pas vraiment le cas … :
#dd if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdd
0+1 enregistrements lus
0+1 enregistrements écrits
440 bytes copied, 0,0309298 s, 14,2 kB/s

j’obtiens bien un MBR dos comme semble l’indiquer la commande fdisk ci-dessous :
#fdisk -l
Disque /dev/sdd : 28,7 GiB, 30828134400 octets, 60211200 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x0c5bc8b6

Mais si j’essaie de monter la clé, il y un message d’erreur :
mount /dev/sdd /media
mount: mauvais type de système de fichiers, option erronée, superbloc erroné
sur /dev/sdd, page de code ou programme auxiliaire manquant, ou autre erreur

    Dans certains cas des renseignements utiles sont dans le journal
    système — essayez « dmesg | tail » ou quelque chose du genre.

#dmesg | tail
[ 2934.237027] scsi host4: usb-storage 5-6:1.0
[ 2935.266118] scsi 4:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 4
[ 2935.266727] sd 4:0:0:0: Attached scsi generic sg4 type 0
[ 2935.268570] sd 4:0:0:0: [sdd] 60211200 512-byte logical blocks: (30.8 GB/28.7 GiB)
[ 2935.269704] sd 4:0:0:0: [sdd] Write Protect is off
[ 2935.269709] sd 4:0:0:0: [sdd] Mode Sense: 23 00 00 00
[ 2935.270829] sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
[ 2935.281382] sdd:
[ 2935.285232] sd 4:0:0:0: [sdd] Attached SCSI removable disk
[ 4101.704777] sdd:

Si je copie le PBR dans un fichier et que j’utilise la commande file pour lire le MBR j’obtiens une information qui laisse voir un MBR dos et non FAT32. De plus je n’ai aucune information sur le nombre de secteurs :
# dd if=/dev/sdd bs=512 count=1 of=mbr_usb.txt
1+0 enregistrements lus
1+0 enregistrements écrits
512 bytes copied, 0,157185 s, 3,3 kB/s
# file mbr_usb.txt
./mbr_usb.txt: DOS/MBR boot sector

J’ai également essayé avec ddrescue. J’ai réussi à recopier l’ensemble de la partition de ma clé dans une nouvelle prévue spécialement à cet effet sur mon disque dur externe. Mais cette nouvelle partition ne semble pas d’avantage accessible. La commande file me donne exactement le même résultat.

Je comprends que le MBR du fichier mbr.bin utilisé avec la commande dd ne serait pas vraiment celui attendu en FAT32… Est-ce aussi peut être un problème de dimensionnement des cylindres et autres paramètres spécifiques aux partitions ?

Pour informaiton dump du MBR de ma clé USB à corriger :
gelinp@gelinux:~$ sudo dd if=/dev/sdd bs=512 count=1 | hexdump -C
00000000 33 c0 fa 8e d8 8e d0 bc 00 7c 89 e6 06 57 8e c0 |3…|…W…|
00000010 fb fc bf 00 06 b9 00 01 f3 a5 ea 1f 06 00 00 52 |…R|
00000020 52 b4 41 bb aa 55 31 c9 30 f6 f9 cd 13 72 13 81 |R.A…U1.0…r…|
00000030 fb 55 aa 75 0d d1 e9 73 09 66 c7 06 8d 06 b4 42 |.U.u…s.f…B|
00000040 eb 15 5a b4 08 cd 13 83 e1 3f 51 0f b6 c6 40 f7 |…Z…?Q…@.|
00000050 e1 52 50 66 31 c0 66 99 e8 66 00 e8 35 01 4d 69 |.RPf1.f…f…5.Mi|
00000060 73 73 69 6e 67 20 6f 70 65 72 61 74 69 6e 67 20 |ssing operating |
00000070 73 79 73 74 65 6d 2e 0d 0a 66 60 66 31 d2 bb 00 |system…ff1...| 00000080 7c 66 52 66 50 06 53 6a 01 6a 10 89 e6 66 f7 36 ||fRfP.Sj.j...f.6| 00000090 f4 7b c0 e4 06 88 e1 88 c5 92 f6 36 f8 7b 88 c6 |.{.........6.{..| 000000a0 08 e1 41 b8 01 02 8a 16 fa 7b cd 13 8d 64 10 66 |..A......{...d.f| 000000b0 61 c3 e8 c4 ff be be 7d bf be 07 b9 20 00 f3 a5 |a......}.... ...| 000000c0 c3 66 60 89 e5 bb be 07 b9 04 00 31 c0 53 51 f6 |.f…1.SQ.|
000000d0 07 80 74 03 40 89 de 83 c3 10 e2 f3 48 74 5b 79 |…t.@…Ht[y|
000000e0 39 59 5b 8a 47 04 3c 0f 74 06 24 7f 3c 05 75 22 |9Y[.G.<.t.$.<.u"|
000000f0 66 8b 47 08 66 8b 56 14 66 01 d0 66 21 d2 75 03 |f.G.f.V.f…f!.u.|
00000100 66 89 c2 e8 ac ff 72 03 e8 b6 ff 66 8b 46 1c e8 |f…r…f.F…|
00000110 a0 ff 83 c3 10 e2 cc 66 61 c3 e8 76 00 4d 75 6c |…fa…v.Mul|
00000120 74 69 70 6c 65 20 61 63 74 69 76 65 20 70 61 72 |tiple active par|
00000130 74 69 74 69 6f 6e 73 2e 0d 0a 66 8b 44 08 66 03 |titions…f.D.f.|
00000140 46 1c 66 89 44 08 e8 30 ff 72 27 66 81 3e 00 7c |F.f.D…0.r’f.>.||
00000150 58 46 53 42 75 09 66 83 c0 04 e8 1c ff 72 13 81 |XFSBu.f…r…|
00000160 3e fe 7d 55 aa 0f 85 f2 fe bc fa 7b 5a 5f 07 fa |>.}U…{Z_…|
00000170 ff e4 e8 1e 00 4f 70 65 72 61 74 69 6e 67 20 73 |…Operating s|
00000180 79 73 74 65 6d 20 6c 6f 61 64 20 65 72 72 6f 72 |ystem load error|
00000190 2e 0d 0a 5e ac b4 0e 8a 3e 62 04 b3 07 cd 10 3c |…^…>b…<|
000001a0 0a 75 f1 cd 18 f4 eb fd 00 00 00 00 00 00 00 00 |.u…|
000001b0 00 00 00 00 00 00 00 00 b6 c8 5b 0c a8 01 00 00 |…[…|
000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |…U.|
1+0 enregistrements lus
1+0 enregistrements écrits
512 bytes copied, 0,00369256 s, 139 kB/s
00000200

Merci pour votre aide …
Patrick

#2

Un formatage brutal en fat 32 avec gparted ou équivalent ne fonctionne pas ?

Ma réponse est idiote, je suppose que tu souhaite récupérer les infos…
donc voir :
http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:usbboot#restoring_a_usb_stick_to_its_original_state

#3

Un passage rapide pour limiter les dégâts et tenter de sauver les baleines.

@jweber
"Un formatage brutal de FTA32" ne permettra certainement pas de récupérer des données, mais plutôt de les faire disparaitre à jamais, mais j’ai peut-être mal compris le sujet.

@gelinp
Si jweber te propose de formater ta clef, c’est peut-être parce-que le titre de ton sujet ne reflète pas clairement les manips que tu fais. Je sens une confusion entre MBR et table de partition.

Dans l’hypothèse où tu as des données importantes sur cette clef, et que tu souhaites récupérer (?), le première chose à faire avant de tripatouiller le MBR aurait été de faire une copie exacte de ta clef avec Dédé.

dd if=/dev/sdX of=./maClef bs=1M && sync

!! si la clef fait 64 Go,… le fichier maClef fera … 64 Go.

Si tu souhaites récupérer les données, tes manips ne permettront en aucun cas de récupérer une de table de partition !
La partie la plus importante du MBR (512 bytes = 1er secteur) est la FAT comprise entre 446 et 512 (0x1BE > 0x1FF), ou mieux un peu plus étendue entre 440 et 512 (soit 72 bytes.
Le reste de cette zone est ultra classique et sans difficulté, à condition de comprendre un minimum ce qu’on fait.

Si ton objectif est d’essayer de récupérer les données, essaie testdisk qui retrouvera les différentes possibilités de FAT selon leur historique, en espérant qu tes manips successives n’aient pas fait trop de massacre.

Si ton objectif est autre, ou simplement recréer ta clef, c’est différent, et il faudrait préciser exactement ce que tu veux faire avec cette clef.
Pour reconstruire une clef propre et fiable, et compatible multi-BIOS en cas de bootloader intégré, ou juste bricoler sous windows pour copier de données et des virus, ce n’est absolument pas la même démarche !!

#4

Mon objectif est de récupérer les fichiers de la clé, avec si possible l’architecture des dossiers et les dates correctes des fichiers. Des logiciels payants me liste environ 2300 fichiers récupérables, ce qui semble correspondre à ce que l’on attend. Y compris avec la structure des dossiers. Mais l’étape finale demande de payer au moins 60 € pour le moins cher. Par exemple le logiciel RecoveryMyFiles semble bien fonctionner…

La clé avait déjà été bidouillée avant que je ne la récupère. J’ai commencer par faire un drescue qui m’a fait une copie de ma partition sur mon disque dur externe. Je comprends qu’il essaie dans le mouvement de corriger la partition, donc elle ne doit effectivement pas être identique à l’originale.

J’ai aussi testé testdik, il cherche la partition mais ne trouve rien, même après la seconde recherche plus avancée …

ma clé fait 32 GO, mais fdisk indique 28,7 Go (voir-ci-dessous). Je comprends que la géométrie indiquée par le MBR ou autre infos spécifiques à la configuration de la partition ne correspond pas … Je ne suis pas spécialiste des partitions.

Disque /dev/sdc : 28,7 GiB, 30828134400 octets, 60211200 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x0c5bc8b6

J’ai essayé aussi avec gparted de récupérer la partition. Il semble bien fonctionner, mais à la fin de la procédure il devrait ouvrir le gestionnaire d efichier sur la patition récupérée, mais aucune fenêtre ne s’ouvre … J’ai essayé sous Fxce, KDE, Gnome …

#5

Certainement une clef qui a été construite n’importe comment à l’origine, et retripatouillée…
Déjà voir les retours de chaque ligne (voir cohérence construction C/H/S)

sudo fdisk /dev/sdc
p
u
p

Pour testdisk, il faut justement l’aider à comprendre cette construction CHS (Cylinders / Heads / Sectors) [ voir options avancées de testdisk / de mémoire… ]

#6

Ou au minimum une copie du MBR original. 512 octets. Maintenant c’est trop tard.

Un “MBR FAT32”, ça n’existe pas. De deux choses l’une :

  • soit la clé est partitionnée (le plus fréquent) et le premier secteur contient un MBR (Master boot record) avec une table de partition qui définit une partition contenant un système de fichiers FAT32 ;

  • soit la clé n’est pas partitionnée (cas moins fréquent) et le premier secteur ne contient pas un MBR mais le BPB (BIOS parameter block) qui identifie un système de fichier FAT32.

Le fichier mbr.bin que tu as utilisé pour réécrire le premier secteur fait 440 octets, donc il n’a pas écrasé une éventuelle table de partition. Mais le dump montre que celle-ci, si elle existe, est vide. Par contre si le secteur contenait un BPB, alors son contenu a été écrasé.

Si testdisk ne détecte aucune partition, il est à craindre que la clé n’était pas partitionnée.
Tu peux essayer de récupérer le contenu des fichiers avec son frère photorec ou equivalent (foremost…) mais cela ne retrouve pas les noms ni l’arborescence, et ne fonctionne qu’avec les fichiers non fragmentés de types connus par le logiciel.

Non, elle ne fait pas 28,7 Go mais 28,7 Gio, soit un peu moins de 31 Go. Rien à voir avec la géométrie CHS, qui n’est pas un concept pertinent avec les clés USB et autres disques modernes.

#7
  • Vrai pour un disque dur, ou un SSD ;
  • Faux pour une clef USB, sauf si c’est juste pour y copier bêtement des données.

Une fois la table de partition perdue, la seule manière pour Testdisk d’essayer de retrouver des tables de partition est d’essayer de retrouver une logique de structure CHS, et de retrouver des EPBR.
L’idéal est de retrouver une structure classique à 255 têtes et 63 secteurs/tête (1 secteur = 512 B) comprise par tous les BIOS.
Le jour où tu feras une clef bootable qui marche parfaitement sur un PC, et pas du tout sur un autre, tu reverras ton point de vue sur le concept de “modernité”.
Ce n’est pas beaucoup plus compliqué de faire une clef proprement construite, permettant une meilleure compatibilité BIOS.

Si Gparted permet justement l’alignement des partitions sur les cylindres, ce n’est pas totalement par hasard (…).
Mais d’autres outils bas niveau savent aussi très bien le faire.

#8

Merci beaucoup pour votre aide. Désolé pour le temps d’attente mais je ne peux pas rester devant mon PC pour attendre. Je vais revenir plus régulièrement voir vos réponses, mais je dois encore m’absenter cet après midi. Je serai de retour vers 17h. CI-dessous la commande fdisk comme demandé :

sudo fdisk /dev/sdc
Commande (m pour l’aide) : p
Disque /dev/sdc : 28,7 GiB, 30828134400 octets, 60211200 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x0c5bc8b6

Commande (m pour l’aide) : u
Modification des unités d’affichage et de saisie en cylindre (obsolète).

Commande (m pour l’aide) : p
Disque /dev/sdc : 28,7 GiB, 30828134400 octets, 60211200 secteurs
Géométrie : 64 têtes, 32 secteurs/piste, 29400 cylindres
Unités : cylindre de 2048 × 512 = 1048576 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x0c5bc8b6

#9

N’importe quoi. Les deux ont la même structure logique et s’utilisent de la même façon.

La géométrie CHS est obsolète et a perdu toute signification physique depuis des décennies. Elle a été avantageusement remplacée par l’adressage linéaire LBA.

Si c’est vraiment ce que fait testdisk, je comprends pourquoi il marche si mal. Les partitions ne sont plus alignées sur des cylindres mais sur des blocs de 1 Mio.

Les BIOS ont des bugs. Tu parles d’un scoop.
Trève de plaisanterie. Tout BIOS de moins de 20 ans connaît l’adressage LBA, et n’a que faire de la structure de partitions d’un disque. Ce n’est pas son problème mais celui du programme d’amorçage installé dans le MBR et du système d’exploitation.

Gparted n’aligne plus les partition sur des cylindres par défaut. S’il permet de le faire, c’est uniquement pour la compatibilité avec de très anciens systèmes.

#10

[quote=“PascalHambourg, post:9, topic:75105”]Gparted n’aligne plus les partition sur des cylindres par défaut. S’il permet de le faire, c’est uniquement pour la compatibilité avec de très anciens systèmes.[/quote]Merci, mais ça on savait…
C’est même exactement ce que je t’explique => garantir une compatibilité BIOS (à moins que tu ne cherches la polémique).
Une clef USB est par définition mobile et portable, plus qu’un disque dur installé dans son châssis.
Figure toi que j’ai déjà passé des journées entières sur ce sujet de “compatibilité” (…) , pour faire la différence entre théorie et pratique, et percer le mystère du BIOS qui comprend, et l’autre qui ne comprend pas.

@gelinp
Je propose que PascalHambourg prenne la suite pour t’aider de manière effective et efficace à retrouver tes données avec des outils “modernes”.
Bonne chance à vous deux.