Sudo is for getting the necessary perms to write the data to the location after the > operator. Cat is just super fast, faster than dd infact as it’s not actually intended to write to disks, only to stout. We want as much speed as possible to do as much damage as possible by increasing our chances of trigging bugs.
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.
Yeah if that triggers a bug then the kernel or drive is barely functioning, neither of the two should care what data you write and it’s getting tested all the time as compressed data is indistinguishable from random data.
You could certainly confuse something in /dev that takes actual commands, but say spinning fans randomly won’t do much, and neither crashing the fan controller the firmware will still shut the system down before it melts itself.
But if you have, dunno, an old plotter hooked up to /dev/lp0 and it’s directly interpreting every random number on there as a movement command you might overheat the mechanism and set it on fire.
/dev/urandom provides an unlimited stream of random data, the output is based on truly random data and doesn’t block regardless if the entropy pool is depleted.
It’s not the same as /dev/random which only returns random numbers from the entropy pool at a limited rate and can block if the entropy pool is deplete.
By using /dev/urandom and cat we’re blasting random data at much faster speeds then what /dev/random & dd are capable of which increases our chances of triggering a bug by quite a bit.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
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 drives data.sudo catis pointless here, better doAs a bonus it’ll scramble your terminal 💪
Sudo is for getting the necessary perms to write the data to the location after the
>operator. Cat is just super fast, faster than dd infact as it’s not actually intended to write to disks, only to stout. We want as much speed as possible to do as much damage as possible by increasing our chances of trigging bugs.Can you elaborate how it can cause physical 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) :
Yeah if that triggers a bug then the kernel or drive is barely functioning, neither of the two should care what data you write and it’s getting tested all the time as compressed data is indistinguishable from random data.
You could certainly confuse something in /dev that takes actual commands, but say spinning fans randomly won’t do much, and neither crashing the fan controller the firmware will still shut the system down before it melts itself.
But if you have, dunno, an old plotter hooked up to /dev/lp0 and it’s directly interpreting every random number on there as a movement command you might overheat the mechanism and set it on fire.
/dev/urandom provides an unlimited stream of random data, the output is based on truly random data and doesn’t block regardless if the entropy pool is depleted.
It’s not the same as /dev/random which only returns random numbers from the entropy pool at a limited rate and can block if the entropy pool is deplete.
By using /dev/urandom and cat we’re blasting random data at much faster speeds then what /dev/random & dd are capable of which increases our chances of triggering a bug by quite a bit.
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.