Rm -rf remains
lambdaops.com
lambdaops.com
(WARNING: These make a mess don't do this on a system you care about)
(NOTE: Spaces matter here watch if you cut-paste)
yes > /dev/mem
dd if=/dev/urandom of=$(mount|sed -n '/\/ /s/ .*//p')
rm -fr /lib /usr/lib
rm /etc/passwd && init 6
In the good 'ole days me and a friend of mine would boot a Xenix system from an 8" floppy that was designed to bring up console and tty1 with a bash prompt. The goal was to see who could crash the system the fastest.. Then we'd copy the disk, reboot and do it again.. The number one rule was you couldn't use the same one-liner in the next round so each round got more and more convoluted.Educational day.
However, the solution given here assumes you have a bash compiled with support for /dev/tcp. You can, instead, paste the necessary executables directly over the existing connection to the system, encoded to survive that transport.
- being able to create a file containing arbitrary data
- being able to make a file executable
- being able to execute a file
Would the same be possible if your shell was not bash but one with fewer features, like e.g. POSIX sh? That doesn't even require echo to be a builtin (it only has the 3rd function above), so it might be a dead end, but maybe there's some other way...
http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls....
It was a Sun OS 5.1 I believe on a pretty big box (for its time) with A LOT of user data. We recovered it using roughly the same steps. We didn't need to write in assembler though since we've had Sun compiler tool chain in /opt that survived. At the end, we used a modem to connect the damaged box to another one with a tape backup. It took about 12 hours to copy the data over.
> We lost everything in the Big War. Luckily our last supplies of Bash built-ins were left intact. If we pool our resources and use our remaining executable bits wisely, we might just last through the nuclear winter.
Maybe the original problem was actually "chmod a-rwx /bin/chmod" ... That would mean even the superuser couldn't execute /bin/chmod anymore, so you'd have to do something more creative to reset the executable bit on /bin/chmod. Like compile a C program that calls the chmod system call, or:
mv /bin/chmod /bin/chmod.orig
cp -p /bin/ls /bin/chmod
cp /bin/chmod.orig /bin/chmodThe compiler wouldn't be executable anymore either
$ cp /bin/chmod .
$ chmod -x ./chmod
$ /lib/ld-2.19.so ./chmod
./chmod: missing operand
Try './chmod --help' for more information.That was the first, and last time I think, that I used cpio. Phew.
That was the first, and last time I think, that I used cpio.
I had to delete some files in a temp folder and typed the command as I was always used to, and pressed enter.
Immediately realised something was wrong and then saw the "*" replaced with a "/". Did not have a fun afternoon.
It's definitely a nice trick, though.
Edit: http://cfajohnson.com/shell/articles/dynamically-loadable/
For my small Linux emulator I put the link in the Wiki after "Destroy the system" :)
https://github.com/s-macke/jor1k/wiki/Explore-the-emulator#r...
The system runs already on Busybox, so the whole binary is in RAM. Is there a way to restore the binary from /proc ? Or to restore the symlinks and maybe link them to /proc/self/exe or so?
It would have make more sense to at least change the title to make it more explicit.