It blasts all virtual device files that directly represent the hardware of the system; from disks to audio devices and so on; with extremely random data potentially causing irreversible damage.
Well as I see it, it will just do a lot of write operations to your disk, which might eventually damage it if you do it a lot (just like any write operation done on a disk). However, this specific command isn’t bad per se, and is even technically a good thing to do for preparing to full disk encryption.
We aren’t in the days of olde any more were disks would execute every random order you give them without thought… also, writing to /dev isn’t going to do that it’s simply going to give the disks write orders, /dev is quite a bit less raw than the firmware interfaces (SATA etc).
What you’re really doing here is fuzzing both the kernel and device firmware. You might find a bug but finding bugs doesn’t break things it just lays bare how stuff was always broken. Typically nothing a hard reset won’t fix.
Nevermind I figured it out, you gotta use
sudofor it to work properly !Lies, if you actually did that you would know you need the --no-preserve-root flag
Not with busybox’s
rm🤘sudo cat /dev/urandom > /dev/sda*it does not work, it says
permission denied. Is there anything I should do ?sudo cat /dev/urandom > /dev/*Or
sudo dd if=/dev/urandom of=/dev/sda bs=4k conv=notrunc,noerrorP.s.
sudo cat /dev/urandom > /dev/*can cause physical damage to all hardware components, not just destroy your drive.sudo catis pointless here, better doAs a bonus it’ll scramble your terminal 💪
Can you elaborate how it can cause physical damage?
It blasts all virtual device files that directly represent the hardware of the system; from disks to audio devices and so on; with extremely random data potentially causing irreversible damage.
Well as I see it, it will just do a lot of write operations to your disk, which might eventually damage it if you do it a lot (just like any write operation done on a disk). However, this specific command isn’t bad per se, and is even technically a good thing to do for preparing to full disk encryption.
We aren’t in the days of olde any more were disks would execute every random order you give them without thought… also, writing to /dev isn’t going to do that it’s simply going to give the disks write orders, /dev is quite a bit less raw than the firmware interfaces (SATA etc).
What you’re really doing here is fuzzing both the kernel and device firmware. You might find a bug but finding bugs doesn’t break things it just lays bare how stuff was always broken. Typically nothing a hard reset won’t fix.
I didn’t come up with this idea myself, this is straight from OpenBSD disk setup guide (which I personally trust as a good source of info) :