Linux / GParted может видеть таблицу разделов, но dd bs = 512 count = 1 не может

У меня есть sd-карта в формате MBR, и при подключении к машине с Linux (xubuntu 12.04) она может смонтировать раздел и проанализировать файловую систему (как может GParted). Тем не менее, когда я пытаюсь прочитать MBR с устройства, используя dd, это дает мне кучу ложных данных.

Может ли кто-нибудь пролить свет на то, как Linux / GParted может читать и понимать MBR, когда dd не может читать MBR. Используют ли они разные методы для получения данных? IE не открывается (), читать ()

Команда DD:

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

Выход DD:

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

дамп mbr.bin с 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

Карта не имеет основной загрузочной записи (MBR). Если бы он имел ваш hexdump, вы бы получили по крайней мере одну запись раздела со смещением 0x1C0и 55aaв конце.

Не все таблицы разделов выкладывают данные в первые 512 байт. Поддельные данные вы видите SID и CSD регистр (а / с) SD - карты. Но, судя по всему, это неверные данные для карты (если только это не старая модель 1 МБ 2001 года).

Первые 16 байтов:

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 байт (хотя бы часть из них):

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

Кроме того, проверка CRC7 для регистра CSD является неправильной. Это могут быть старые данные, оставленные от времяпровождения.

Эти и другие регистры можно запрашивать непосредственно с карты различными командами. Это делают драйверы модулей, концентраторы карт и т. Д.

Было бы интересно посмотреть, что вы найдете по командам, данным Stephane Chazelas, slm и т. Д.

Я бы попытался использовать sfdiskкоманду, а не dd. Например:

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

Теперь глядя на mbr_using_sfdisk.binпоказывает, что вы ищете:

$ 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

Так почему я не вижу, как использовать таблицу разделов dd?

Я не совсем уверен , почему , но я наткнулся на эту уловку , что показывает вам , как увидеть таблицы разделов в вашей mbr.binпомощи fileкоманды.

Например:

$ 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

Ссылки

• Как скопировать структуру разделов целого диска, используя стандартные инструменты
• Таблицы разделов MBR / EBR ← отличный учебник по MBR!
• Пример Master Boot Record

Эти данные не являются памятью вашей SD-карты, но отправляются вашим контроллером SD-карты (ASMI). Эта страница описывает проблему, как это случилось со мной:

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