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 quand je me connecte à une machine Linux (xubuntu 12.04), il peut monter une partition et parsingr le système de files (comme GParted). Cependant, quand j'essaie de lire le MBR de l'appareil en utilisant dd, il me donne un tas de données fausses.

Quelqu'un pourrait-il jeter un peu de lumière sur la façon dont Linux / GParted est capable de lire et de donner un sens au MBR lorsque dd n'est pas capable de lire le MBR. Utilisent-ils différentes methods pour get datatables? IE pas ouvert (), lire ()

La command 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 est:

 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 

Je voudrais essayer d'utiliser la command sfdisk 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, en regardant mbr_using_sfdisk.bin révèle ce que vous cherchez:

 $ 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 en utilisant dd ?

Je ne suis pas tout à fait sûr pourquoi mais j'ai rencontré cette astuce qui vous montre comment voir les tables de partition dans votre mbr.bin utilisant la command de file .

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) copyd, 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 

Les references

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

La carte n'a pas de Master Boot Record (MBR). Si votre hexdump vous aurait donné au less une input de partition au décalage 0x1C0 et 55aa à la fin.

Toutes les tables de partition ne présentent pas datatables dans les 512 premiers octets. Les données parasites que vous voyez sont SID et CSD registre de (a / la) carte SD. Mais d'après son apparence, ce ne sont pas datatables correctes pour la carte (sauf s'il s'agit d'un ancien model 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 

Suivant 16 octets (au less en 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 classs (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 

Le contrôle CRC7 pour le registre CSD est également incorrect. Il pourrait s'agir d'anciennes données laissées par le passé.

Ces registres et plus peuvent être interrogés directement depuis la carte par différentes commands. Cela se fait par les pilotes de module, les concentrateurs de maps, etc.


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

Ces données ne sont pas la memory de votre carte SD, mais sont envoyées par votre controller de carte SD (ASMI). Cette page décrit le problème comme il m'est arrivé:

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