What is the most destroying command you can type in the Linux terminal?
What is the most destroying command you can type in the Linux terminal?
What is the most destroying command you can type in the Linux terminal?
sudo apt install microsoft-edge-stable
Look, a heretic!
I actually like Edge more than Chrome.
I don't use either, die-hard Firefox user for decades but if I'm forced to pick one...
Someone put it in AUR: https://aur.archlinux.org/packages/microsoft-edge-stable-bin
It’s also in NixOS for some sick reason: https://search.nixos.org/packages?channel=23.11&from=0&size=50&sort=relevance&type=packages&query=Microsoft
Is it really available in a Debian or Ubuntu repo?
it's in basically every distro: https://linuxiac.com/install-microsoft-edge-on-linux/
Many people have given great suggestions for the most destroying commands, but most result in an immediately borked system. While inconvenient, that doesn't have a lasting impact on users who have backups.
I propose writing a bash script set up to run daily in cron, which picks a random file in the user's home directory tree and randomizes just a few bytes of data in the file. The script doesn't immediately damage the basic OS functionality, and the data degradation is so slow that by the time the user realizes something fishy is going on a lot of their documents, media, and hopefully a few months worth of backups will have been corrupted.
Calm down there Satan.
So basically malware by a sadistic internet troll?
It'll just write a new Shakespeare play
I think we may need to implement a 128 bit unix timestamp before that will work.
Some generative AI is going to swallow this thread and burp it up later
My wife's job is to train AI to not do that. It's pretty interesting, actually.
A bad actor doesn't care what your wife does. :)
How does she accomplish it?
If you allow root privileges, there is:
sudo rm -rf --no-preserve-root /
If you want to be malicious:
sudo dd if=/dev/urandom of=/dev/sdX
or
sudo find / -exec shred -u {} \;
Let's extend a little and really do some damage
for x in /dev/(sd|nvme)*; do dd if=/dev/urandom of=$x bs=1024 & ; done
Now alias ls=
all that. And throw it in a background process. And actually return the value of ls so it doesn't look like anything nefarious is going on.
I bet you could chroot into a ram disk so you're not tearing the floor out from under you.
The victim would find this prank hilarious and everyone would like you and think you're super cool.
Don’t forget the mmc block devices too. Gotta purge those SD cards. (/dev/mmcblk*)
JFC. That's terminal.
Yes, you enter that in the terminal
🙃
sudo dd if=/dev/urandom of=/dev/sdX
sudo cp /dev/urandom /dev/nvme0n1
or
# cat /dev/urandom > /dev/nvme0n1
Way faster.
But honestly, find ~/ -type f -delete
is almost as bad.
cat bomb_threat.txt | mail tips@fbi.gov
vim
Everyone else talking about how to shred files or even the BIOS is missing a big leap, yeah. Not just destroying the computer: destroying the person in front of it! And vim is happy to provide. 😅
Emotional damage
True, just entering vim on a pc for a user who doesn't know about vim's existence is basically a prison sentence. They will literally be trapped in vim hell until they power down their PC.
I once entered vim into a computer. I couldn't exit. I tried unplugging the computer but vim persisted. I took it to the dump, where I assume vim is still running to this very day.
sudo chmod 000 -R /
is very fun way of braking your system and is not widely known 🙂
Can you recover from that?
I imagine if you can mount from a busybox possibly
chroot
in and then syncing the permissions from something like the equivalent of filesystem
package in Arch for your distro should get you going
What does this do? nobody can read any file? would sudo chmod 777 fix it at least to a usable system?
The trick is that you loose access to every file on the system. chmod
is also a file. And ls
. And sudo
. You see where it's going. System will kinda work after this command, but rebooting (which by a coincidence is a common action for "fixing" things) will reveal that system is dead.
Yep. You could run chmod again to fix it (from a different OS / rescue USB), but that would leave all the permissions in a messy state - having everything set to 777 is incredibly insecure, and will also likely break many apps/scripts that expect more restrictive permissions. So the only way to fix this properly would be to reinstall your OS/restore from backups.
How are you gonna run chmod when you don't have permissions to use it anymore?
Everyone is deleting data, but with proper backups that's not a problem. How about:
curl insert_url_here | sudo bash
This can really mess up your life.
Even if the script isn't malicious, if the internet drops out halfway the download you might end up with a "rm -r /", or similar, command.
So many things these days use that install.sh piping stuff, very bad practice.
Worst I can imagine would be something like zeroing your bios using flashrom.
Sometimes EDID eeproms are writable from i2c-dev... And sometimes VRM configuration ports too...
Mistaking if= and of= when using dd.
After all, it is known as the Dick Destroyer.
Edit: Disk Destroyer, I meant to write "Disk Destroyer"...
😂
Ouch!
Why didn't they called them from= and to= ? :(
Probably dd if=/dev/zero of=/dev/sda or whatever your system volume is
Posible to recover data, use /dev/urandom.
Only on very old hard disks, on newer disks there's no difference between overwrite patterns
With wear levelling on SSDs you may be able to recover some of the data
I did have RH Linux die while updating core libs a very long time ago. It deleted them and the system shut down. No reboot possible. I eventually (like later that day) copied a set of libs from another rh system and was able to boot and recover.
Never used rh by choice again after that.
Everyone is talking about rm -rf /
and damage to storage drives, but I read somewhere about EFI variables having something to do with bricking the computer. If this is possible, then it's a lot more damage than just disk drives.
Edit: this is interesting SE post https://superuser.com/questions/313850
Systemd mounted them r/w. https://askubuntu.com/questions/521293/an-ubuntu-command-bricked-my-system#767286
:(){:|:&};:
That 'amp;' does not belong in there, it's probably either a copy-paste error or a Lemmy-error.
What this does (or would do it it were done correctly) is define a function called ":" (the colon symbol) which recursively calls itself twice, piping the output of one instance to the input of the other, then forks the resulting mess to the background. After defining that fork bomb of a function, it is immediately called once.
It's a very old trick that existed even on some of the ancient Unix systems that predated Linux. I think there's some way of defending against using cgroups, but I don't know how from the top of my head.
It's a lemmy problem
I think however you're accessing Lemmy is rendering it wrong. I see the usual function.
AFAIR a simple ulimit will work
I think poor Lemmy is trying to help URL encode your fork bomb lol
I was going to suggest a fork bomb, but it is recovered easily. Then I thought about inserting a fork bomb into .profile
, or better, into a boot process script, like:
bash
echo ':(){:|:&};:' | sudo tee -a /bin/iptables-apply
That could be pretty nasty. But still, pretty easy to recover from, so not really "destructive."
Came here for this one. Not the most destructive, but certainly the most elegant.
"wipefs -a" instantly removes filesystem signatures. It's fast, doesn't actually delete data but is just as effective in most cases where you're not worried about someone trying to recover it. Much faster than rm on /. As far as the OS is concerned the drive is then empty.
"nvme format" is also fast.
youngsters and their tools... we just used to dd some /dev/zero onto the block device and ^C out of it after a second or two... :D
Ctrl-D
Kills the terminal instantly.
Unless ignoreeof is on
./self_destruct.sh
Assuming you have a script that triggers explosives to destroy your computer.
Reminds me of those Defcon talks where they discover it's really hard to pack a HDD killing device into a 2ru server.
That's nothing compared to:
./fire_ze_missiles.sh
whoami
It really was a feat that they were able to implement the Total Perspective Vortex in busybox.
I don't know about how exactly to do it, but I do have an idea or two.
echo b > /proc/sysrq-trigger
This will need magic SysRq compiled into the kernel, and power off/reboot enabled. The latter can be done by enabling all magic SysRq functions echo 1 > /proc/sys/kernel/sysrq
or just reboot/power off with "128". 1.- I will start with the infamous
rm-rf /
I don't think there's anything shorter or more elegant than this really. When you're right you're right.
These days the GNU rm specifically warns you and asks you to confirm before proceeding
dd
Alias ls="sudo rm -rf / > /dev/null"
would be hilarious
Is there a command that will publish your browsing history?
This is probably a start: https://askubuntu.com/questions/631631/getting-internet-browsing-history-from-shell#631637
emacs
(Runs away....)
I can't remember but having my hard drive encrypted, I believe there is a single file that messing with it would render the drive not decryptable.
The LUKS headers. If those are corrupted you can't decrypt the drive. The good news is that you can back up the headers to prevent that from happening.
Those aren't files, though, they are just some sectors on your block device. Sure, if you mess with those, your ability to decrypt your disk goes out the window, but then, when was bypassing the filesystem and messing with bits on your disk directly ever safe?
It's possible he was using an encrypted key file instead of just a password for that extra strong security. In that case, of course, if you lose that file, kiss your data good bye.
Here is the command that will render a LUKS encrypted device un recoverable
From the documentation.
5.4 How do I securely erase a LUKS container?
For LUKS, if you are in a desperate hurry, overwrite the LUKS header and key-slot area. For LUKS1 and LUKS2, just be generous and overwrite the first 100MB. A single overwrite with zeros should be enough. If you anticipate being in a desperate hurry, prepare the command beforehand. Example with /dev/sde1 as the LUKS partition and default parameters:
head -c 100000000 /dev/zero > /dev/sde1; sync
Dd is known as disk destroyer for a good reason. Very easy to fuck yourself over.
smbios-token-ctl pick one of the "dangerous - permanent write once" tokens
sudo apt install gnome
That wouldn't work on my system.
Typing apt just opens the man page for pacman.
btw
sudo apt remove ratpoison
undefined
alias cp="rm -rf"
bonus points for putting it into the shells RC file.
Not as destructive as deleting root, but a lot more sneakier
dd if=/dev/urandom of=/dev/sdx
will overwrite every single byte of /dev/sdx with random data. Replace /dev/sdx with the drive you want to wipe. Optionally, specify a larger block size to speed it up more.
Noted
Sudo pacman -Syu
shutdown -h now
Sucks when the host is remote and you do a -h instead if a -r
sudo apt-get install factorio
Good luck recovering from that one
hdparm --yes-i-know-what-i-am-doing --sanitize-crypto-scramble /dev/sda
Modern disks have encryption enabled in disk level. This will change the encryption key on the disk, meaning that in seconds all data in the disk is in unrecoverable state.
This is way better than writing the whole disk 0's or rm -fr /
been there and done rm -rf as root
Why?
because I wanted to delete something? It was probably 23 odd years ago
I was a newbie user, telling a friend of mine about rm -rf /*
. I typed it in a hit Enter, telling him it doesn't harm since I didn't enter sudo
. But I'd forgotten that I have still permission to delete my home directory. 🥲😂
I'd imagine rm
has easily caused the most destruction.
tar czf /dev/sda /home
dd if=/dev/random of=/dev/sda
Wipes the entire disk and replaced it with random data.
./fire_nukes.sh
Destructive for me or for others?
for the terminal's operating system
If you have to ask, you're not ready to know.
sudo panman -Syu
with a caveat: just read the news feed
real arch linux user would know to have a rescue live usb handy in the event the system becomes unbootable.