E-SNIFFThe embedded ethernet packet sniffer

A Senior Design Project by Alex HoylandAdvisors: Mr. Steve Gutschlagand Dr. Aleksander Malinowski

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.

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.

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!

How it works

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.

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

Hardware - CPU

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

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.

Hardware - VGA

Hardware - VGA

Hardware - VGA

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.

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.

Hardware - Keyboard

Hardware - Top

This is what it looks like when you put it all together:

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.

Software - Init

Software - CPU monitor

Software - 1s interrupt

Software - Keyboard

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

Software - Ethernet

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.

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.

Software - Dissectors

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.

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.

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

Questions?