Capturing and interpreting raw network data are totally separate things. Being able to recognize anomalies in the network data is the key to providing a useful tool that could be of real benefit to network managers and administrators.

Raw network data can appear totally unordered, with HTTP packets mixed in with NETBIOS (Microsoft file sharing) and ARP, each performing different tasks, but working simultaneously. Some of these packets can be recognized immediately: familiar snippets of HTML generally indicate HTTP (although it could be a rich-text email or a Web page being uploaded). Most networks will primarily ferry IP traffic, but will also carry non-IP traffic such as NETBIOS and ARP.

Every packet carries a header that is in a strictly defined binary format. To define the standards involved most concisely, the tables in this chapter list the name and starting point of each field in the relevant header. Every field runs contiguously with the next; thus, the length of any field can be calculated by subtracting its starting point from the following field’s starting point.

Because fields do not need to start at a byte boundary, the bit number is also provided in the second column. Where a field is commonly known as being part of a collective field, it is separated in the description column from the parent field by a colon.

The frame header (Table 13.1) is the only part that the hardware within the network card will actually read or process. It is 14 bytes long, containing the hardware address of the source and destination computers. In the case where the hardware address of the destination computer is unknown, this address is set to FF-FF-FF-FF-FF-FF (hex). Over PPP connections, the source and destination MAC address may be omitted and replaced by SRC and DEST.

The Ethernet type code is a two-digit hex number that specifies the packet protocol (Table 13.2). A fairly comprehensive list of Ethernet type codes can be seen at www.cavebear.com/CaveBear/Ethernet.

In IP packets, the IP header (Table 13.3) immediately follows the frame header at byte 14. IP is definitively described in RFC 791.

In ICMP (ping) packets immediately following the IP header make up a 4-byte header (Table 13.4) followed by a body of variable length. A definitive description of ICMP can be found in RFC 792.

Type: Defines the purpose or function of the packet. See Table 13.5.

Code: A type code–specific identifier that more accurately describes the function of the packet. In a destination unreachable (3) packet, 0 indicates the subnet is down, whereas 1 indicates that only the host is down.

Checksum: The checksum is the 16-bit ones complement of the ones complement sum of the ICMP message starting with the ICMP type.

In TCP/IP packets, immediately following the IP header is a 24-byte TCP header (Table 13.6). A definitive description of TCP can be found in RFC 793.

TCP is a connection-oriented protocol with built-in protection from duplicated, dropped, and out-of order packets. This is done by explicitly opening a connection between client and server and assigning each packet a sequence number. The client will reply to the server with an acknowledgment for every packet sent; if sequence numbers go missing, appear twice, or appear out of order to the client, the acknowledgment will not be sent, and the server can take appropriate action.

A TCP connection is established with a three-way handshake. Initially, the client sends a SYN request to the server, and the server replies with an ACK response, to which the client replies with an ACK reply. Similarly, a TCP connection is closed with a two-way handshake, where one party sends a FIN request to the other, which then replies with an ACK response.

In UDP packets, immediately following the IP header is an 8-byte UDP header (Table 13.7). A definitive description of UDP can be found in RFC 768.

UDP is the most basic data-carrying protocol that is valid for the Internet. It contains no protection against lost or duplicated packets, and therefore is not applicable to media that require high integrity. It is acceptable for live streaming audio and video formats.

In DNS packets, immediately following the UDP header (port 53) is a 12-byte DNS header (Table 13.8). A definitive description of DNS can be found in RFC 1035.

DNS is used primarily to resolve IP addresses from domain names; however, it can also be used to locate mail exchanges and so forth.

This first example uses WinPCap with the rvPacket wrapper to display all network traffic on a textbox. It is normal for network data to pass through the adapter faster than it can appear on-screen, so there may be some time lag between data passing through the network and what is displayed on-screen. The first step in developing this application is to download and install WinPCap from http://winpcap.mirror.ethereal.com, then to download rvPacket from http://network.programming-in.net/downloads/rvPacket.zip, and copy the DLL into your Windows system folder.

Create a new project in Visual Studio .NET, and draw a textbox named tbPackets with multiline set to true. Two buttons named btnStart and btnStop are required. VB.NET developers will need to add a reference to Microsoft.VisualBasic.Compatibility using Project→ Add References.

Click on the Start button and add the following code:

C#

