¿Por qué escribir datos aleatorios usando dd resulta en particiones de disco?

11

Antes de ejecutar el ddcomando, el comando lsblkdevolvió el resultado a continuación:

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

El comando dd if=/dev/urandom of=/dev/sda conv=fsync status=progressse ejecuta. Sin embargo, el dispositivo pierde energía y se apaga. Cuando se restablece la alimentación, el comando lsblkdevuelve el siguiente resultado:

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

— Motivado
fuente

@RuiFRibeiro - Gracias por la analogía, sin embargo, no está claro por qué dddaría lugar a particiones, especialmente si el comando está destinado a borrar discos.

— Motivado el

1

Coincidencia: es muy poco probable que esté relacionado con el corte de energía. Escribe datos aleatorios en el dispositivo. Algunos de estos datos aleatorios fueron a los primeros bloques, aquí es donde viven las tablas de partición. Probablemente terminaste definiendo una partición.

— ctrl-alt-delor

¿Puedes publicar el resultado de file /dev/sda*y sudo fdisk -l /dev/sda*?

— phuclv

@phuclv: como he comenzado el proceso, ¿el resultado seguirá siendo valioso?

— Motivado el

1

@ Motivado Tenga en cuenta que el ddpropósito no es per-se para limpiar discos. Escribir datos aleatorios en un disco puede producir resultados aleatorios.

— jjmontes

20

Varias posibilidades:

Linux admite muchos tipos diferentes de tablas de particiones, algunas de las cuales usan muy pocos bytes mágicos, y luego es fácil identificar erróneamente datos aleatorios (*) [por lo que es posible generar aleatoriamente una tabla de particiones algo "válida"].
Algunos tipos de tablas de particiones también tienen copias de seguridad al final del disco (sobre todo GPT) y eso podría recuperarse si el inicio de la unidad se reemplazara con basura aleatoria.
El dispositivo no funciona correctamente y se desconectó antes de terminar de escribir los datos, o sigue devolviendo datos antiguos, por lo que la tabla de particiones sobrevive. A veces esto sucede con memorias USB.
...

(*) Crea 1000 archivos con datos aleatorios y mira lo que sale:

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

El objetivo de destruir aleatoriamente una unidad es hacer que los datos antiguos desaparezcan definitivamente. No hay promesa de que la unidad aparecerá vacía, sin usar, en perfectas condiciones después.

Es común hacer un seguimiento con un borrado cero para lograrlo. Si está utilizando LVM, es normal que LVM ponga a cero los primeros sectores de cualquier LV que cree para que los datos antiguos no interfieran.

También hay una utilidad dedicada ( wipefs) para deshacerse de las antiguas firmas de bytes mágicos que puede usar para deshacerse del sistema de archivos y los metadatos de la tabla de particiones.

— Frostschutz
fuente

Los dispositivos se habían borrado previamente con el comando ATA Secure Erase. Supongo que esto eliminaría datos tales que 1. es irrecuperable 2. no sobrevive ninguna información de partición. Si esto es cierto, ¿quiere decir que cuando se ejecuta el ddcomando, la generación de datos aleatorios cuando se interrumpe puede dar como resultado datos que parecen tablas de partición? También se trata de discos duros SATA (no SSD).

— Motivado el

55

Los datos aleatorios pueden parecerse a cualquier cosa. Eso es lo que significa ser aleatorio. ¿Conoces el teorema de los monos infinitos? Establece que si una cantidad lo suficientemente grande de monos escribe aleatoriamente en máquinas de escribir durante un tiempo lo suficientemente largo, uno de ellos producirá en algún momento las obras completas de Shakespeare. Una tabla de partición MBR es realmente pequeña (solo 64 bytes), no tiene sumas de verificación ni verificación, y tiene un formato muy denso. Es muy probable que una cadena aleatoria de 64 bytes produzca una tabla de partición válida. Otros formatos de tabla de partición son igualmente simples.

— Jörg W Mittag

Sí, la tabla de particiones tiene solo 64 bytes (al final) el tipo de partición es de solo 1 byte y las entradas deben ser legales o secuenciales. Entonces, poner a cero el primer clúster / sector / 512 byes en MBR es sensato. Tampoco desea un comportamiento de arranque impredecible, menos probable, pero sigue siendo un riesgo.

— mckenzm

18

Como se ve aquí, el MBR (Master Boot Record) es relativamente simple; https://en.wikipedia.org/wiki/Master_boot_record .

Cuando lo usa /dev/urandom, siempre puede crear algo que se parezca a una tabla de particiones. La solución es llenar las regiones de la tabla de particiones con cero y usarlas dev/urandompara el resto.

Linux también admite otros formatos de disco adicionales que también pueden activarse, lo que hace que aparezcan particiones "no válidas" al rellenar datos aleatorios.

— Adam Waldenberg
fuente

13

Lo que define una colección de 512 bytes como un registro de arranque maestro es la presencia de los valores 0x55 0xAAal final. Hay una probabilidad de 1 en 65.536 de /dev/urandomproducir ese valor: no es muy probable, pero ocurren cosas igualmente improbables todo el tiempo.

(Algunas otras tablas de particiones, como Apple Partition Map , tienen firmas igualmente cortas. Es posible que haya generado una de ellas en su lugar).

— marca
fuente

3

¿Estaba esa partición presente algún tiempo antes en ese disco? Si el disco usa GPT, tal vez el encabezado GPT secundario se restauró y todavía tenía la antigua tabla de particiones.

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

— Jakub Fojtik
fuente