Linux / GParted peut voir la table de partition mais dd bs = 512 count = 1 ne peut pas

J'ai une carte SD formatée MBR et lorsque je me connecte à une machine Linux (xubuntu 12.04), elle peut monter une partition et analyser le système de fichiers (comme GParted). Cependant, lorsque j'essaie de lire le MBR de l'appareil à l'aide de dd, cela me donne un tas de données parasites.

Quelqu'un pourrait-il nous éclairer sur la façon dont Linux / GParted est capable de lire et de comprendre le MBR lorsque dd n'est pas capable de lire le MBR. Utilisent-ils différentes méthodes pour obtenir les données? IE pas ouvert (), lu ()

La commande DD est:

dd if=/dev/sdb of=mbr.bin bs=512 count=1

La sortie DD est:

1+0 records in
1+0 records out
512 bytes transferred in 0.000786 secs (651345 bytes/sec)

vidage mbr.bin avec hexdump -C mbr.bin:

00000000  04 16 41 53 4d 49 2d 53  44 03 00 00 00 00 16 f1  |..ASMI-SD.......|
00000010  00 7f 00 32 1f 5b 80 00  36 db bf bf 96 c0 00 01  |...2.[..6.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  6f 00 00 10 00 00 02 2e  00 00 00 00 00 00 00 00  |o...............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

La carte n'a pas de Master Boot Record (MBR). S'il l'avait eu, votre hexdump vous aurait donné au moins une entrée de partition à l'offset 0x1C0et 55aaà la fin.

Toutes les tables de partition ne présentent pas les données dans les 512 premiers octets. Les données parasites que vous voyez sont le registre SID et CSD de (a / la) carte SD. Mais à première vue, ce ne sont pas les données correctes pour la carte (sauf s'il s'agit d'un ancien modèle de 1 MiB 2001).

Les 16 premiers octets sont:

CID Register:
----------------------------------------------------------------------------
Manufacturer ID       (MID): 04               => (Transcend)
OEM/Application ID    (OID): 16 41            =  ?A
Product name          (PNM): 53 4d 49 2d 53   =  SMI-S
Product revision      (PRV): 44               =  0100 0100 => 4.4
Product serial number (PSN): 03 00 00 00
reserved               (-) : 00 >> 4          = 0000b
Manufacturing date    (MDT): (00 & 0x0f)|0x16 = 0001b,0110b => 2000+1,6=> Jun 2001
CRC7 checksum         (CRC): 1f >> 1          = 120
always 1               (1) : 1f & 1           = 1

16 octets suivants (au moins une partie):

CSD Register:
----------------------------------------------------------------------------
CSD Structure        (CSD_STRUCTURE): 00 >> 6  = 00b => CSD Version 1.0
reserved                         (-): 00 & 3f  = 00 0000b
Data read access time 1       (TAAC): 7f = 1111b => time val 8.0, 111b => 7=10ms
Data read access time 2       (NSAC): 00
Max. data transfer rate (TRAN_SPEED): 32 = 0110,010 time val 2.5, 2=10Mbit/s 25MHz
Card command classes           (CCC): 1f << 4 | 5b >> 4 = 0x1f5

...
Device size (C_SIZE) : (0x80 & 0x03) << 0xa | 00h | 36 >> 6 : 0

Max. read  current @VDD min (VDD_R_CURR_MIN) : 110 => 60mA
Max. read  current @VDD max (VDD_R_CURR_MAX) : 110 => 80mA
Max. write current @VDD min (VDD_W_CURR_MIN) : 110 => 60mA
Max. write current @VDD max (VDD_W_CURR_MAX) : 110 => 80mA
Device size multiplier         (C_SIZE_MULT) : 111 => 2^(7 + 2) = 512
Erase single block enable     (ERASE_BLK_EN) : 0
Erase sector size              (SECTOR_SIZE) : 1111111 => 127 + 1 = 128
Write protect group size       (WP_GRP_SIZE) : 0111111 =>  63 + 1 = 64

MULT      = 2^(C_SIZE_MULT + 2)  = 2^(7 + 2) = 512
BLOCKNR   = (C_SIZE + 1) * MULT  = 1 * 512   = 512
BLOCK_LEN = 2^READ_BL_LEN        = 2^11      = 2048

memory capacity = 
BLOCKNR * BLOCK_LEN = 512 * 2048 = 1048576 bytes = 1024 KiB = 1 MiB

De plus, la vérification CRC7 du registre CSD est erronée. Il peut s'agir d'anciennes données d'un passe-temps.

Ces registres et plus peuvent être interrogés directement depuis la carte par diverses commandes. Cela se fait par les pilotes de modules, les concentrateurs de cartes, etc.

Serait intéressant de voir ce que vous trouvez par les commandes données par Stéphane Chazelas, slm etc.

J'essaierais d'utiliser la sfdiskcommande par opposition à dd. Par exemple:

$ sudo sfdisk -d /dev/sda > /tmp/mbr_using_sfdisk.bin
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.

Maintenant, regarder mbr_using_sfdisk.binrévèle ce que vous recherchez:

$ more /tmp/mbr_using_sfdisk.bin
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=     2048, size=  2457600, Id= 7, bootable
/dev/sda2 : start=  2459648, size=314765312, Id= 7
/dev/sda3 : start=956291072, size= 20480000, Id= 7
/dev/sda4 : start=317224960, size=639066112, Id= 5
/dev/sda5 : start=317227008, size=  1024000, Id=83
/dev/sda6 : start=318253056, size=638038016, Id=8e

Alors, pourquoi ne puis-je pas voir la table de partition utiliser dd?

Je ne sais pas exactement pourquoi, mais je suis tombé sur cette astuce qui vous montre comment voir les tables de partition dans votre mbr.binutilisation de la filecommande.

Par exemple:

$ sudo dd if=/dev/sda bs=512 count=1 of=mbr.bin
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000184924 s, 2.8 MB/s

$ file mbr.bin 
mbr.bin: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x12f0c26a, GRUB version 0.94; 
partition 1: ID=0x7, active, starthead 32, startsector 2048, 2457600 sectors; 
partition 2: ID=0x7, starthead 162, startsector 2459648, 314765312 sectors;
partition 3: ID=0x7, starthead 239, startsector 956291072, 20480000 sectors;
partition 4: ID=0x5, starthead 239, startsector 317224960, 639066112 sectors, code offset 0x48

Références

• Comment copier la disposition des partitions d'un disque entier à l'aide d'outils standard
• Tables de partition MBR / EBR ← excellent tutoriel sur MBR!
• Un exemple de Master Boot Record

Ces données ne sont pas la mémoire de votre carte SD, mais sont envoyées par votre contrôleur de carte SD (ASMI). Cette page décrit le problème tel qu'il m'est arrivé:

http://www.idioten-notschlachten.de/blog/2011/11/13/kennen-sie-asmi/