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.
This is a nice exploration of what's built into the bash shell. Handy not just for when you rm -rf / , but also for when you suddenly find yourself lacking in usable tools. For instance, I've had an upgrade break the dynamic linker (/lib/ld-linux.so.2 or /lib64/ld-linux-x86-64.so.2), and suddenly no dynamically linked program runs.
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.
This is basically a bootstrapping problem and turns out to rest on these critical functions:
- 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...
Alternatively, I think it might be possible if you can cause arbitrary interrupts to the operating system and control some registers and perhaps the stack as well. Depending on the shell, you might be able to do this; you certainly don't need the standard command-line tools for chmod and cat, because those are just small programs that pass through to actual system calls:
I've had very similar experience. I believe it was Oracle 7 and one smart guy tried to install it into the root folder. The only problem was that the install script did 'rm -rf $DESTFOLDER' at the beginning. Luckily for us, the script actually printed the commands on the console and the guy quickly realized what is about to happen. He aborted the install script but by the time /etc and quite a few other things were gone.
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.
On Macs, /Applications is probably the first to go. I stopped an rm -rf /* (intended .*) inside /Applications/Adium.app. I'm really glad I wasn't using a SSD!! Adium itself started acting very odd. One of the many issues was that sending a message to a specific person actually sent the message to a group chat. I was lucky to figure that one out before I cursed out the group chat while describing my stupidity.
Mildly interesting: CoreOS is shooting for `rm -rf /` being safe and similar to a "factory reset" on your phone. Here are the results on vagrant after rebooting a machine where `rm -rf /` was done: http://i.imgur.com/VMuPkf3.png
I was thinking more of a post-apocalyptic sci-fi story.
> 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.
My worst has been accidentally removing zip - back in my Slackware days IIRC. I was trying to upgrade and so I removed the old one and then went to install the new one and couldn't install it again as the packager used zip and all the downloads I could find were tar.gz (or tar.bz2 or whatever).
That was the first, and last time I think, that I used cpio. Phew.
No, root can still run chmod, because its superuser privileges override the new restrictive directory perms. That was my point.
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:
The explanation for what made him type that is what interests me. It would be like accidentally cutting your left hand clean off with a steak knife while you were eating dinner.
My bash is set to use vim bindings (set -o vi) and I constantly loop through commands. I am guilty of doing this while sleepy and sometimes I think I have cd to another directory when in fact I have not. I rm-ed (too) many things that way.
I gave the vi mode a very short try, but it doesn't seem to make as much sense in a shell. If it has you accidentally deleting things, you might want to ask how much is it really worth. In vim you can undo.
My worst has been accidentally removing zip - back in my Slackware days IIRC. I was trying to upgrade and so I removed the old one and then went to install the new one and couldn't install it again as the packager used zip and all the downloads I could find were tar.gz (or tar.bz2 or whatever).
That was the first, and last time I think, that I used cpio.
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?
There may be an obvious reason, but if using another machine is fair game as he did in one of the examples, then why did OP not just copy ls/chmod/etc from another machine to poke around?
How are you proposing he copy it from another machine? There's no file transfer program, client or server, remaining. Nor is there a way to mount an external filesystem. The whole point of the exercise is to bootstrap up from the few remaining resources to the point where you can "just" copy stuff in from another machine.
Reposts are fine when an item hasn't had significant attention within about the last year. The previous post had 10 points, but 0 comments, so this repost probably doesn't count as a dupe.
(WARNING: These make a mess don't do this on a system you care about)
(NOTE: Spaces matter here watch if you cut-paste)
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.