Lab 6: Dr. Horrible's Fork Bomb of DOOM

This lab is part of Assignment 3. You are to complete the exercises here before arriving in lab on Monday/Tuesday. In lab, you and your partner will demonstrate your code to your TA, and get feedback. Your revised code is due on March 14 at noon.

Labs 5 and 6, together, form a simulation of a fork bomb, a type of computer security exploit. In Lab 5, we will implement code for a binary tree of computer processes. In Lab 6, we will use that implementation to simulate the virus.

As always, your code must comply with the CS 190 Style Specifications, and work on the ECF machines. The marking scheme for Assignment 3 is available here.

Part One: Fork Bomb

A denial of service attack is when a computer or other computational resource is made unavailable to its users. This type of attack tends to involve flooding the intended target with processes until the computer is overloaded, and crashes.

A fork bomb is a basic denial of service attack. It works like so: you create a process. All this process does is to clone itself: it makes a second process identical to the original. This is known as forking. The clone, of course, does the same thing. So you have 4 processes. Then 8. Then 16. 32. 64. And so on. This quite quickly overwhelms a CPU.

In Lab 5, we made a process tree. Now, we want to alter our tree so we can use it to simulate a fork bomb. You are required to implement the following methods. Note this tree has a different structure than the sorted tree from lab 5, but you can use helper methods like is_complete or print_inorder from lab 5!

Download the updated process.h and Makefile for this, along with test_three.c
  1. can_add_alternate: like can_add from lab 5, but does not check for a unique PID.
  2. spawn: this method creates a simulated fork bomb. Each leaf of the tree makes two children: the left child has the same PID and the same amount of memory as its parent. Starting again from the root, we look for the FIRST available leaf. The method stops and returns when no more memory is available in our simulated CPU (this number should be passed in as a parameter). Starting with a tree containing a single process with PID 1, our tree's lowest level would look like this over the first few iterations:
    1. 1
    2. 1 2
    3. 1 3 2 4
    4. 1 5 3 6 2 7 4 8
    5. 1 9 5 10 11 6 12 2 13 7 14 4 15 8 16
  3. is_leaf: returns 1 if a given node is a leaf of the given tree
  4. time_to_crash: this measures the CPU time for spawn to run until spawn has spawned enough nodes to take up all the memory in our simulated CPU. You can read how to time your program here: http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html.
  5. killall: frees all memory taken by our simulated program (i.e. frees the memory of the tree) -- this is the same as remove_all from before

Note that marks will be deducted for any compiler warnings.

Part Two: Dr. Horrible's Fork Bomb of DOOM

Dr. Horrible, putting his Ph.D. in Horribleness to use, has written a fork bomb program that crashes any computer it is run on. He plans to put this on a sensitive server and detonate it at a horrible and inconvenient time, and use it to take over the world!

Fortunately, Dr. Horrible never read The Top 100 Things I'd Do If I Ever Became An Evil Overlord and wasn't warned that "No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot." As such, his horrible bomb, if given the correct command-line arguments, will turn off the bomb (and save the world).

Your task is to use gdb to walk through the bomb (an executable named "horrible") and find the correct command-line argument to defuse the bomb. This is a difficult task, and if you fail your computer WILL CRASH. As such DO NOT RUN THE EXECUTABLE horrible DIRECTLY -- only use gdb, and stop the program before it enters the bomb. Two command-line arguments, both integers, will be needed to save the day.

Every student will have a different executable to defuse. To get yours, open a terminal and type the following commands:
wget www.cs.toronto.edu/~patitsas/cs190/code/group_NUM/horrible
wget www.cs.toronto.edu/~patitsas/cs190/code/group_NUM/horrible.c
chmod a+x horrible
gdb --tui horrible
 Be creative. You can discover the two numbers in either order.

Thankfully for you, Dr. Horrible was a bit sloppy, and through some friends you managed to get a copy of his browser history. The following articles in his browser history may prove pertinent to your task. If you're stuck, you should read through these carefully for clues.

  1. Two's Complement
  2. Instruction Set Architecture
  3. Big and Little Endian
  4. IEEE Standard 754 Floating Point Numbers
  5. C data types
  6. Strings
  7. Computer Insecurity
  8. SDB:Secure coding checklist: C and C++
  9. Call Stack
  10. Debugging with GDB: Examining the Stack
  11. Advanced GDB Features
  12. Where the top of the stack is on x86

Once you have the two numbers discovered, put the two in a file, solutions.txt, separated by a space. It should look like this. Hand this file in. It must be named solution.txt and have that formatting to be read by the automarker.

Commit your code before leaving your lab session on Monday/Tuesday.

Waiting to Talk to Your TA?

Get started on your Report!