E-SNIFF The embedded ethernet packet sniffer

1. E-SNIFFThe embedded ethernet packet sniffer A Senior Design Project by Alex Hoyland Advisors: Mr. Steve Gutschlag and Dr. Aleksander Malinowski

2. Project Summary • Packet Sniffers are devices or programs capable of intercepting and logging data traveling over a computer network. • Sniffers are used for a variety of purposes, including monitoring, network troubleshooting, intrusion detection and surveillance. • The typical packet sniffer is a software program that runs on a PC. This wastes CPU time that could be used for other tasks. Also, PCs are bulky and difficult to hide, making them less practical for surveillance purposes. • E-Sniff is a small special-purpose embedded system for capturing and logging network data. It is implemented in an FPGA, and uses a soft processor and custom hardware to capture packets and display them on a VGA monitor. The user can also enter commands using a PS/2 keyboard to control packet processing.

3. Project Summary • The E-sniff project is implemented in an Altera DE2 board. • This board contains numerous peripherals. • The ones used for this project are: a Cyclone II FPGA, an 8MB SDRAM, 4MB CFI flash, an 8MB Serial Flash, a 16x2 Optrex LCD, a high-speed Video DAC, a PS/2 serial port and a DM9000A 10/100 Mbps Ethernet Controller. These are highlighted below in red.

4. How it works • Ethernet networks use a physical bus topology. All devices on the same bus segment are said to be in the same “collision domain.” • All hosts in a collision domain can see all the data on the bus segment, i.e. they can intercept traffic meant for other hosts. • This means our packet sniffer can intercept traffic going to/from any host in the same collision domain. • In modern networks, switches are used to break up collision domains. Each port on a switch corresponds to a single collision domain. This means our sniffer cannot see any traffic if it is plugged into the switch!!! • To sidestep this problem, E-Sniff is plugged into a hub, which is inlined between the host and the switch. This puts the sniffer on the host’s collision domain. Now we can read our coworker’s email!

5. How it works

6. Hardware - CPU • The CPU is an Altera Nios II customizable soft processor. It is clocked at 100 MHz and is implemented in the Cyclone II FPGA. • The CPU was generated with Altera’s SOPC builder tool • The Nios II can be completely customized, and can interface directly with any memory or peripheral device on the board. • The E-sniff CPU interfaces with several chips on the DE2 and has access to over 20 MB of memory, as shown below: • 8MB EPCS serial flash - holds software image and FPGA config data • 8MB SDRAM - main program memory, holds heap, stack, text, etc. • 4MB CFI Flash - non-volatile packet storage and software config data • 4KB On-chip memory - fast memory on the FPGA, used to hold the exception stack/interrupt service routines.

7. Hardware - CPU • The CPU also interfaces with the following onboard peripherals: • Davicom DM9000A Fast Ethernet MAC/PHY • Keyboard/VGA on-chip text memory • Keyboard receive module • Optrex LCD • 25 LEDs, 17 switches, 4 buttons • It contains the following peripheral modules: • Hardware system ID module • JTAG Debug/Trace module • 1s interval timer - generates interrupts for per-second tasks • 1ms interval timer - generates interrupts for CPU usage monitoring

8. Hardware - CPU This is the memory map of the main CPU as shown in SOPC builder.

9. Hardware - VGA • The VGA monitor is controlled by a custom hardware module. • The module generates VGA sync signals to drive a 640x480 display. • It maps ASCII character codes from a small on-chip memory into pixel patterns on the screen. • This way, the processor can quickly write a string to the memory and have it appear on screen. The processor also does not have to bother with generating VGA sync signals. • Line returns are also handled in hardware. When the CPU wants to advance to the next line, it briefly asserts an ‘enter’ signal that is read by the VGA controller. This adds to an internal memory offset that effectively shifts the top line off of the display and adds a blank line to the bottom. This saves the CPU the trouble of redrawing the text one line higher on the screen.

10. Hardware - VGA

11. Hardware - VGA

12. Hardware - VGA

13. Hardware - Keyboard • The keyboard hardware receives scan codes from a PS/2 keyboard, translates them into ASCII and writes them to the screen. • The first module in the keyboard controller receives 11-bit keyboard messages, checks them for parity and alignment errors, and outputs the 8-bit scan codes contained in them. • The second module is a hardware look-up table, which takes the scan codes and translates them into ASCII. • The ASCII characters are then written to an on-chip memory in the vga module, which displays them on the screen. • This is all done without interrupting the processor. • When the user has typed an entire line of text, they press the enter key. • This interrupts the processor, which reads the line of text out of the input memory, then clears it, then processes the command.

