Linux / GParted può vedere la tabella delle partizioni ma dd bs = 512 count = 1 no

Ho una scheda SD formattata MBR e quando mi collego a una macchina Linux (xubuntu 12.04) può montare una partizione e analizzare il file system (come GParted). Tuttavia, quando provo a leggere l'MBR dal dispositivo usando dd mi dà un sacco di dati spuri.

Qualcuno potrebbe far luce su come Linux / GParted è in grado di leggere e dare un senso all'MBR quando dd non è in grado di leggere l'MBR. Usano metodi diversi per ottenere i dati? IE non open (), read ()

Il comando DD è:

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

L'output DD è:

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

mbr.bin dump con 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 scheda non ha un Master Boot Record (MBR). Se avesse avuto il tuo hexdump ti avrebbe dato almeno una voce di partizione in offset 0x1C0e 55aaalla fine.

Non tutte le tabelle delle partizioni dispongono i dati nei primi 512 byte. I dati spuri che vedi sono il registro SID e CSD della (a / la) scheda SD. Ma dal suo aspetto, non sono i dati corretti per la scheda (a meno che non sia un vecchio modello 1 MiB 2001).

I primi 16 byte sono:

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

Prossimi 16 byte (almeno in parte):

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

Inoltre, il controllo CRC7 per il registro CSD è errato. Potrebbero essere vecchi dati lasciati da un passatempo.

Quei registri e altro ancora possono essere interrogati direttamente dalla carta da vari comandi. Questo viene fatto da driver di modulo, hub di schede, ecc.

Sarebbe interessante vedere cosa trovi dai comandi dati da Stephane Chazelas, slm ecc.

Proverei a usare il sfdiskcomando al contrario di dd. Per esempio:

$ 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.

Ora guardando mbr_using_sfdisk.binrivela ciò che stai cercando:

$ 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

Quindi perché non riesco a vedere la tabella delle partizioni usando dd?

Non sono del tutto sicuro del perché, ma mi sono imbattuto in questo trucco che ti mostra come vedere le tabelle delle partizioni mbr.binusando il filecomando.

Per esempio:

$ 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

Riferimenti

• Come copiare il layout della partizione di un intero disco usando strumenti standard
• Tabelle delle partizioni MBR / EBR ← eccellente tutorial su MBR!
• Un esempio di Master Boot Record

Questi dati non sono la memoria della scheda SD, ma vengono inviati dal controller della scheda SD (ASMI). Questa pagina descrive il problema come è successo a me:

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