Dangerous Linux commands: In what ways is one harmful while the other seems to have no effect?

Question

As many of you know, the >> operator appends the output of a command to whatever you put after it.

I know that it can be used to overwrite or add data onto files, but I also know that it can be used in a malicious way: If a drive or partition is used as the output, the command's output gets written directly to the drive, which can damage that drive or partition.

For example, from my understanding, appending >> /dev/sda to a command would append the output of the command directly onto the existing data in /dev/sda.

Out of curiosity, I set up a Ubuntu VM amd tried this for fun. This machine's virtual drive is /dev/vda, has /dev/vda1 as its boot partition, has /dev/vda2 as its root partition, and does not have a separate partition for /home.

Now here comes the fun part:

• When I ran echo "Hello world" >> /dev/vda (as root) in the VM and then restarted it, nothing seemed to have been damaged. It booted up just fine on restart and everything seemed to work afterwards.
• However, when I ran echo "Hello world" >> /dev/vda1 (also as root) in the same VM and then restarted it, it wouldn't boot.

So I already know why writing the output to vda1 was bad (it damaged the boot partition). My question is: Why does appending the output to /dev/vda not seem to do anything, but appending the output to /dev/vda1 harm it? Is it because /dev/vda2 is located "after" /dev/vda1 and so passing vda results in the command output being written to vda2?

Answer 1

I think you boot in UEFI mode. It means that the boot process does not look into the very head end of the drive.

If you boot in BIOS mode (alias CSM alias legacy mode), the very first bytes on a drive should contain the master boot record, MBR. Very close to the head is also the partition table stored.

When using >> on a block device, it does not append, instead it writes to the head of the drive. See the following demo, where /dev/sdc is a USB pendrive.

$ sudo bash -c 'echo "Hello world" >> /dev/sdc'
$ sudo dd if=/dev/sdc bs=12 count=1
Hello world
1+0 poster in
1+0 poster ut
12 byte kopierade, 0,00127171 s, 9,4 kB/s

If my description is correct, you would damage the process, if you write a longer chunk of data to the head end (long enough to overwrite the partition table and not only the MBR).

In a drive that is set set up for BIOS boot, writing to the head of the drive will damage the boot process because the MBR is damaged.

Edit 1:

Writing in the same way to the head end of a partition with a FAT32 file system shows that the file system is damaged:

$ lsblk -o model,name,size,fstype,label,mountpoint /dev/sdc
MODEL   NAME    SIZE FSTYPE LABEL MOUNTPOINT
Voyager sdc     7,5G              
        ├─sdc1  256M vfat         
        └─sdc2  512M vfat
$ sudo dd if=/dev/sdc1 bs=12 count=1
�X�mkfs.fat1+0 poster in
1+0 poster ut
12 byte kopierade, 0,00118622 s, 10,1 kB/s
$ sudo bash -c 'echo "Hello world" >> /dev/sdc1'
$ lsblk -o model,name,size,fstype,label,mountpoint /dev/sdc
MODEL   NAME    SIZE FSTYPE LABEL MOUNTPOINT
Voyager sdc     7,5G

        ├─sdc1  256M

        └─sdc2  512M vfat
$ sudo dd if=/dev/sdc1 bs=12 count=1
Hello world
1+0 poster in
1+0 poster ut
12 byte kopierade, 0,00118594 s, 10,1 kB/s

Edit 2:

Partition #2 is untouched and you may want to see the hexdump and not only the ugly representation of non-ascii characters:

$ sudo dd if=/dev/sdc2 bs=12 count=1 | hexdump -C
1+0 poster in
1+0 poster ut
12 byte kopierade, 0,00129779 s, 9,2 kB/s
00000000  eb 58 90 6d 6b 66 73 2e  66 61 74 00              |.X.mkfs.fat.|
0000000c