Linux / GParted pode ver a tabela de partição, mas dd bs = 512 count = 1 não pode

Eu tenho um cartão SD formatado em MBR e, quando conectado a uma máquina Linux (xubuntu 12.04), ele pode montar uma partição e analisar o sistema de arquivos (como o GParted). No entanto, quando tento ler o MBR do dispositivo usando o dd, ele fornece um monte de dados espúrios.

Alguém poderia lançar alguma luz sobre como o Linux / GParted é capaz de ler e entender o MBR quando o dd não é capaz de ler o MBR. Eles usam métodos diferentes para acessar os dados? IE não aberto (), leia ()

O comando DD é:

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

A saída DD é:

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

O dump do mbr.bin com 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

O cartão não possui um registro mestre de inicialização (MBR). Se o seu hexdump tivesse fornecido pelo menos uma entrada de partição no deslocamento 0x1C0e 55aano final.

Nem todas as tabelas de partição distribuem dados nos primeiros 512 bytes. Os dados espúrios que você vê são o registro SID e CSD do (a) cartão SD. Mas, pelo que parece, não são os dados corretos para o cartão (a menos que seja um modelo antigo do 1 MiB 2001).

Os primeiros 16 bytes são:

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

Próximos 16 bytes (pelo menos parte dele):

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

Além disso, a verificação CRC7 para registro de CSD está incorreta. Podem ser dados antigos deixados em um passatempo.

Esses registradores e mais podem ser consultados diretamente no cartão por vários comandos. Isso é feito por drivers de módulo, hubs de cartões etc.

Seria interessante ver o que você encontra pelos comandos dados por Stephane Chazelas, slm etc.

Eu tentaria usar o sfdiskcomando em oposição a dd. Por exemplo:

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

Agora, a análise mbr_using_sfdisk.binrevela o que você está procurando:

$ 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

Então, por que não consigo ver a tabela de partição usando dd?

Não sei bem por que, mas me deparei com esse truque que mostra como ver as tabelas de partição mbr.binusando o filecomando

Por exemplo:

$ 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

Referências

• Como copiar o layout da partição de um disco inteiro usando ferramentas padrão
• Tabelas de partição MBR / EBR ← excelente tutorial sobre MBR!
• Um exemplo de registro mestre de inicialização

Esses dados não são a memória do seu cartão SD, mas são enviados pelo seu controlador de cartão SD (ASMI). Esta página descreve o problema como aconteceu comigo:

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