Mengapa menulis data acak menggunakan dd menghasilkan partisi disk?

11

Sebelum menjalankan ddperintah, perintah lsblkmengembalikan output di bawah:

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

Perintah dd if=/dev/urandom of=/dev/sda conv=fsync status=progressitu dijalankan. Namun perangkat kehilangan daya dan dimatikan. Ketika daya diaktifkan kembali, perintah lsblkmengembalikan output berikut:

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

— Termotivasi
sumber

@RuiFRibeiro - Terima kasih untuk analoginya namun tidak jelas mengapa ddakan menghasilkan partisi terutama jika perintah tersebut dimaksudkan untuk menghapus disk?

— Termotivasi

1

Kebetulan: sangat tidak mungkin terkait dengan pemadaman listrik. Anda menulis data acak ke perangkat. Beberapa data acak ini pergi ke beberapa blok pertama, ini adalah tempat tabel partisi hidup. Anda mungkin akhirnya mendefinisikan partisi.

— ctrl-alt-delor

dapatkah Anda memposting hasil dari file /dev/sda*dan sudo fdisk -l /dev/sda*?

— phuclv

@ phuclv - Karena saya sudah memulai prosesnya, apakah hasilnya akan tetap berharga?

— Termotivasi

1

@Motivated Perhatikan bahwa ddtujuan itu bukan untuk menghapus disk. Menulis data acak ke disk dapat menghasilkan hasil acak.

— jjmontes

20

Beberapa kemungkinan:

Linux mendukung banyak jenis tabel partisi yang berbeda, beberapa di antaranya menggunakan sangat sedikit byte ajaib, dan kemudian mudah untuk salah mengidentifikasi data acak (*) [sehingga dimungkinkan untuk secara acak menghasilkan tabel partisi yang agak "valid"].
Beberapa tipe tabel partisi memiliki cadangan di akhir disk juga (terutama GPT) dan itu bisa diambil jika awal drive diganti dengan sampah acak.
Perangkat tidak berfungsi dengan baik dan terputus sebelum selesai menulis data, atau terus mengembalikan data lama, sehingga tabel partisi bertahan. Terkadang ini terjadi dengan stik USB.
...

(*) Buat 1000 file dengan data acak di dalamnya dan lihat apa yang keluar:

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

Tujuan dari merobek-robek drive secara acak adalah membuat data lama hilang selamanya. Tidak ada janji drive akan tampak kosong, tidak digunakan, dalam kondisi bersih sesudahnya.

Adalah umum untuk menindaklanjuti dengan penghapusan nol untuk mencapai itu. Jika Anda menggunakan LVM, itu normal untuk LVM untuk nol sektor pertama dari setiap LV yang Anda buat sehingga data lama tidak akan mengganggu.

Ada juga utilitas khusus ( wipefs) untuk menyingkirkan tanda tangan byte sulap yang dapat Anda gunakan untuk menyingkirkan filesystem dan tabel partisi metadata.

— frostschutz
sumber

Perangkat sebelumnya telah dihapus menggunakan perintah ATA Secure Erase. Saya berasumsi bahwa ini akan menghapus data sehingga 1. tidak dapat dipulihkan 2. tidak ada informasi partisi yang bertahan. Jika ini benar, apakah Anda bermaksud mengatakan bahwa ketika menjalankan ddperintah, pembuatan data acak ketika terganggu dapat menghasilkan data yang tampak seperti tabel partisi? Juga ini adalah hard disk SATA (non-SSD).

— Termotivasi

5

Data acak dapat terlihat seperti apa saja. Itulah artinya menjadi acak. Apakah Anda akrab dengan Teorema Infinite Monkeys? Ini menyatakan bahwa jika sejumlah besar monyet mengetik secara acak pada mesin tik untuk waktu yang cukup lama, salah satu dari mereka akan menghasilkan karya lengkap Shakespeare. Tabel partisi MBR sangat kecil (hanya 64 byte), tidak memiliki checksum atau verifikasi, dan format yang sangat padat. Sangat mungkin bahwa string acak 64 byte akan menghasilkan tabel partisi yang valid. Format tabel partisi lainnya juga sederhana.

— Jörg W Mittag

Ya tabel partisi hanya 64 byte, (pada akhirnya) tipe partisi hanya 1 byte, dan entri harus sah atau berurutan. Jadi memusatkan byte / sektor / 512 bye pertama pada MBR masuk akal. Anda juga tidak ingin perilaku boot yang tidak terduga, kecil kemungkinannya, tetapi masih berisiko.

— mckenzm

18

Seperti yang terlihat di sini, MBR (Master Boot Record) relatif sederhana; https://en.wikipedia.org/wiki/Master_boot_record .

Saat Anda menggunakan, /dev/urandomAnda selalu dapat membuat sesuatu yang tampak seperti tabel partisi. Solusinya adalah mengisi daerah tabel partisi dengan nol dan gunakan dev/urandomsisanya.

Linux juga mendukung format disk tambahan lain yang juga berpotensi dipicu, menyebabkan partisi "tidak valid" muncul ketika mengisi dengan data acak.

— Adam Waldenberg
sumber

13

Hal yang mendefinisikan koleksi 512 byte sebagai Master Boot Record adalah keberadaan nilai-nilai 0x55 0xAAdi akhir. Ada kemungkinan 1-in-65.536 /dev/urandommenghasilkan nilai seperti itu: tidak terlalu mungkin, tetapi hal-hal yang sama mustahil terjadi sepanjang waktu.

(Beberapa tabel partisi lain, seperti Peta Partisi Apple , memiliki tanda tangan pendek yang serupa. Mungkin Anda malah membuat salah satunya.)

— Menandai
sumber

3

Apakah partisi seperti itu ada beberapa waktu sebelumnya pada disk itu? Jika disk menggunakan GPT, mungkin Header GPT Sekunder dipulihkan dan masih memiliki tabel partisi lama.

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

— Jakub Fojtik
sumber