A Tutorial on Sniffer for Windows

By Bit_Logic
bit_logic@s-mail.com
“To those who dare to learn.”

Disclaimer

Consider this electronic book (eBook) literary freeware. It may be transferred,

reproduced, and viewed with no limitations so long as the following two conditions
are maintained without exception:

1. This document may not be modified in any way, in part or in whole.

2. Under no circumstances may you accept payment for redistribution of this
eBook, either electronically or in print.

And of course, the author cannot be held responsible for anything foolish you
decided to do. This document is provided solely for educational purposes.

“Information wants to be free.”

- Bruce Sterling

SYN

I get a lot of requests from people to teach them how to use Sniffer. Sniffer, as you
probably know since you’re reading this tutorial, is a Windows-based GUI network
packet sniffing application. Essentially, it captures all data frames and/or packets
[Note 1] going in and out of your network card. Why would anyone care to view
these packets? There are actually a lot of reasons. Sniffing is used primarily to
monitor network performance, but of course much more devious uses can be applied
to it. For example, if you configured a switch to send all network traffic through your
computer by means of SPANing (Switched Port ANalysis) a certain switch, you could
monitor every bit of data sent and received by everyone on your LAN.

The main goal of this tutorial is not to teach you to spy on your coworkers (well,
maybe a little), but to teach you how to capture and view packets using Sniffer, so
that you can in turn learn more about networking in general. As Sniffer is Windows-
based, we’ll be dealing almost exclusively with TCP/IP Ethernet traffic. If you
haven’t installed Sniffer yet, now is a good time to do so. The installation process is
relatively straightforward, and shouldn’t take more than a few minutes, plus a
reboot. If you have any problems getting it to run, consult the Sniffer readme file.
Once you have it working, it’s time to capture our first frames!

Getting Started

When you run Sniffer for the first time, you’ll notice a main window with a button
toolbar at the top, and a child window titled “Dashboard”. Close the dashboard for
now, and let’s focus on the main toolbar for a moment. Here’s a rough list of each
function available in the toolbar:

Capture Controls – These first few buttons allow you to start, pause, stop, and
view captures.

Filters – You can define and apply packet filters with the “Define Filter” button and
drop-down list.

Open/Save – You can save captured packet lists and open them to view later.

Print – Take wild guess.

Dashboard – The dashboard displays real-time traffic going in and out of your
network card.

Host Table – The host table lists all recorded hosts on your LAN that have
sent/received data to/from your computer.

Matrix – That’s right, it’s not just a movie. The matrix has a whole bunch of traffic
summarization tools. You can choose to view traffic in a list or graphical format.
These are neat when you have at least a couple dozen computers on your LAN.

Application Response Time – You can see exactly – and I mean exactly - how long
it takes for a certain webpage to load, or how high the delay on your domain
controller is, for example.

History – Here you can find a summary of just about any packet category,
represented in just about any graphical format.

Protocol Distribution – See how different protocols stack up to each other in use
on your network.

Global Statistics – Displays the rarity of different frame sizes.

Alarm Log – Problematic frame transmissions (collisions, fragments, etc.) should

show up here.

Capture Panel – Displays real-time capture statistics. The detail tab provides a nice
clean overview of the entire process.

Address Book – Sniffer will usually auto-detect hostnames and other identities, but
you can manually add specific addresses to the address book.

Sound like a lot of features? You haven’t seen half of them yet. Now, the moment
you’ve been waiting for; we’re going to capture a minute or so of typical network
traffic. Back at the far left of the toolbar, click the “Start” button. You should see
the “Expert” window pop up. This window provides a real-time summary and
diagnostic of network traffic. There are three gray buttons at the bottom of the left
column. “Diagnoses” and “Symptoms” list packet errors or other indications of poor
network performance. “Objects” offers a more interesting survey of all known
devices, protocols, connections and more.
We’ll discuss the Expert window more in-depth (probably a lot more in-depth than
you ever wanted to go) later. For now, open up your web browser and go to a web
site. Any web site, it doesn’t matter; our goal here is to generate some traffic for us
to sniff. A single hit to cnn.com should give you a healthy few hundred frames.
When the page has finished loading, go back into Sniffer. You can view the number
of captured frames in Sniffer’s status bar at the bottom of the screen.

