Por que gravar dados aleatórios usando dd resulta em partições de disco?

11

Antes de executar o ddcomando, o comando lsblkretornou a saída abaixo:

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

O comando dd if=/dev/urandom of=/dev/sda conv=fsync status=progressé executado. O dispositivo, no entanto, perde energia e desliga. Quando a energia é restabelecida, o comando lsblkretorna a seguinte saída:

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
fonte

@RuiFRibeiro - Obrigado pela analogia, no entanto, não está claro por ddque resultaria em partições, especialmente se o comando se destina a limpar discos?

— Motivado

1

Coincidência: é muito improvável que esteja relacionado ao corte de energia. Você grava dados aleatórios no dispositivo. Alguns desses dados aleatórios foram para os primeiros blocos, é aqui que as tabelas de partição ficam. Você provavelmente acabou definindo uma partição.

— CTRL-ALT-DELOR

você pode postar o resultado de file /dev/sda*e sudo fdisk -l /dev/sda*?

— Phuclv

@phuclv - Como eu comecei o processo, a saída ainda será valiosa?

— Motivado

1

@Motivated Observe que o ddobjetivo não é propriamente o de limpar discos. A gravação de dados aleatórios em um disco pode produzir resultados aleatórios.

— jjmontes

20

Várias possibilidades:

O Linux suporta muitos tipos diferentes de tabela de partição, alguns dos quais usam muito poucos bytes mágicos, e é fácil identificar dados aleatórios (*) [para que seja possível gerar aleatoriamente uma tabela de partição um tanto "válida"].
Alguns tipos de tabela de partição também têm backups no final do disco (principalmente a GPT), que podem ser ativados se o início da unidade for substituído por lixo aleatório.
O dispositivo não funciona corretamente e foi desconectado antes de terminar de gravar os dados ou continua retornando dados antigos, para que a tabela de partição sobreviva. Às vezes isso acontece com pen drives.
...

(*) Crie 1000 arquivos com dados aleatórios e veja o que sai:

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

O objetivo de destruir aleatoriamente uma unidade é fazer com que os dados antigos desapareçam para sempre. Não há promessa de que a unidade aparecerá vazia, sem uso e em perfeito estado depois.

É comum seguir com uma limpeza zero para conseguir isso. Se você estiver usando o LVM, é normal o LVM zerar os primeiros setores de qualquer LV criado para que os dados antigos não interfiram.

Há também um utilitário dedicado ( wipefs) para livrar-se de assinaturas antigas de bytes mágicos que você pode usar para se livrar dos metadados do sistema de arquivos e da tabela de partição.

— frostschutz
fonte

Os dispositivos foram apagados anteriormente usando o comando ATA Secure Erase. Suponho que isso remova dados de modo que 1. seja irrecuperável 2. nenhuma informação de partição sobreviva. Se isso for verdade, você quer dizer que, ao executar o ddcomando, a geração de dados aleatórios quando interrompidos pode resultar em dados que parecem tabelas de partição? Também são discos rígidos SATA (não SSD).

— Motivado

5

Dados aleatórios podem parecer com qualquer coisa. É isso que significa ser aleatório. Você conhece o teorema dos macacos infinitos? Ele afirma que, se uma quantidade grande e suficiente de macacos digitar aleatoriamente em máquinas de escrever por um tempo suficiente, um deles, em algum momento ou outro, produzirá as obras completas de Shakespeare. Uma tabela de partição MBR é realmente pequena (apenas 64 bytes), não possui somas de verificação ou verificação e um formato muito denso. É altamente provável que uma sequência aleatória de 64 bytes produza uma tabela de partição válida. Outros formatos de tabela de partição são igualmente simples.

— Jörg W Mittag

Sim, a tabela de partição tem apenas 64 bytes, (no final) o tipo de partição tem apenas 1 byte e as entradas precisam ser legais ou seqüenciais. Portanto, é sensato zerar o primeiro cluster / setor / 512 bytes no MBR. Você também não deseja um comportamento de inicialização imprevisível, menos provável, mas ainda assim um risco.

— Mckenzm

18

Como visto aqui, o MBR (Master Boot Record) é relativamente simples; https://en.wikipedia.org/wiki/Master_boot_record .

Ao usar, /dev/urandomvocê sempre pode criar algo que se parece com uma tabela de partição. A solução é preencher as regiões da tabela de partição com zero e usar dev/urandompara o resto.

O Linux também suporta outros formatos de disco adicionais que também podem ser potencialmente acionados, fazendo com que partições "inválidas" sejam exibidas ao preencher dados aleatórios.

— Adam Waldenberg
fonte

13

O que define uma coleção de 512 bytes como sendo um registro mestre de inicialização é a presença dos valores 0x55 0xAAno final. Há uma chance de 1 em 65.536 de /dev/urandomproduzir esse valor: não muito provável, mas coisas igualmente improváveis acontecem o tempo todo.

(Algumas outras tabelas de partição, como o Apple Partition Map , têm assinaturas igualmente curtas. É possível que você tenha gerado uma delas.)

— Marca
fonte

3

Essa partição estava presente algum tempo antes nesse disco? Se o disco usa GPT, talvez o cabeçalho GPT secundário tenha sido restaurado e ainda tenha a tabela de partições antiga.

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

— Jakub Fojtik
fonte