Dlaczego zapisywanie losowych danych przy użyciu dd powoduje partycje dysku?

11

Przed uruchomieniem ddpolecenia polecenie lsblkzwróciło wynik poniżej:

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

Polecenie dd if=/dev/urandom of=/dev/sda conv=fsync status=progressjest uruchamiane. Jednak urządzenie traci moc i wyłącza się. Po przywróceniu zasilania polecenie lsblkzwraca następujące dane wyjściowe:

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

— Zmotywowany
źródło

@RuiFRibeiro - Dzięki za analogię, jednak nie jest jasne, dlaczego ddmiałoby to prowadzić do partycji, szczególnie jeśli polecenie ma wyczyścić dyski?

— Zmotywowany

1

Zbieg okoliczności: jest bardzo mało prawdopodobne, aby było to związane z odcięciem zasilania. Zapisujesz losowe dane na urządzeniu. Niektóre z tych losowych danych trafiły do kilku pierwszych bloków, tutaj znajdują się tabele partycji. Prawdopodobnie zakończyłeś definiowanie partycji.

— ctrl-alt-delor

czy możesz opublikować wynik file /dev/sda*i sudo fdisk -l /dev/sda*?

— phuclv

@phuclv - Czy po rozpoczęciu procesu dane wyjściowe nadal będą cenne?

— Zmotywowany

1

@ Zmotywowany Należy pamiętać, że ddcelem nie jest samo czyszczenie dysków. Zapisywanie losowych danych na dysku może dawać losowe wyniki.

— jjmontes

20

Kilka możliwości:

Linux obsługuje wiele różnych typów tablic partycji, niektóre z nich wykorzystują bardzo mało magicznych bajtów, a następnie łatwo jest błędnie zidentyfikować losowe dane (*) [więc można losowo wygenerować nieco „prawidłową” tablicę partycji].
Niektóre typy tablic partycji mają również kopie zapasowe na końcu dysku (zwłaszcza GPT) i można je było pobrać, jeśli początek dysku zostałby zastąpiony losowymi śmieciami.
Urządzenie nie działa poprawnie i zostało odłączone przed zakończeniem zapisywania danych lub zwraca stare dane, więc tabela partycji przetrwa. Czasami dzieje się tak w przypadku pamięci USB.
...

(*) Utwórz 1000 plików z losowymi danymi i zobacz, co się pojawi:

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

Celem losowego niszczenia dysku jest usunięcie starych danych na dobre. Nie ma obietnicy, że napęd będzie potem pusty, nieużywany, w nienaruszonym stanie.

Aby to osiągnąć, często wykonuje się zerowanie. Jeśli używasz LVM, LVM normalnie zeruje kilka pierwszych sektorów dowolnego utworzonego LVM, aby stare dane nie przeszkadzały.

Istnieje również dedykowane narzędzie ( wipefs) do usuwania starych podpisów bajtów, których można użyć do pozbycia się metadanych systemu plików i tablicy partycji.

— frostschutz
źródło

Urządzenia zostały wcześniej usunięte za pomocą polecenia ATA Secure Erase. Zakładam, że spowodowałoby to usunięcie takich danych, że 1. jest to niemożliwe do odzyskania 2. żadna informacja o partycji nie zostaje zachowana. Jeśli to prawda, czy masz na myśli powiedzieć, że po uruchomieniu ddpolecenia generowanie losowych danych po przerwaniu może spowodować, że dane wyglądają jak tablice partycji? Są to także dyski twarde SATA (inne niż SSD).

— Zmotywowany

5

Losowe dane mogą wyglądać jak wszystko. To znaczy być losowym. Czy znasz Twierdzenie o Nieskończonych Małpach? Stwierdza, że jeśli wystarczająco duża liczba małp losowo pisze na maszynie do pisania przez wystarczająco długi czas, jedna z nich w pewnym momencie wyprodukuje kompletne dzieła Szekspira. Tablica partycji MBR jest naprawdę mała (tylko 64 bajty), nie ma sum kontrolnych ani weryfikacji, a także bardzo gęsty format. Jest wysoce prawdopodobne, że losowy ciąg 64 bajtów wytworzy prawidłową tablicę partycji. Inne formaty tablic partycji są podobnie proste.

— Jörg W Mittag

Tak, tabela partycji ma tylko 64 bajty, (na końcu) typ partycji ma tylko 1 bajt, a wpisy muszą być zgodne z prawem lub sekwencyjne. Dlatego rozsądne jest zerowanie pierwszego klastra / sektora / 512 bajtów w MBR. Nie chcesz również nieprzewidywalnego zachowania podczas uruchamiania, mniej prawdopodobne, ale nadal stanowi ryzyko.

— mckenzm

18

Jak widać tutaj, MBR (Master Boot Record) jest stosunkowo prosty; https://en.wikipedia.org/wiki/Master_boot_record .

Kiedy używasz /dev/urandom, zawsze możesz stworzyć coś, co wygląda jak tablica partycji. Rozwiązaniem jest wypełnienie regionów tablicy partycji zerem i użycie dev/urandomdla reszty.

Linux obsługuje także inne dodatkowe formaty dysków, które mogą być potencjalnie wyzwalane, powodując wyświetlanie „nieprawidłowych” partycji podczas wypełniania losowych danych.

— Adam Waldenberg
źródło

13

To, co definiuje zbiór 512 bajtów jako główny rekord rozruchowy, to obecność wartości 0x55 0xAAna końcu. Istnieje szansa 1 na 65 536 /dev/urandomwytworzenia takiej wartości: niezbyt prawdopodobne, ale przez cały czas zdarzają się podobnie nieprawdopodobne rzeczy.

(Niektóre inne tabele partycji, takie jak Apple Partition Map , mają podobnie krótkie podpisy. Możliwe, że wygenerowałeś jedną z nich.)

— znak
źródło

3

Czy taka partycja istniała wcześniej na tym dysku? Jeśli dysk używa GPT, być może został przywrócony dodatkowy nagłówek GPT i nadal ma on starą tablicę partycji.

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

— Jakub Fojtik
źródło