There are two ways to stop sniffing. The “Stop” button will simply abort the capture.
This means you will not be able to save anything. The “Stop and Display” button,
however, will allow you to save your capture, and view saved statistical information
too. It also opens up the ability to view and edit raw data frames. Click “Stop and
Display”.

I know at first it doesn’t look like much, but you have actually captured a great
amount of data. In the top window bar, go to File > Save As… Rename the file to
MyFirstSniff.cap and save it to a directory of your choice. Congratulations! You have
just captured and saved real live network traffic.

Viewing Raw Frames

If you don’t understand exactly what Sniffer is doing yet, that’s okay. This next
section should provide a good insight to the actual process of frame capturing. First,
you need a stopped frame capture open. You can create a new capture or open an
existing one, just make sure you have a stopped capture, as you can’t view raw
frames in real-time.

In your completed capture window, you should see a row of tabs along the bottom of
the window (Expert, Decode, Matrix…). Click on the “Decode” tab to switch to the
raw frame view. At this point, you will be presented with an enormous amount of
information; try not to explode. (Note: You may find it easier to maximize the
Sniffer and Decode windows to take up the entire screen.) The decode view is
divided into three horizontal panes, each taking up a rough third of the screen. Each
pane has a separate degree of detail:

Summary Pane

This top window lists every captured frame in chronological order. It has several
columns that you can resize, move, or hide as you see fit:

Selection – The leftmost column contains a checkbox for selecting individual

frames. More on this later.

Number – The frame’s chronological ranking (No. 1 is the first frame captured).

Status – Any special status of the frame, usually none. You’ll notice the first frame
is marked with “M”.

Source Address – The protocol address or hostname of the transmitting station.

Destination Address - The protocol address or hostname of the receiving station.

Summary – Shows the identified protocol, and any available specifications unique to
that protocol (such as the destination and source ports for TCP). Don’t worry if you
don’t understand any of it.

Length – Frame length measured in bytes.

Relative Time – Time since the capture started, presented in the format
Hours:Minutes:Seconds.Milliseconds.

Delta Time – Time since the last frame was captured, presented in the format
Seconds:Milliseconds:Nanoseconds.

Absolute Time – Time of capture as indicated by the system clock, presented in the
format Month/Day/Year, Hour:Minute:Second, AM or PM.

Most of these are self explanatory, with the possible exception of the summary
column. First, the text in this column will be colored according to what protocol the
frame is. For example, generic TCP is pale green, DNS is brown, HTTP is pink, etc.
The first item listed in the summary field is the detected protocol. Then, it will
display certain key values corresponding to that protocol. For example, TCP will
show the source and destination ports, SYN/ACK/FINs, a sequence number, and so
on, whereas HTTP will instead show the source port and HTTP request.

Individual frames can be selected or deselected by checking or unchecking the box in

the leftmost column. You can also right-click anywhere in the summary pane and
click “Select Range…” to specify a range of frames to be selected or deselected. Also
found in the right-click context menu is the “Save Selected…” option. This will copy
all selected (checked) frames to a completely new capture window. (Note: This will
not affect your current capture in any way; it simply opens an additional window.) If
you switch to “Decode” view in this new window, you’ll see that only the selected
frames have been copied into the new capture. Try it out to get the hang of it, then
return to your original capture.

Detail Pane

The detail pane provides a very convenient frame overview, broken into a hierarchy
of information corresponding to the OSI Model [Note 2] layers. An example HTTP
packet contains four such levels: DLC, IP, TCP, HTTP. All Ethernet frames will have a
DLC (Dynamic Link Control) layer, followed by the network/transport layer
protocol(s) and finally the application protocol(s).

The DLC header is short and sweet, with only three fields. (Note: The first line
(“Frame XXX arrived at…”) is only a summary of the frame added by Sniffer – it is
NOT data contained within the frame itself.) The source and destination MAC (Media
Access Control) addresses are displayed here with one notable difference: the first
three bytes of the address may have been changed to read as the card
manufacturer’s name. For example, instead of “00B0D0”, it would say “Dell”. For
more information on MAC addressing, see [Note 3]. Last is the Ethertype, usually IP
or IPX.