private void btnStart_Click(object sender, System.EventArgs
e)
{
  short Qid;
  string packetBuffer;
  short openSuccess;
  short packetQueue;
  short packetLen;
  string rawAdapterDetails = "";
  int posDefaultAdapter;
  getAdapterNames(rawAdapterDetails);
  Adapter="\"; // default adapter
  openSuccess = openAdapter("\");
  if (openSuccess != ERR_SUCCESS)
  {
    MessageBox.Show(
    "Unable to start. Check WinPCap is installed");
    return;
  }
  while(true)
  {
    packetQueue = checkPacketQueue(Adapter);
    for (Qid = 1; Qid<packetQueue;Qid++)
    {
       packetBuffer = new
       StringBuilder().Append
       (' ',MAX_PACKET_SIZE).ToString();
       packetLen = getQueuedPacket(packetBuffer);
     packetBuffer = packetBuffer.Substring(0, packetLen);
     tbPackets.Text = tbPackets.Text +
             packetBuffer.Replace(""," ");
     tbPackets.SelectionStart = tbPackets.Text.Length;
     Application.DoEvents();
   }
   Application.DoEvents();
 }
}

VB.NET

Private Sub cmdStart_Click(ByVal eventSender As _
    System.Object, ByVal eventArgs As _
    System.EventArgs) Handles cmdStart.Click
Dim Qid As Short
Dim packetBuffer As String
Dim adapters() As String
Dim openSuccess As Short
Dim packetQueue As Short
Dim packetLen As Short
Dim rawAdapterDetails As String
Dim posDefaultAdapter As Short
rawAdapterDetails = Space(MAX_ADAPTER_LEN)
getAdapterNames(rawAdapterDetails)
posDefaultAdapter = _
rawAdapterDetails.IndexOf(ADAPTER_DELIMITER)
Adapter = rawAdapterDetails.Substring(0, posDefaultAdapter)
openSuccess = openAdapter(Adapter)
If openSuccess <> ERR_SUCCESS Then
 MsgBox("Unable to start. Check WinPCap is installed")
 Exit Sub
End If
Do
 packetQueue = checkPacketQueue(Adapter)
 For Qid = 1 To packetQueue
  packetBuffer = Space(MAX_PACKET_SIZE)
  packetLen = getQueuedPacket(packetBuffer)
  packetBuffer = packetBuffer.Substring(0, packetLen)
  tbPackets.Text = tbPackets.Text & Replace _
        (packetBuffer, Chr(0), " ")
  tbPackets.SelectionStart = Len(tbPackets.Text)
   System.Windows.Forms.Application.DoEvents()
  Next
  System.Windows.Forms.Application.DoEvents()
 Loop
End Sub

The code listed above performs two functions; first, detects all of the network adapters on the system, bearing in mind that computers can have more than one means of connecting to a network, either by modem, Ethernet, or some other system. The getAdapterNames returns a list of adapter names separated by a pipe character (“|”). Here the first default adapter is used.

Network traffic regularly arrives faster than it can be read and handled by an application; thus, the data is buffered internally in a linked-list structure. The rvPacket library has two functions for reading this buffer, checkPacketQueue and getQueuedPacket. As the names suggest, the former is a nonblocking function that retrieves the number of packets in the queue, and the latter will then read each packet in the queue sequentially. The queue is guaranteed not to grow in size between calls to checkPacketQueue, and no data on this buffer will be altered.

The threading model is primitive, using nothing more than a DoEvents call to maintain responsiveness for the user interface. This has the side effect of pushing CPU usage to 100%, which looks unprofessional in a consumer product. In a more polished version, proper threading should be used.

Although not strictly necessary, the adapter should be closed after use. If it is not closed before the application is destroyed, then a memory leak will result. More importantly, if two separate processes open the adapter at once, Windows will crash.

Click on the Stop button, and enter the following code:

C#

private void btnStop_Click(object sender, System.EventArgs e)
{
    closeAdapter(Adapter);
}

VB.NET

Private Sub btnStop_Click(ByVal sender As _
     System.Object, ByVal e As System.EventArgs) _
     Handles btnStop.Click
       closeAdapter(Adapter)
End Sub

Several API declarations have to be made to make the rvPacket library accessible. Insert this code directly after the form constructor:

C#

[DllImport("rvPacket.dll")]
public static extern short getAdapterNames (string s);

[DllImport("rvPacket.dll")]
public static extern short openAdapter (string Adapter);

[DllImport("rvPacket.dll")] public static extern short
checkPacketQueue(string Adapter);

[DllImport("rvPacket.dll")] public static extern short
getQueuedPacket(string s);

[DllImport("rvPacket.dll")] public static extern void
closeAdapter(string Adapter);

const short SIMULTANEOUS_READS = 10;
const short MAX_ADAPTER_LEN = 512;
const string ADAPTER_DELIMITER = "|";
const short MAX_PACKET_SIZE = 10000;
const short ERR_SUCCESS = 1;
const short ERR_ADAPTER_ID= 2;
const short ERR_INVALID_HANDLE= 3;
const short ERR_INVALID_ADAPTER= 4;
const short ERR_ALLOCATE_PACKET= 5;
string Adapter = "";

VB.NET

Private Declare Function getAdapterNames Lib _
        "rvPacket.dll" (ByVal s As String) As Short
Private Declare Function openAdapter Lib _
        "rvPacket.dll" (ByVal Adapter As String) As Short
 Private Declare Function checkPacketQueue Lib _
        "rvPacket.dll" (ByVal Adapter As String) As Short
 Private Declare Function getQueuedPacket Lib _
        "rvPacket.dll" (ByVal s As String) As Short
 Private Declare Sub closeAdapter Lib _
        "rvPacket.dll" (ByVal Adapter As String)

 Private Const SIMULTANEOUS_READS As Short = 10
 Private Const MAX_ADAPTER_LEN As Short = 512
 Private Const ADAPTER_DELIMITER As String = "|"
 Private Const MAX_PACKET_SIZE As Short = 10000
 Private Const ERR_SUCCESS As Short = 1
 Private Const ERR_ADAPTER_ID As Short = 2
 Private Const ERR_INVALID_HANDLE As Short = 3
 Private Const ERR_INVALID_ADAPTER As Short = 4
 Private Const ERR_ALLOCATE_PACKET As Short = 5
 Public Adapter As String

The rvPacket library is developed in unmanaged C++; therefore, these rather cryptic function declarations must be used, in the same way as they were required to access the Windows API. The calling conventions for each of the functions are identical: they all accept a string and return a number.

GetAdapterNames is used to retrieve a list of network adapters present on the system. One of these adapter names would be passed to openAdapter, which effectively begins the sniffing process on that network adapter.

CheckPacketQueue returns the number of packets that are currently held in the network card buffer. The GetQueued packet can then retrieve each of these packets one at a time.

CloseAdapter stops the sniffing process and frees up the adapter for any other process to use it. Immediately following the declarations are several constants that can be used within the code to better explain errors to users, and so forth.

Finally, C# programmers require the following namespaces:

C#

using System.Text;
using System.Runtime.InteropServices;

To test the application, make sure you are connected to an active network and that WinPCap and rvPacket have been installed. Run the program from Visual Studio .NET and press Start. If you open a browser and start using the Web, you will see the HTTP sent and received in the textbox (Figure 13.3).

Figure 13.3. Frame-layer packet sniffer with rvPacket.

The following example uses BeeSync’s packetX control (www.beesync.com) to illustrate the concept. There would be no problem in using rvPacket for this example, but packetX is a useful alternative to know how to use. The object of the example is to log packets that match a certain criterion. In this case, only TCP/IP traffic will be logged.

TCP/IP traffic can be isolated from raw network traffic by checking two bytes in the packet. In an IP packet, the IP header follows the frame header and, thus, will appear at the 14th byte in the packet. The first byte in the IP header will always be 69 when IPv4 is used with standard priority. The second byte to check is the protocol byte, the 10th byte in the IP header. This byte will always be 6 when TCP/IP is used.

You will need to have downloaded and installed both WinPCap and PacketX before starting to code this program. Start a new project in Visual Studio .NET, right-click on the toolbox on the left, and click Customize Toolbox (or Add/Remove Items in Visual Studio .NET 2003), click the COM tab, check PacketXCtrl Class, and press OK. Drag the new icon onto the form. Draw a List View control named lvPackets onto the form as well as a Start button named btnStart.

To start with, add a few column headers into the list view so that the results it displays will be evenly tabulated. Add the following lines of code to the load event:

C#

private void Form1_Load(object sender, System.EventArgs e)
{
  lvPackets.Columns.Add("From", lvPackets.Width / 3,
                          HorizontalAlignment.Left);
  lvPackets.Columns.Add("To", lvPackets.Width / 3,
                          HorizontalAlignment.Left);
  lvPackets.Columns.Add("Size", lvPackets.Width / 3,
                          HorizontalAlignment.Left);
  lvPackets.View = View.Details;
}

VB.NET

Private Sub Form1_Load(ByVal sender As System.Object, _
 ByVal e As System.EventArgs) Handles MyBase.Load
 With lvPackets
  .Columns.Add("From", .Width / 3, HorizontalAlignment.Left)
  .Columns.Add("To", .Width / 3, HorizontalAlignment.Left)
  .Columns.Add("Size", .Width / 3, HorizontalAlignment.Left)
  .View = View.Details
 End With
End Sub

The PacketX control will not start detecting packets until the Start method is called. This is to facilitate choosing nondefault adapters:

C#

private void btnStart_Click(object sender, System.EventArgs
e)
{
 axPacketXCtrl1.Start();
}

VB.NET

Private Sub btnStart_Click(ByVal eventSender As _
    System.Object, ByVal eventArgs As System.EventArgs) _
    Handles Command1.Click
  axPacketXCtrl1.Start()
End Sub

Unlike the polling mechanism of the rvPacket library, PacketX uses an event to notify the host application of the arrival of packets. The event delivers an object that effectively derives from System.EventArgs, yet contains a PacketClass object that contains information on the packet contents and the exact time (with microsecond accuracy) the packet was received.

The packet contents are stored in a byte array named Data. This byte array appears to .NET as a generic object; thus, to handle it without causing type cast errors, Option Strict Off must be added as the first line of the VB.NET code:

C#

private void axPacketXCtrl1_OnPacket(object sender,
AxPACKETXLib._IPktXPacketXCtrlEvents_OnPacketEvent e)
{
  short I;
  string thisPacket;
  string SourceIP;
  string DestIP;
  ListViewItem item = new ListViewItem();
    thisPacket = "";
  byte[] packetData = (byte[])e.pPacket.Data;
  for (I = 0;I<e.pPacket.DataSize - 1;I++)
  {
    thisPacket = thisPacket + Convert.ToChar(packetData[I]);
  }
  if (packetData[14] == 69 && packetData[23] == 6)
  {
    SourceIP = packetData[26] + "." +
      packetData[27] + "." +
      packetData[28] + "." +
      packetData[29];

    DestIP = packetData[30] + "." +
      packetData[31] + "." +
      packetData[32] + "." +
      packetData[33] + ".";

   item.SubItems[0].Text = SourceIP;
   item.SubItems.Add(DestIP);
   item.SubItems.Add(e.pPacket.DataSize.ToString());
   lvPackets.Items.Add(item);
  }
}

VB.NET

Private Sub axPacketXCtrl1_OnPacket(ByVal eventSender _
     As System.Object, ByVal e As _
     AxPACKETXLib.IPktXPacketXCtrlEvents_OnPacketEvent) _
    Handles axPacketXCtrl1.OnPacket
 Dim I As Short
 Dim thisPacket As String
 Dim SourceIP As String
 Dim DestIP As String
 Dim item As New ListViewItem()

 thisPacket = ""
 For I = 0 To e.pPacket.DataSize - 1
   thisPacket = thisPacket & Chr(eventArgs.pPacket.Data(I))
 Next
 If e.pPacket.Data(14) = 69 And e.pPacket.Data(23) = 6 Then
  SourceIP = e.pPacket.Data(26) & "." & _
             e.pPacket.Data(27) & "." & + _
             e.pPacket.Data(28) & "." & + _
             e.pPacket.Data(29)
  DestIP = e.pPacket.Data(30) & "." & _
           e.pPacket.Data(31) & "." & + _
           e.pPacket.Data(32) & "." & + _
           e.pPacket.Data(33)
   item.SubItems(0).Text = SourceIP
   item.SubItems.Add(DestIP)
   item.SubItems.Add(e.pPacket.DataSize)
   lvPackets.Items.Add(item)
  End If
End Sub

The actual network packet that is passed within the eventArgs or e parameter of the event takes the form of an object stored in e.pPacket.Data, which can be cast to a byte array (implicitly so, in the case of VB.NET). This array is examined for key bytes, first to filter out non-TCP/IP data and then to extract the Local and Remote IP addresses from the header. The extracted data is displayed on-screen in a list box.

To test this application, run it from Visual Studio .NET and wait for a TCP/IP connection to take place on the network. Alternately, simply opening a browser should generate a TCP/IP connection to the server hosting your browser’s home page.

The example shown in Figure 13.4 is one single HTTP request between two computers on a LAN. Note that it does not involve simply one packet for the request and one for the response, but a fair amount of handshaking takes place between client and server, before a connection is made. This may be worth knowing if, for instance, you were using a TCP trace to build up statistics on user browsing habits. You cannot equate the number of packets to the amount of Web pages or emails sent. It might be better to count occurrences of the string HTTP/1.1 or HELLO in outgoing packets on ports 80 and 25, respectively, in this instance.

Figure 13.4. Frame-layer packet sniffer with PacketX.

A busy network may produce an overwhelming number of packets, and it is likely that .NET will not be able to process 10 Mb of packets per second, as is commonplace on LANs. In this case, we can use hardware filters that are built into network cards to cope with high-volume traffic.

To detect only packets destined for the local machine, we can apply the directed packet hardware filter to the WinPCap driver by setting a parameter in the PacketX object with:

PacketXCtrl1.Adapter.HWFilter = 1

The default hardware filter is promiscuous mode, which will pass up every packet seen by the network adapter. The rvPacket library only operates in promiscuous mode. Wireless network cards cannot operate in promiscuous mode; therefore, a nonpromiscuous hardware filter (Table 13.9) must be applied for wireless devices.

WinPCap also has the capability to send and receive packets. This functionality can be accessed through Adapter.SendPacket, which could be useful for generating non-IP-based packets, such as ARP requests or raw server message block (SMB) data. These packets would not be routable over the Internet, but they may have applications within company networks.