High Level Design

The overall goal of this project was to create as much havoc on the internet as is possible from an unassuming computer. While time and legal constraints limited some of the scope of what we could do (DNS cache poisoning, SSL forgery), we still were able to accomplish quite a lot. Below is a general description of what our project actually did.

After initializing the ethernet controller, we listened for packets in promiscuous mode (not just packets addressed to us). When a packet was received, we incrimented the packet counter on the 7-segment LCD screen, and examined the packet to see if it was of interest to us. There were basically two groups of interest for us - packets addressed to other web servers, and packets addressed to us (for our web server).

For packets addressed to other web servers, we looked specifically for HTTP GET requests. This is basically the browser asking a website (e.g. google.com) for its webpage. We display the request URL on our LCD display.

Since we will likely receive this packet several milliseconds before the real web server does, we forge a response that will beat the real web server's response back to the browser. We forge this response to look identical to what the browser expects (correct SEQ/ACK/Port numbers, Source IP, and even correct MAC address (though this is not checked by anyone)), so even if the browser was wise to us, it would not be able to tell the difference between our forged page, and the real page.

For good measure, we then send a TCP FIN/ACK packet to the source (browser), essentially severing the connection between the host and client.

We detect packets addressed to us if it is to our MAC address or (depending on packet type IPv4) if the packet has our* IP address. These packets appear in various forms, including For ARP, we must respond with an ARP response with our MAC address (00:13:37:13:37:00). For TCP, we have to respond based on what type of TCP packet it is. If it is a SYN packet, we respond with SYN/ACK. For FIN/ACK, we respond with ACK (and our own FIN/ACK). We can ignore ACKs because they are just acknowledgements of packets we have sent. For HTTP, we must respond to GET requests with an HTML page (containing the visitor count, and the current temperature). We implemented ICMP so that we could ping the MPC823 and get a response.

*Note: the IP address 141.213.9.239 was not really "our IP address", so much as "DCO's IP address which didn't respond to pings, so we decided to respond to packets addressed to it as if it were ours".

We also occasionally generated packets (if the right switch was set). These packets were gratuitous ARP packets, with a forged IP and MAC address of the gateway address (the address all computers on the subnet send outgoing packets to when trying to reach "the internet"). We sent about 100 of these packets per second. This fooled any switches these packets passed through into thinking that the outgoing physical port for the internet was on our port, and so we received a large amount (all) of the outbound traffic despite being a dead-end node. This caused computers to loose connectivity on the internet - they were virtually silenced to the outside world. Thus, a fairly large network can be taken down with a suprisingly small number of packets.