Чому запис випадкових даних за допомогою 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

partition dd lsblk

— Мотивований
джерело

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

— Мотивовано

1

Збіг обставин: це дуже неправдоподібно пов'язане з відключенням електроенергії. Ви записуєте випадкові дані на пристрій. Деякі з цих випадкових даних перейшли до перших блоків, саме тут живуть таблиці розділів. Ви, ймовірно, визначили розділ.

— ctrl-alt-delor

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

— phuclv

@phuclv - Як я почав процес, чи буде результат все ще цінним?

— Мотивовано

1

@ Мотивоване Зауважте, що ddціль не полягає в тому, щоб стерти диски. Запис випадкових даних на диск може призвести до випадкових результатів.

— jjmontes

20

Кілька можливостей:

Linux підтримує безліч різних типів таблиць розділів, деякі з яких використовують дуже мало магічних байтів, і тоді легко визначити випадкові дані (*) [так що можливо випадковим чином генерувати дещо "дійсну" таблицю розділів].
Деякі типи таблиць розділів також мають резервні копії в кінці диска (особливо це стосується GPT), і їх можна було взяти, якщо початок диску буде замінено випадковим сміттям.
Пристрій не працює належним чином, і його було відключено до того, як він закінчив записувати дані або не повертає старі дані, тому таблиця розділів зберігається. Іноді це відбувається з USB-накопичувачами.
...

(*) Створіть 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 нульове спочатку кілька секторів будь-якого створеного НН, так що старі дані не заважатимуть.

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

— заморожувати
джерело

Раніше стирали пристрої за допомогою команди ATA Secure Erase. Я припускаю, що це видалить дані так, що 1. це не можна відновити 2. жодна інформація про розділи не збереглася. Якщо це правда, ви хочете сказати, що під час виконання ddкоманди генерація випадкових даних при перериванні може призвести до даних, схожих на таблиці розділів? Також це жорсткі диски SATA (не-SSD).

— Мотивовано

5

Випадкові дані можуть виглядати як завгодно. Ось що означає бути випадковим. Ви знайомі з теоремою нескінченних мавп? У ньому йдеться про те, що якщо достатньо велика кількість мавп навмання набереться на друкарських машинках протягом досить тривалого часу, одна з них в той чи інший момент створить цілі твори Шекспіра. Таблиця розділів MBR насправді невелика (всього 64 байти), у ній немає контрольних сум чи перевірки та дуже щільний формат. Велика ймовірність, що випадкова рядок у 64 байти створить дійсну таблицю розділів. Інші формати таблиць розділів аналогічно прості.

— Йорг W Міттаг

Так, таблиця розділів становить лише 64 байти, (в кінці) тип розділу лише 1 байт, і записи повинні бути законними або послідовними. Тож обнулення першого кластера / сектора / 512 байтів на MBR є розумним. Ви також не хочете непередбачуваної поведінки завантаження, менш вірогідного, але все ж ризику.

— mckenzm

18

Як бачимо тут, MBR (Master Boot Record) порівняно простий; https://en.wikipedia.org/wiki/Master_boot_record .

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

Linux також підтримує інші додаткові формати диска, які також потенційно можуть бути спровоковані, викликаючи появу "недійсних" розділів при заповненні випадковими даними.

— Адам Вальденберг
джерело

13

Те, що визначає колекцію з 512 байтів як основний запис завантаження, - це наявність значень 0x55 0xAAв кінці. Є ймовірність 1 на 65 656, щоб /dev/urandomстворити таку цінність: не надто ймовірно, але незмінно все це трапляється постійно.

(Деякі інші таблиці розділів, наприклад, карта розділів Apple , мають аналогічно короткі підписи. Можливо, ви створили одну з них замість цього.)

— Позначити
джерело

3

Чи був такий розділ деякий час раніше на цьому диску? Якщо на диску використовується GPT, можливо, вторинний заголовок GPT був відновлений, і він все ще мав стару таблицю розділів.

https://en.wikipedia.org/wiki/GUID_Partition_Table

— Якуб Фойтик
джерело