Internet Interrupter
by Greg Ruhnow and Eric Wustrow
The Internet Interrupter was an experiment in applying embedded systems (MPC823) to large networks (Internet, via Umich). Over the course of the project, the MPC accomplished a surprising amount of goals including:
- Packet counter - counted the number of packets recieved
- Packet sniffer - listened to HTTP traffic, printed out URLs of pages people were visiting on an LCD screen
- Packet injector - responded to HTTP requests before the real web server could reply, essentially poisoning a web page (see above picture)
- Web server - with a "borrowed" IP address (141.213.9.239), we served a simple web page that displayed the number of visitors, as well as the current temperature in the lab.
- Network disruptor - spoofed packets from the gateway's MAC address, forcing chosen switches to reroute all outgoing traffic to our MPC823. This had the lovely side affect of taking down the network in the lab (or potentially greater area).
Task Distribution
- Ethernet driver - Eric
- Ethernet applications - Eric
- Temperature sensor - (90%) Eric, (10%) Greg
- LCD driver - Greg
- LCD applications - Greg
Results
The original goal for the project was to be able to intercept packets and display URLs of web pages as people were visiting them. This was something that this project did reliably, and exceeded our expectations. The implementation of the packet injector (the ability to send our own web page in place of a legitimate one) was quite surprising and amusing to see actually work. However, there were some reliability issues with sending packets, which affected many of the "extra" aspects of this project (including packet injector and web server). A large amount of time was spent trying to solve this problem, and small improvements were made, but it is still far from a polished product. The proof of concept and ideas were definitely there, however.
Conclusion
Over this project, we learned a great deal about hardware/software interfacing, and learned how to read documentation. While our project certainly wasn't as flashy and perhaps as cool as some of the other projects, it had a very technical purpose, and was amusing to those that understood what it was doing.Given what we have learned from this project, doing it again we may make more risks with our design with more confidence. For example, we may write the drivers in C, or even perhaps make our own hardware ethernet controller to make things easier to debug. This may or may not make transmitting more reliable, but it would be an interesting project to learn more of the inner details of what the ethernet controller is doing.
As far as processing power goes, while a faster processor would not hurt (we might be able to communicate at 100Mbps instead of just 10Mbps), the nature of the CPM running in parallel with the MPC823 core made this project plenty fast to do what it was doing. There is of course a limit (a single board would likely not be able to poison every web request in umich at once), but for small scale purposes like in the lab, the MPC823 was fast enough.