Why does writing random data using dd result in disk partitions?

Question

Prior to running the dd command, the command lsblk returned the output below:

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

The command dd if=/dev/urandom of=/dev/sda conv=fsync status=progress is run. The device however loses power and shuts down. When power is reinstated, the command lsblk returns the following 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

Answer 1

Several possibilities:

• Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].

• Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.

• The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.

• ...

(*) Make 1000 files with random data in them and see what comes out:

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

The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.

It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.

There's also a dedicated utility (wipefs) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.

Answer 2

As seen here, the MBR (Master Boot Record) is relatively simple; https://en.wikipedia.org/wiki/Master_boot_record.

When you use /dev/urandom you can always create something that looks like a partition table. The solution is to fill the partition table regions with zero and use dev/urandom for the rest.

Linux also supports other additional disk formats that can also potentially be triggered, causing "invalid" partitions to show up when filling with random data.

Answer 3

The thing that defines a collection of 512 bytes as being a Master Boot Record is the presence of the values 0x55 0xAA at the end. There's a 1-in-65,536 chance of /dev/urandom producing such a value: not too likely, but similarly improbable things happen all the time.

(Some other partition tables, such as the Apple Partition Map, have similarly short signatures. It's possible you've generated one of them instead.)

Answer 4

Was such partition present some time before on that disk? If the disk uses GPT, maybe the Secondary GPT Header got restored and it still had the old partition table.

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