The next protocol will vary depending upon what type of network you are on. The
majority of Windows/*nix LANs run TCP/IP Ethernet. At the time of this writing,
Sniffer is only available on Windows platforms, so the next few examples will assume
you’re capturing on a TCP/IP stack. For more information about TCP/IP, see [Note
4].

Next comes the IP header (remember, this is assuming you’re running TCP/IP). The
IP header contains a good deal of information about the packet, but most of it is
outside the scope of this tutorial. For now, all you might need to be concerned with
are the source and destination addresses. After IP, you’ll usually see TCP. (Yes,
there are other IP based protocols (like UDP and ICMP), but this is a Sniffer tutorial,
not an RFC. Give me a break.) Again, this header contains a whole lot of
information, but we usually just don’t care about it. The most useful fields are the
source and destination port numbers, which can often help you identify a protocol if
Sniffer cannot detect it automatically.

After this, you’ll see any number of higher protocols. The most common are
detected automatically by Sniffer, but there are thousands of them. [Note 5] lists all
officially mapped protocols and their ports.

Hex Pane

This last pane is the real down-and-dirty, byte-for-byte view of a frame. You can’t
get anymore close up and personal than actual hex (except maybe flat out binary,
but that would drive you to insanity). To learn more about hex, see [Note 6]. You’ll
notice every hex byte is color-coded to match its corresponding data layer. A series
of black zeroes at the end of a very short frame, called padding bytes, are used to
enlarge a frame to its minimum length.

Every row of bytes begins with its row number, also represented in hex. There are
sixteen bytes per row, along with each byte’s ASCII representation at the right
(invalid ASCII values are indicated by a dot – not to be confused with the actual
ASCII value for a period, “2E”). Clicking on individual bytes will highlight the series
of bytes it belongs to in both the summary and hex panes.

Transmitting Frames

Sniffer isn’t only limited to sniffing, believe it or not. It also has the ability to send
raw data frames onto the network. This is an invaluable tool, as you can easily
retransmit a frame or list (known as a buffer) of frames to sort of recreate network
traffic. To send a single frame, right-click it in the summary pane, and select “Send
Current Frame…”. Here you can specify the number of times to transmit the frame,
as well as the delay between transmissions. You can also edit the raw hex values in
the frame; more on that later. You can view the current count of transmitted frames
in Sniffer’s status bar at the bottom of the screen.

One important note about firewalls: Certain firewalls interfere with the transmission
of raw frames, whether Sniffer is allowed to access the network or not. This results
in one of those lovely blue screens and a full system reboot. My advice is to
temporarily disable your firewall before you attempt to transmit a raw frame.

You can also retransmit an entire capture. Remember how to select frames in the
summary window? Select the frames you want to send, and save them to a new
capture. In this new capture, right-click anywhere in the summary window and click
“Send Current Buffer”. Here you can only adjust the number of transmissions; the
delay is specified by the individual frames’ delta times.

Editing Frames

You can also edit raw frames to save or retransmit. Unfortunately, editing some
frames correctly, like TCP packets, is close to impossible because of the checksum
and length limitations. Editing is possible, though. To edit a frame, right-click
anywhere in the hex window, and select “Edit…”. The “Hex Edit” window will pop up,
and you can alter raw hex value, four bits (half a byte) at a time. As you edit the
hex, the ASCII representation to the right will change to match the new values.
When you’ve finished editing, click “Re-interpret” to save the modified frame back
into the capture buffer.

Capture Filters

Sniffer is installed with the “Default” capture filter, which is set to capture all frames.
On a normal LAN, this means quite a bit of traffic. If you’re only looking to monitor a
certain type of packet (for example, HTTP requests), you can define and apply a filter
to do so. Start by clicking the “Define Filter” button at the top toolbar. Here you will
see a window with several tabs. This is the default filter definition.

Let’s say you suspect that a rogue user has been pinging down one of your servers
at random times. Being the savvy network administrator you are, you decide to run
Sniffer to get some hard evidence (I know this example sucks, but bear with me).
But wait, we don’t want to monitor the traffic of the entire LAN; that would result in
thousands of frames after just a few minutes. Instead, we want to define a filter to
capture only ICMP packets from a certain workstation.

In the “Define Filter – Capture” window, click the “Profiles…” button at the bottom
right. This will allow you to create new filters. Click “New…” and type in the name
“Pings Only”. Leave the other options as they are – this will copy the default filter.
Hit “OK”, and then “Done”. Now you should see the highlighted “Pings Only” filter
listed beneath “Default” on the right. Next, we need to define the filter. There are
five tabs along the top of the window:

Summary – This window provides a brief overview of the current filter.

Address – You can opt to only include or exclude certain MAC, IP, or IPX addresses.

Data Pattern – Allows you to match frames by a certain data string.

Advanced – Include only certain protocols, sizes, and types.

Buffer – You can set the capture’s buffer size. This the amount of data held in
memory during a capture. When the buffer is full, it can be set to dump or save to a
file.
Returning to our example, assume we only want to capture ICMP packets from the
workstation 192.168.14.183. Under the address tab, specify “IP” as the address
type, leave the mode as “Include”, and type “192.168.14.183” in the first box under
“Station 1”. (Note: By including only certain workstations, all others are excluded.)
Next, click on the “Advanced” tab. Scroll down the list until you find “IP”. Click the
plus sign next to “IP” to expand the list. Find “ICMP”, and check it. You can now hit
“OK” and start capturing. When you stop and view your capture later, you’ll notice
only ICMP traffic (if any) was captured. (Note: Make sure the “Pings Only” capture is
selected in the toolbar at the top, not “Default”.)

Triggers

Sniffer has the ability to automatically start and stop capturing frames based on
user-defined conditions called triggers. Select “Capture” from Sniffer’s top window
menu (not the buttons), and click “Trigger Setup…”. You can define separate start
and stop triggers, as well as enable/disable “Repeat Mode”. Both triggers need a
trigger and capture filter, but the stop trigger also has the option to set a delay of X
number of packets.

To define a start trigger, first enable it. We’ll leave the capture filter to default (all
frames). Click “Define…” to set the trigger. We’ll create a new trigger called “Work
Days”, so click “New…”, enter “Work Days” in the prompt, and click “OK”. Check the
“Date/Time” filter and set it to 7:00 AM, and unselect (click) the Saturday and
Sunday buttons. You can also set predefined alarms and make your own trigger
filters (which are made the same way as capture filters) if you need to. Click “OK” to
return to the trigger setup window. You could also set a stop trigger the same way
you just set a start trigger, but we’ll leave it disabled for now. This means it will
keep capturing until a human user stops it (or the capture filter tells it to stop when
the buffer is full). (Note: Once you’ve become familiar with triggers, make sure you
disable all triggers until you want to use them.)

FIN

You may still be far from becoming a sniffing pro, but you should have the basics of
Sniffer down. There are a few trivial areas I didn’t go into detail on, but you should
be able to find them should you come to need them. I hope this tutorial has helped
you understand the raw data transfer behind computer networking, and that you
continue to study the field. There’s no better way to understand the TCP/IP three-
way initial handshake then by actually viewing those three packets byte for byte in
plain text on the screen in front of you. You may also want to experiment with
sniffing on different platforms and networks. There are sniffing utilities for just
about every OS out there. Remember, no matter how much you know, there’s
always more to learn.

- Bit_Logic
[Note 1]
Frames are the datagram unit for the OSI Media Access Control layer (layer 2),
whereas packets apply to the Network layer (layer 3). See [Note 2] for more
information.

[Note 2]
The OSI (Open System Interconnect) model is a seven-layer network specification
detailing what operations take place at what “layer” of a network. Further
information can be found at:
• http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm
• http://www.thelinuxreview.com/howto/intro_to_networking/c4412.htm
• http://www.learntcpip.com/OSIModel/default.htm (With video for the
excessively lazy)

[Note 3]
MAC (Media Access Control) addresses are unique burnt-in hardware addresses
found on every network card. For more information, see:
• http://compnetworking.about.com/library/weekly/aa062202a.htm
• http://howto.lycos.com/lycos/step/1,,26166+25845+18045,00.html

[Note 4]
The TCP/IP protocol stack is the most commonly used system for network
communication in use on LANs (Local Area Networks) and the Internet today. For
more information, see:
• http://www.ipprimer.com
• http://www.cisco.com/warp/public/535/4.html
• http://www.protocols.com/pbook/tcpip.htm

[Note 5]
Most common protocols, such as DNS, HTTP, and SMTP, have well-known port
numbers. For a complete list, see
• http://www.iana.org/assignments/port-numbers.

[Note 6]
Hexadecimal math is used as a sort of shorthand method for representing binary
value (from 0 to 255). For more information, see:
• http://www.southwest.com.au/~jfuller/binary/binary7.htm.