Yes I tested it but replaced the destruction command with another command and it works as expected. You can remove it, it was just for the laughs.
I wish there was a forum specifically for posting viruses f33's, comes pretty close! Not for financial/black-hat reasons but for creating visible havock on virtual machines or empty computers, i've seen a couple of youtube videos which contain that...I kinda want to remove that script - but you DID warn 'em.
Note: New users, do not run the script in this post:
Also, I wonder if @f33dm3bits tested the script before sharing it?
I also tested the script with the desctruct command in a vm and it works as expected there as well, causing my vm's installation to be destroyed.I kinda want to remove that script - but you DID warn 'em.
Note: New users, do not run the script in this post:
Also, I wonder if @f33dm3bits tested the script before sharing it?
I also tested the script with the desctruct command in a vm and it works as expected there as well, causing my vm's installation to be destroyed.
alias organize='find <top-folder> -maxdepth <number> -mindepth <number> -type d -exec cp -r {} <destination> \;'
find
here is configured to take folders from an exact depth, and then those folders are given to cp
and put into a more favorable place (use the same number for maxdepth and mindepth to specify an exact depth). I'm so happy that i actually figured out how to use the -exec
option today!Nice script. Try using rsync. It will preserve the date and time stamps and much much more. That, and if your into learning, it's a worm hole all it's own. It has over 100 options and can be used to transfer/copy to/from folder to folder and to and from other hosts. It could be used to replicate important data / folders etc.. from your machine to a backup computer for safe keeping.alias organize='find <top-folder> -maxdepth <number> -mindepth <number> -type d -exec cp -r {} <destination> \;'
find /util -maxdepth 0 -mindepth 0 -type d -exec rsync -avn {} /tmp/output/ \;
Yeah rsync is a powrrful tool but i'm generally confused about practical ways to use it, the normal copy command is very easy to understand but i do want to have a better grasp of rsync.Nice script. Try using rsync. It will preserve the date and time stamps and much much more. That, and if your into learning, it's a worm hole all it's own. It has over 100 options and can be used to transfer/copy to/from folder to folder and to and from other hosts. It could be used to replicate important data / folders etc.. from your machine to a backup computer for safe keeping.
Something like this.
Code:find /util -maxdepth 0 -mindepth 0 -type d -exec rsync -avn {} /tmp/output/ \;
The n in avn is for a dry run. You can test your code and never write a byte. Remove the n to run it. The a = archive v = verbose (tells you what files are being copied & more)
Just a thought.
Fork bomb is a pretty great system-destroyer...i tested it on an ubuntu VM today (live without install), and it took about 30 minutes before it made the system run so badly that i had to power off the machine. I think that's neat because not only could i keep entering {icode]free[/icode] to check on how much virtual RAM was getting used up, but it could also theoretically be used for "evil" purposes since it's kinda slow:Look up 'fork bomb', if you want some good old fashioned terminal fun.
:(){ :|:& };:
It might have been 15-20 minutes (never over-estimate my conception of time...) but i was happy that it was slow enough that i could keep running the "free" command to see the progress it was making. RIght off the bat, it was using less than 4GB of 8GB total RAM...it slowly made it's way up to 5GB, and then slowly made its way to giving me just a black screen that i couldn't click back into existence.A word of caution... Do not run the above command unless you know what to expect. It's an amusing academic exercise that won't really break anything, but it will force a reboot.
That said, I wonder what made it take 30 minutes. It's usually much faster.
There are some great obfuscated fork bombs out there in like Perl.
It could, theoretically, if you force the computer and that causes the needle to scratch the platter on an HDD...but other than that it shouldn't hard the integrity of files.Oh, it shouldn't actually harm your data - not that one I don't think, even on real hardware.
#!/bin/bash
FNAME=<insert-absolute-directory-path-to-new-filename-in-desktop>
if [ -e $FNAME ]; then
echo -e "\n\nOkay I know i wasn't very specific, but I'm in your bathroom! Explain yourself!" >> $FNAME
else
echo -e "Dear Desktop User,\n I know about some things you did a very long time ago, and i also know about some other stuff too.\nGive me a million dollar by 5pm eastern standard time or else there's gonna be some problems dude!" >> $FNAME
fi
#!/bin/bash
#this will look through every file in a working directory and
#find the text files that contain a string
echo -e "Enter string you want to find in your files. This script only searches files"
read -p "in your working directory: " term
echo -e "\nUN-HIDDEN FILES\n"
FILES="$(grep -lIs "$term" *)"
#options mean show files containing text of file, omit binary files,
#omit error messages.
#file takes grep output to display their type,
#then sed removes error messages when files have spaces
file $FILES | sed '/No such file or directory/d'
FILESH="$(grep -lIs "$term" .*)"
echo -e "\nHIDDEN FILES\n"
file $FILESH | sed '/No such file or directory/d'
echo -e "\nFind and grep can't process these files because they have spaces in them:\n"
#sed removes directories and their listings
ls *' '* | sed -n '/:$/q;p'
31 minutes ago, i decided to try the forkbomb just on my desktop, and it's actually progressing a lot slower than it did on the virtual machine. This is the RAM readout right after i started it:Oh, it shouldn't actually harm your data - not that one I don't think, even on real hardware. I wonder if the VM has something to do with it taking that long. The last time I ran it on a real computer it was that same command and it killed it pretty quickly. It wouldn't surprise me too much if it behaved differently on virtualized hardware. The VM's software may even try to prevent things like that.
Anyhow, we probably shouldn't veer too far from the topic in this thread, so I'll stop gabbing like an old lady across the fence.
total used free shared buff/cache available
Mem: 15655348 8727412 4671728 20020 2256208 6586500
Swap: 2097148 0 2097148
total used free shared buff/cache available
Mem: 15655348 9170860 4127876 57216 2356612 6096892
Swap: 2097148 0 2097148
31 minutes ago, i decided to try the forkbomb just on my desktop, and it's actually progressing a lot slower than it did on the virtual machine.
Yeah, i was thinking it was either because Ubuntu has more built in defenses, or maybe it once again has something to do with hardware...funny how that happens a lot with computers.I wonder if there's now some in-built defenses against it?
Maybe try one of the many other fork bombs out there, if you're curious.
#trillions
s/\([0-9]\)\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3,\4,\5/g
#hundred billions
s/\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3,\4/g
#ten billions
s/\([0-9]\{2\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3,\4/g
#billions
s/\([0-9]\)\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3,\4/g
#hundred millions
s/\([0-9]\{3\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3/g
#ten millions
s/\([0-9]\{2\}\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3/g
#millions
s/\([0-9]\)\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2,\3/g
#hundred thousands
s/\([0-9]\{3\}\)\([0-9]\{3\}\)/\1,\2/g
#ten thousands
s/\([0-9]\{2\}\)\([0-9]\{3\}\)/\1,\2/g
#one thousands
s/\([0-9]\)\([0-9]\{3\}\)/\1,\2/g
xarathustra@xarathustra:~$ df | sed -f easy-numbers.sed
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1,565,544 3,292 1,562,252 1% /run
/dev/nvme0n1p2 805,437,640 421,062,300 343,387,900 56% /
tmpfs 7,827,708 23,812 7,803,896 1% /dev/shm
tmpfs 5,120 4 5,116 1% /run/lock
/dev/nvme0n1p1 523,248 5,364 517,884 2% /boot/efi
tmpfs 1,565,540 148 1,565,392 1% /run/user/1,000
/dev/nvme0n1p4 1,093,885,756 5,293,096 1,032,952,596 1% /media/xarathustra/4f763,174-e291-489a-9b8d-e418f7b70fa1
/dev/nvme0n1p3 19,982,160 15,252,016 3,689,760 81% /media/xarathustra/9d485,139-229e-4f36-ade2-d
df
program, so you would need some code from awk to make this look neater...but my script does work to accomplish its intention.