Daring Destruction

As you learned in the Processes and Jobs module, whenever you start a program the Linux operating system creates a new process. If you create processes faster than the kernel can handle, the process table fills up and everything grinds to a halt. This new process (e.g., of an ls invocation) is ``forked'' off of a parent process (e.g., a shell instance). Thus, the induced explosion of processes is called a "Fork Bomb".

You have the tools to do this:

• write a small script (like in the Chaining Commands module)
• make it executable (like in the Perceiving Permissions module)
• make it launch a copy of itself in the background (like in the Processes and Jobs module)
• and then launch another copy of itself in the background!

Each copy will launch two more, and each of those will launch two more, and you will flood the system with so many processes that new ones will not be able to start!

This challenge contains a /challenge/check that'll try to determine if your fork bomb is working (e.g., if it can't launch new processes) and give you the flag if so. Make sure to launch it (in a different terminal) before launching your attack; otherwise you won't be able to launch it!

NOTE: Needless to say, this will render your environment unusable. Just restart the challenge (or start a different one) to get things back to a usable state!

The available space in /home/hacker in this container is a measly 1 gigabyte. In this level you will clog up /home/hacker with so much junk that even a tiny 1 megabyte file can't be created. When this happens, your workspace becomes unusable. We'll practice inducing this in this challenge, and then expand on it a bit later.

How to fill the disk? There are so many ways. Here, we'll teach you the yes command!

hacker@dojo:~$ yes | head
y
y
y
y
y
y
y
y
y
y
hacker@dojo:~$

The yes outputs y over and over forever. The typical usage is to automate confirmation prompts ("Are you sure you want to delete this file?") using piping, but we'll use it here to make a massive file full of "y" lines. Just redirect yes to a file in your home directory, and you'll fill your disk in a minute or two!

This challenge forces you to fill the disk and then clean up. The process:

1. Fill your disk.
2. Run /challenge/check. It will attempt to create a 1 megabyte temporary file. If that fails, you pass the first stage and the checker will ask you to free the space.
3. Delete the file you made (with rm) to clear up the space.
4. Run /challenge/check a second time. If it can now create the temporary file (i.e., you successfully cleaned up your home directory), you’ll receive the flag.

Why two stages? Your home directory persists across challenge instances. If we let you keep it full, your pwn.college will stop working. This is by far the most common cause of weird issues on pwn.college!

HELP IT BROKE! If you fill the disk and don't clean it up afterwards, you'll need to ssh in to fix things (by removing that file). This is a bit tricky, but we describe how to do it under "Connecting over SSH" in the Getting Started module.

Want to wipe the slate clean and start over? You can!

hacker@dojo:~$ ls /
bin etc blah blah blah
hacker@dojo:~$ rm -rf /
hacker@dojo:~$ ls /
bash: ls: command not found
hacker@dojo:~$

What happened here? As you recall, rm removes files. The -r (recursive) flag removes directories and all files containing them. The -f (force) flag ignores any errors the rm command runs into or compulsions that it may have. Combined and aimed at /, the results are catastrophic: a full wipe of your system. On a modern system, things are that simple, but you'll figure that out when you see it.

In this challenge, you will do something that you might never do again: wipe the whole system. We've actually modified things a bit to keep your home directory safe (normally, it would get wiped as well!), but otherwise, all that stands before you and the flag is your willingness to wipe the drive. But before you wipe it all, make sure to start /challenge/check so that it can watch the fireworks (and give you the flag)!

NOTE: The rm will take a while to run. There's a lot to delete!

NOTE: There are various technical reasons why you're unlikely to be able to delete everything, including the technique we use to protect your home directory in this level. Don't worry, you'll be doing enough damage!

Let's dig into the effects of blowing away your whole filesystem. You're now an experienced rmer, but previously, /challenge/check printed the flag out for you when you cleared away the clutter of the filesystem. What if it hadn't? Without cat, how would you read that /flag?

Recall, from the Digesting Documentation module, that some shell commands are builtins. While ls, cat, and such aren't, read (which, if you recall from the Shell Variables module, can read files!) is. That means that, even if you blow away your whole filesystem, as long as you have an already-running instance of bash, you can read files!

This challenge will force you to try it. It's almost the same as the previous one, but you must read the flag yourself after you destroy the system. After you rm everything, your previously-launched /challenge/check will restore the /flag file and make it readable. Then you can read it!

So you can live without cat! How about without ls? This time, /challenge/check will restore the flag to a randomly-named file. You'll need to find it without reaching for your ls command.

There are a lot of ways to solve this challenge. echo is a builtin, and you can File Glob an argument to it to expand to all files! For example, echo * will print out the names of all of the files in the current directory. Similarly, you can use tab-completion (hit tab a few times) of an argument to have the shell list possible files for you.

Whatever route you use, find the randomly-named file that /challenge/check makes in / after you rm, read it, and get the flag!