Perché scrivere dati casuali usando dd provoca partizioni del disco?

11

Prima di eseguire il ddcomando, il comando ha lsblkrestituito l'output seguente:

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

Il comando dd if=/dev/urandom of=/dev/sda conv=fsync status=progressè eseguito. Il dispositivo tuttavia perde potenza e si spegne. Quando viene ripristinata l'alimentazione, il comando lsblkrestituisce il seguente output:

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

— Motivata
fonte

@RuiFRibeiro - Grazie per l'analogia, tuttavia non è chiaro il motivo per cui ddsi tradurrebbe in partizioni soprattutto se il comando è destinato a cancellare i dischi?

— Motivato il

1

Coincidenza: è molto improbabile che sia correlato alla mancanza di corrente. Scrivi dati casuali sul dispositivo. Alcuni di questi dati casuali sono andati ai primi blocchi, qui vivono le tabelle delle partizioni. Probabilmente hai finito per definire una partizione.

— ctrl-alt-delor

puoi pubblicare il risultato di file /dev/sda*e sudo fdisk -l /dev/sda*?

— phuclv

@phuclv - Come ho iniziato il processo, l'output sarà ancora prezioso?

— Motivato il

1

@Motivated Nota che lo ddscopo non è di per sé cancellare i dischi. La scrittura di dati casuali su un disco può produrre risultati casuali.

— Jjmontes,

20

Diverse possibilità:

Linux supporta molti tipi diversi di tabelle delle partizioni, alcune delle quali utilizzano pochissimi byte magici, quindi è facile identificare erroneamente i dati casuali (*) [quindi è possibile generare in modo casuale una tabella delle partizioni un po '"valida"].
Alcuni tipi di tabella delle partizioni dispongono anche di backup alla fine del disco (in particolare GPT) e che potrebbero essere rilevati se l'avvio dell'unità è stato sostituito con immondizia casuale.
Il dispositivo non funziona correttamente ed è stato disconnesso prima di aver finito di scrivere i dati o continua a restituire vecchi dati, quindi la tabella delle partizioni sopravvive. A volte questo accade con le chiavette USB.
...

(*) Crea 1000 file con dati casuali al loro interno e guarda cosa viene fuori:

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

L'obiettivo della distruzione casuale di un'unità è far sparire definitivamente i vecchi dati. Non vi è alcuna promessa che l'unità apparirà vuota, non utilizzata, in condizioni perfette in seguito.

È comune seguire con una cancellazione zero per raggiungere questo obiettivo. Se si utilizza LVM, è normale che LVM azzeri i primi settori di qualsiasi LV creato in modo che i vecchi dati non interferiscano.

C'è anche un'utilità dedicata ( wipefs) per sbarazzarsi delle vecchie firme dei byte magici che puoi usare per sbarazzarti dei file system e dei metadati della tabella delle partizioni.

— frostschutz
fonte

I dispositivi erano stati precedentemente cancellati utilizzando il comando ATA Secure Erase. Presumo che ciò eliminerebbe i dati in modo che 1. sia irrecuperabile 2. non sopravvivano informazioni sulla partizione. Se questo è vero, intendi dire che quando si esegue il ddcomando, la generazione di dati casuali quando interrotta può provocare dati che sembrano tabelle di partizione? Anche questi sono dischi rigidi SATA (non SSD).

— Motivato il

5

I dati casuali possono sembrare qualsiasi cosa. Questo è ciò che significa essere casuali. Conosci il teorema delle scimmie infinite? Afferma che se una quantità sufficiente di scimmie digita casualmente sulle macchine da scrivere per un tempo sufficientemente lungo, una di esse in un punto o in un altro produrrà le opere complete di Shakespeare. Una tabella delle partizioni MBR è veramente piccola (solo 64 byte), non ha checksum o verifica e un formato molto denso. È molto probabile che una stringa casuale di 64 byte produca una tabella delle partizioni valida. Altri formati di tabella delle partizioni sono altrettanto semplici.

— Jörg W Mittag,

Sì, la tabella delle partizioni ha solo 64 byte, (alla fine) il tipo di partizione è solo 1 byte e le voci devono essere lecite o sequenziali. Quindi è ragionevole azzerare il primo cluster / settore / 512 byte su MBR. Inoltre, non si desidera un comportamento di avvio imprevedibile, meno probabile, ma comunque un rischio.

— mckenzm,

18

Come visto qui, l'MBR (Master Boot Record) è relativamente semplice; https://en.wikipedia.org/wiki/Master_boot_record .

Quando lo usi /dev/urandompuoi sempre creare qualcosa che assomigli a una tabella delle partizioni. La soluzione è riempire di zero le aree della tabella delle partizioni e utilizzarle dev/urandomper il resto.

Linux supporta anche altri formati di disco aggiuntivi che possono anche essere potenzialmente attivati, causando la visualizzazione di partizioni "non valide" durante il riempimento con dati casuali.

— Adam Waldenberg
fonte

13

La cosa che definisce una raccolta di 512 byte come un Master Boot Record è la presenza dei valori 0x55 0xAAalla fine. Esiste una possibilità 1 su 65.536 di /dev/urandomprodurre un tale valore: non troppo probabilmente, ma cose altrettanto improbabili accadono continuamente.

(Alcune altre tabelle delle partizioni, come la mappa delle partizioni Apple , hanno firme altrettanto brevi. È possibile che tu ne abbia generato una.

— marchio
fonte

3

Tale partizione era presente qualche tempo prima su quel disco? Se il disco utilizza GPT, forse l'intestazione GPT secondaria è stata ripristinata e aveva ancora la vecchia tabella delle partizioni.

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

— Jakub Fojtik
fonte