14. Hardware - Keyboard • Features: • The user can press backspace to clear a character • The module supports repeating, i.e holding down a key will write the same character multiple times until the key is released • Supports capital and lowercase letters, numbers and punctuation • Problems: • Only a subset of the keys on a normal keyboard are supported because my head hurt from writing giant lookup tables • Transmission to the keyboard is not currently supported, so the CAPS LOCK, NUM LOCK and SCROLL LOCK LEDs cannot be lit. • Also, if a message is misaligned or contains a parity-bit error, the controller cannot signal the keyboard to retransmit and the user must type the character again. Full-featured PS/2 controllers can tell the keyboard to retransmit the last character code if this happens.

15. Hardware - Keyboard

16. Hardware - Top This is what it looks like when you put it all together:

17. Software • The E-Sniff software was built using the Altera Nios II EDS, an Eclipse-style IDE for writing Nios II software. • The software consists of five main routines distributed over 21 source files. The source files contain over 3000 lines of C code. • The first routine initializes the system. • The second routine monitors CPU usage. • The third routine updates the status bar, system run timer and LEDs. • The fourth routine handles user input from the keyboard. • The fifth routine handles interrupts from the Ethernet controller.

18. Software - Init

19. Software - CPU monitor

20. Software - 1s interrupt

21. Software - Keyboard

22. Software - Keyboard • Supported commands: • capture - starts/stops packet capture • filter - sets filter rules, turns filter off/on • verbosity - controls the amount of text displayed about each packet • log - turn the packet log off or on • status - change what is displayed in the status bar • debug - debug commands, read/write memory • splash - show the splash screen • sysinfo - display system info • praise - show reviews from classmates • homer - ascii art of homer simpson • help - display a help menu • <command> help - help for any command

23. Software - Ethernet

24. Software - Filtering • To look at a particular subset of traffic, the user can set a filter. • The E-Sniff filter has up to five filter rules. If a packet matches any of these rules, it will be displayed. • Each rule consists of the following subrules: • Source IP/netmask • Destination IP/netmask • Source Port • Destination Port • Source MAC address • Destination MAC Address • Network/Transport protocol • For a packet to match a filter rule, it must match all of the subrules.

25. Software - Dissectors • The dissectors perform the actual work of dismantling and parsing a packet. One dissector is implemented for each protocol to be read. • Ethernet packets have a layered structure. For example, HTTP data is encapsulated in a TCP datagram, which is encapsulated in an IP packet, which is encapsulated in an Ethernet frame. • As a result, packet dissection is similar to peeling an onion. • Every packet starts in the frame dissector parse_eth_frame(). • parse_eth_frame() parses the Ethernet Frame data and strips it off. A lookup table is consulted to determine what dissector to call next. • The data is passed to the next dissector, which parses a layer, strips it off, consults a lookup table to find the next dissector, and passes it on. • This continues until the actual application data is parsed.

26. Software - Dissectors

27. Performance • E-Sniff can capture packets from a busy 10 Mbps half-duplex line with about 99% reliability. • No test have been performed on a 100 Mbps line due to unavailability of required test equipment (new model Cisco switch) • Filtering works properly. • Dropped/Received/Filtered packet counters work correctly • Link state change monitoring works correctly.

28. Known Issues • The keyboard controller cannot transmit to the keyboard. This means that incorrectly received scan codes cannot be retransmitted and the lights on the keyboard cannot be lit. • CAPS LOCK key “capitalizes” numbers - 2 becomes @, etc. • The keyboard controller occasionally writes incorrect or multiple characters to the screen when a misaligned scan code is received. • The keyboard controller does not support all the keys on a standard keyboard, and does not support the arrow keys. • The LCD does not display text on the bottom line. This is believed to be caused by a glitch in the hardware • The link state change interrupt occasionally stops working when changes are made to unrelated code - may be due to a problem with the ethernet controller interface hardware • There is no command history - could be implemented without much trouble • The output buffer is only slightly bigger than the screen - needs to be enlarged - this could also be done without much trouble.

29. Future Work • Correct known issues • Add a web interface for issuing commands and reading the log • Add the ability to flash in new firmware over the network • Add the ability to identify gateways and nameservers • Add the ability to cache routing information and build a route table • Add the ability to log and display current DHCP leases • Add the ability to track website usage by each host • Add DNS name resolution to packet dissectors • Write dissectors for the hundreds of protocols left unimplemented • Allow eavesdropping on VoIP phone calls • Add support for basic network testing tools - ping, tracert, nslookup, port scanning, etc. • Identify network servers and determine their weaknesses

30. Questions?