Почему запись случайных данных с использованием dd приводит к разделам диска?


11

Перед выполнением ddкоманды команда lsblkвернула вывод ниже:

NAME              MAJ:MIN  RM   SIZE    RO TYPE  MOUNTPOINT
sda               8:0       0    931.5G  0  disk  

Команда dd if=/dev/urandom of=/dev/sda conv=fsync status=progressзапускается. Устройство, однако, теряет питание и выключается. Когда питание восстанавливается, команда lsblkвозвращает следующий вывод:

NAME              MAJ:MIN     RM   SIZE    RO TYPE  MOUNTPOINT
    sda           8:0          0   931.5G  0  disk 
      sda2        8:2          0   487.5G  0  disk

@RuiFRibeiro - Спасибо за аналогию, однако неясно, почему ddмогут возникнуть разделы, особенно если команда предназначена для очистки дисков?
Мотивировано

1
Совпадение: очень маловероятно, что оно связано с отключением электроэнергии. Вы записываете случайные данные на устройство. Некоторые из этих случайных данных пошли в первые несколько блоков, именно здесь живут таблицы разделов. Вы, вероятно, в конечном итоге определить раздел.
Ctrl-Alt-Delor

Вы можете опубликовать результат file /dev/sda*и sudo fdisk -l /dev/sda*?
phuclv

@phuclv - Как я начал процесс, будет ли выход по-прежнему ценным?
Мотивировано

1
@Mooted Обратите внимание, что ddцель не состоит в том, чтобы стирать диски. Запись случайных данных на диск может привести к случайным результатам.
Jjmontes

Ответы:


20

Несколько возможностей:

  • Linux поддерживает множество различных типов таблиц разделов, некоторые из которых используют очень мало магических байтов, и тогда легко ошибочно идентифицировать случайные данные (*) [так что возможно случайным образом генерировать несколько «правильную» таблицу разделов].

  • Некоторые типы таблиц разделов также имеют резервные копии в конце диска (в частности, GPT), и их можно было бы найти, если бы диск был заменен случайным мусором.

  • Устройство не работает должным образом, и оно было отключено до завершения записи данных или продолжает возвращать старые данные, поэтому таблица разделов сохраняется. Иногда это происходит с флешками.

  • ...

(*) Создайте 1000 файлов со случайными данными в них и посмотрите, что получится:

$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP\011Secret Sub-key -
....

Цель случайного уничтожения диска - заставить старые данные исчезнуть навсегда. Нет никаких обещаний, что диск будет казаться пустым, неиспользованным, в идеальном состоянии после этого.

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

Также есть специальная утилита ( wipefs) для избавления от старых магических байтовых сигнатур, которую вы можете использовать, чтобы избавиться от метаданных файловой системы и таблицы разделов.


Устройства были ранее удалены с помощью команды ATA Secure Erase. Я предполагаю, что это приведет к удалению данных таким образом, что: 1. оно не подлежит восстановлению; 2. информация о разделах не сохраняется. Если это так, то хотите ли вы сказать, что при выполнении ddкоманды генерация случайных данных при прерывании может привести к получению данных, похожих на таблицы разделов? Также это жесткие диски SATA (без SSD).
Мотивировано

5
Случайные данные могут выглядеть как угодно. Вот что значит быть случайным. Вы знакомы с теоремой о бесконечных обезьянах? В нем говорится, что если достаточно большое количество обезьян случайным образом печатать на пишущих машинках в течение достаточно длительного времени, то одна из них в тот или иной момент произведет полное произведение Шекспира. Таблица разделов MBR действительно мала (всего 64 байта), не имеет контрольных сумм или проверок, и имеет очень плотный формат. Весьма вероятно, что случайная строка размером 64 байта создаст правильную таблицу разделов. Другие форматы таблиц разделов также просты.
Йорг Миттаг

Да, таблица разделов составляет только 64 байта, (в конце) тип раздела - только 1 байт, и записи должны быть законными или последовательными. Таким образом, обнуление первого кластера / сектора / 512 байтов на MBR имеет смысл. Вы также не хотите непредсказуемого поведения загрузки, менее вероятно, но все же риск.
Маккензм

18

Как видно здесь, MBR (Master Boot Record) относительно проста; https://en.wikipedia.org/wiki/Master_boot_record .

При использовании /dev/urandomвы всегда можете создать что-то похожее на таблицу разделов. Решение состоит в том, чтобы заполнить регионы таблицы разделов нулями и использовать dev/urandomдля остальных.

Linux также поддерживает другие дополнительные форматы дисков, которые также могут быть запущены, в результате чего при заполнении случайными данными появляются «неверные» разделы.


13

То, что определяет коллекцию из 512 байтов как основную загрузочную запись, - это наличие значений 0x55 0xAAв конце. Существует 1 из 65 536 шансов /dev/urandomполучить такую ​​ценность: не слишком вероятно, но подобные невероятные вещи случаются постоянно.

(Некоторые другие таблицы разделов, такие как Apple Partition Map , имеют аналогично короткие подписи. Возможно, вы сгенерировали одну из них.)


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.