Monitoring Ethernet Network Activity With NDIS Drivers
A Technical Report
Technical Expertise Level :
Intermediate
Requires knowledge of
: C, Networking concepts, and basic knowledge of drivers.
INDEX
The paper targets on providing a basic understanding of NDIS and how applications can interact with a driver and make the best use of the driver. The paper also presents a case study of an application that uses the sample driver (PACKET.SYS) for the purpose of monitoring a network. This paper rather than helping a programmer develop network drivers assists him in using one such driver.
Writing device drivers has been a fascination for most system programmers from the time computers were invented. Drivers are developed by programmers to fulfill the needs of a particular application. This has led to the development of a large number of different classes of drivers viz. printer drivers, file system drivers and so on. Furthermore device drivers very specific to an application, has also been developed which resulted in developing different kinds of drivers belonging to the same class. With the advent of the Internet, writing network drivers has become the center of attraction in the field of driver development. To aid the development of network device drivers Microsoft came out with the Network Device Interface Specification (NDIS) library supplied with the Windows NT operating system.
A device driver is the glue between the Operating system and its input/output devices. Drivers act as translators, converting the generic requests received from the Operating System into commands that specific peripheral controllers can understand.
A Network Interface Card (NIC) is a physical device that acts as a gateway through which data frames are transmitted and received by any machine in a network. A NIC is called with different names in different types of networks. For example, in an Ethernet network a NIC is called as an Ethernet Interface Card, similarly in a token ring network it is called as a token ring interface card, etc.
The Network Driver Interface Specification describes an interface by which one or more NIC drivers communicate with one or more overlying protocol drivers and the operating system. NDIS provides a full abstraction for the network driver development. The NIC drivers can rely upon the NDIS for all the external functions including communication with protocol drivers, registering and intercepting NIC hardware interrupts and communicating with underlying NICs.
The NDIS library (NDIS.SYS) provides a fully abstracted interface to which a NIC driver is written. The library exports all NT Kernel-mode functions that can be used for NIC driver development. The library also takes care of all the Operating system specific tasks and also maintains binding and state information about all underlying NIC drivers.
· Single NIC Driver
· NDIS Library
· Symmetric Multiprocessor support
· Loopback Support
· Multiprotocol Driver Support
· Administration
· Types of Send
· Options Flags
· Full Duplex Operation
· ARCNET and WAN support
The three types of drivers supported by Windows NT are:
· Network Interface card (NIC) drivers.
· Intermediate Protocol drivers.
· Upper-level protocol drivers.
The figure illustrates the Windows NT network driver components.
Network Interface Card drivers:
NIC drivers manage the Network interface card (NIC). NIC drivers interface directly to the hardware (NIC) at its lower edge and at their upper edge these provide an interface that helps the upper level drivers to:
· Send and recieve packets.
· Reset NIC
· Halt the NIC.
· Query NIC.
· Set operational characteristics of NIC.
NIC drivers are of two types namely:
· Miniport DriversMiniport drivers implement the hardware specific operations necessary to manage a NIC, including sending and receiving data on NIC. Miniport drivers do not call operating system routines directly instead they call functions exported by the NDIS.
· Full NIC DriversFull NIC drivers manage both hardware-specific as well as operating system specific tasks which are usually done by NDIS. Full NIC drivers have to also maintain binding information for indicating received data.
Intermediate Protocol Driver
Intermediate Protocol driver interface lies between the legacy protocol driver and miniport drivers. To the upper level transport driver an intermediate driver looks like a miniport driver. To the miniport driver it looks like a protocol driver. The main reason for using an intermediate protocol driver is for media translation between an existing transport driver and the miniport managing new media type unknown to the transport driver.
Upper Level Protocol Driver
An upper level protocol driver implements a TDI interface or another application-specific interface to provide services to its users. Such a driver allocates packets, copies data into the packets and sends the packets to the lower level driver by calling the NDIS. It also provides a protocol interface at its lower level to receive packets from the next lower level driver.
All drivers that are written under Windows NT must have a DriverEntry function that acts as an entry point to the driver. The other functions in the driver are known to the application only through the DriverEntry routine. An application calls functions such as CreateFile, ReadFile, etc that in turn call the NT I/O manager that generates an IRP (input/output Request Packet) corresponding to every function call. Under Windows NT, almost all I/O is packet-driven. Each I/O is described by a work order that tells the driver what to do and tracks the progress of the request through the I/O subsystem. These work orders take the form of a data structure called an I/O Request Packet (IRP). This IRP in turn invokes the entry point present in the driver for performing the particular operation.
The following sections deal with the monitoring of an Ethernet network using a NDIS sample driver.
Packet monitoring implies capturing all packets that travel in the LAN. This can be achieved in an Ethernet Network because of its broadcasting nature. That is any packet sent over an Ethernet Network is broadcasted to all machines in the network. The Ethernet card in every machine checks whether the particular packet is destined to it, if so accepts it else rejects it. This basic functionality of an Ethernet Network is exploited to capture all packets that travel through the network. The Ethernet card can be placed in a number of modes using drivers and can be used to capture packets as desired. One such sample driver that aids in placing the Ethernet card in a desired mode is the PACKET.SYS that comes along with the Microsoft Windows NT Device Development Kit (DDK).
The various modes in which an Ethernet card can be placed is as follows:
· Broadcast.
· Multicast.
· Directed.
· Promiscuous.
Broadcast: A frame that is to be sent to all machines in the network is broadcasted over the network with the destination address 0xffffff. This is supposed to be the broadcast address for the frame. Any card that is placed in the broadcast mode accepts frames with this destination address. Usually all cards will be configured to accept broadcast frames.
Multicast: A frame that is to sent to a particular set of machines is sent as a multicast frame with a specified multicast address as its destination address. These sets of machines constitute a multicast group. Thus any machine that is a member of the multicast group will accept the frame with the multicast destination address. Even though a card is not a part of the multicast group it can programmatically be placed in the multicast mode to accept all multicast frames.
Directed: A frame that is destined to a particular machine will have the destination machine's physical address (Ethernet address) specified as its destination address. The machine with that physical address will accept the frame while all the others will reject it. The card can also be set to only receive directed frames programmatically.
Promiscuous: Any card when placed in this mode accepts any packet that comes to it. This mode along with the broadcasting nature of the Ethernet is the key to the packet monitoring application.
The PACKET.SYS sample driver helps to place the network card in all the above mentioned modes. The application with the aid of the PACKET.SYS places the card in the promiscuous mode to capture all the packets that travel in the network.
The sample PACKET.SYS comes along with the NT DDK. This driver helps to place the network card in any mode desired and also allows applications to send and receive packets through and from the network. The driver sample apart from the sys file also provides a DLL (PACKET32.DLL) through which an application communicates with the driver.
How our application communicates with the PACKET.SYS?
The diagram above clearly depicts the way our application interacts with the PACKET.SYS driver. The Application calls the functions in the DLL, which in turn calls the entry points in the PACKET.SYS driver. The driver uses the NDIS.SYS exported functions to communicate with the Network Interface Card.
How Our Application uses PACKET32.DLL?
The application uses the driver to read all packets that come to the NIC. An example of how this could be done is as shown below
The structures used in the above process are listed below.
typedef struct _ADAPTER
{
// holds the handle that is returned by the CreateFile method.
HANDLE hFile;
// Holds the symbolic link name of the driver.
TCHAR SymbolicLink[MAX_LINK_NAME_LENGTH];
} ADAPTER, *LPADAPTER;
typedef struct _PACKET
{
// Holds the handle to the event that is associated with the adapter object.
HANDLE hEvent;
// The OVERLAPPED structure contains information used in
// asynchronous input and output
OVERLAPPED OverLapped;
// Buffer that holds the data sent or received.
PVOID Buffer;
// Length of the Buffer.
UINT Length;
} PACKET, *LPPACKET;
typedef struct _CONTROL_BLOCK
{
// Pointer to the Adapter object.
LPADAPTER hFile;
// handle to the event.
HANDLE hEvent;
// Name of the driver as registered in the registry.
TCHAR AdapterName[64];
// Buffer where the received packet data is stored.
HANDLE hMem;
LPBYTE lpMem;
// Buffer where the packet data to be sent is stored.
HGLOBAL hMem2;
LPBYTE lpMem2;
// Specifies the Packet length.
ULONG PacketLength;
// Specifies the Last read packet size.
ULONG LastReadSize;
// Specifies the Buffer length.
UINT BufferSize;
} CONTROL_BLOCK, *PCONTROL_BLOCK;
The implementation code begins here.
// Variables used in the patch code.
CONTROL_BLOCK cbAdapter;
// Get the Adapter name from the registry.
1. ULONG NameLength=64;
2. PacketGetAdapterNames(
3. CbAdapter.AdapterName,
4. &NameLength
5. );
6. //reserve 1514 bytes, maximum frame size.
7. CbAdapter.BufferSize=1514;
8. // Allocate and lock the memory buffers to send and receive packets.
9. CbAdapter.hMem=GlobalAlloc(GPTR, 1514);
10. CbAdapter.lpMem=(LPBYTE)GlobalLock(CbAdapter.hMem);
11. CbAdapter.hMem2=GlobalAlloc(GPTR,1514);
12. CbAdapter.lpMem2=(LPBYTE)GlobalLock(CbAdapter.hMem2);
13. //Open the underlying adapter for retrieving packets.
14.CbAdapter.hFile=(ADAPTER*)PacketOpenAdapter(CbAdapter.AdapterName);
15. // OpenAdapter failed.
16. if (CbAdapter.hFile = = NULL)
17. {
18.
AfxMessageBox("Open Adapter failed");
19. }
20. // A void pointer that receives the packet pointer returned by PacketAllocatePacket.
21. PVOID Packet;
22. //Set Filter for the non-selective mode.
23. Filter=NDIS_PACKET_TYPE_PROMISCUOUS;
24. //set the card in Promiscous mode.
25. PacketSetFilter(
26. CbAdapter.hFile,
27. Filter
28. );
29. // Allocate buffer to receive the packet data.
30. Packet=PacketAllocatePacket(CbAdapter.hFile);
31. // Initialize the packet receive buffer.
32. if(Packet != NULL)
33. {
34.
PacketInitPacket(
35.
(PACKET *)Packet,
36.
(char *)pdData[nCurrentWriteLocation].pData,
37.
1514
38. );
39. // Read the packet from the Underlying driver.
40. PacketReceivePacket(
41. CbAdapter.hFile,
42. (PACKET *)Packet,
43. TRUE,
44. &pdData[nCurrentWriteLocation].nPacketLength
45. );
The above patch of code clearly describes how the application uses the PACKET.SYS driver to place the Ethernet Interface Card in promiscuous mode to capture all the packets that travel through the network.
CODE ANALYSIS:
(1-5):
These lines call the function PacketGetAdapterNames in the DLL to get the name of the driver as registered in the registry.
Lines (7-13):
This piece of code initializes all the variables and buffer areas of the Adapter object. The also lock the global buffers that have been allocated.
Lines (14-19):
This piece of code calls the PacketOpenAdapter function of the DLL, which in turn calls the CreateFile method there by invoking the corresponding entry point in the driver. This opens the adapter for subsequent read and write operations.
Lines (23-28):
This piece of code calls the PacketSetFilter function in the DLL that places the Ethernet Interface Card (EIC) in the desired mode. In this case the filter is set to the promiscuous (non-selective) mode. This function in turn calls the DeviceIoControl method to set the card in the desired mode.
(31-38):
This piece of code calls the PacketInitPacket function in the DLL to initialize the Packet object. This packet object is the one that receives all packet data obtained from the network.
(40-45):
This piece of code calls the PacketReceivePacket function in the DLL that in turn calls the ReadFile method to read the data received by the EIC from the network.
The above given piece of code clearly describes how the sample driver PACKET.SYS can be used by an application to place the EIC in the desired mode, send and receive packets.
The various function definitions as provided in the Packet32.dll that are used by our application are as follows:
ULONG
PacketGetAdapterNames(
PTSTR pStr,
PULONG BufferSize
)
{
HKEY SystemKey;
HKEY ControlSetKey;
HKEY ServicesKey;
HKEY NdisPerfKey;
HKEY LinkageKey;
LONG Status;
DWORD RegType;
// Open the Key HKEY_LOCAL_MACHINE,
Status=RegOpenKeyEx(
HKEY_LOCAL_MACHINE,
TEXT("SYSTEM"),
0,
KEY_READ,
&SystemKey
);
if (Status == ERROR_SUCCESS) {
// Open the key currentcontrolset
Status=RegOpenKeyEx(
SystemKey,
TEXT("CurrentControlSet"),
0,
KEY_READ,
&ControlSetKey
);
if (Status == ERROR_SUCCESS) {
// Open the key Services
Status=RegOpenKeyEx(
ControlSetKey,
TEXT("Services"),
0,
KEY_READ,
&ServicesKey
);
if (Status == ERROR_SUCCESS) {
// Open the key Packet.
Status=RegOpenKeyEx(
ServicesKey,
TEXT("Packet"),
0,
KEY_READ,
&NdisPerfKey
);
if (Status == ERROR_SUCCESS) {
// Open the key Linkage.
Status=RegOpenKeyEx(
NdisPerfKey,
TEXT("Linkage"),
0,
KEY_READ,
&LinkageKey
);
if (Status == ERROR_SUCCESS) {
// Open the key Export.
Status=RegQueryValueEx(
LinkageKey,
TEXT("Export"),
NULL,
&RegType,
(LPBYTE)pStr,
BufferSize
);
// Close all the keys that have been opened so far.
RegCloseKey(LinkageKey);
}
RegCloseKey(NdisPerfKey);
}
RegCloseKey(ServicesKey);
}
RegCloseKey(ControlSetKey);
}
RegCloseKey(SystemKey);
}
return Status;
}
The above function PacketGetAdapterNames retrieves the name of the driver as registered in the registry.
1. PVOID
2. PacketOpenAdapter(
3. LPTSTR
AdapterName
4. )
5. {
6. LPADAPTER lpAdapter;
7. BOOLEAN
Result;
8. ODS("Packet32: PacketOpenAdapter/n");
// allocates global memory for the adapter object.
9. lpAdapter=(LPADAPTER)GlobalAllocPtr(
10. GMEM_MOVEABLE | GMEM_ZEROINIT,
11. sizeof(ADAPTER)
12. );
13. if (lpAdapter==NULL) {
14. ODS("Packet32: PacketOpenAdapter GlobalAlloc Failed/n");
15. return NULL;
16. }
// Copy the name into the symbolic link member.
17. wsprintf(
18. lpAdapter->SymbolicLink,
19. TEXT(".//%s%s"),
20. DOSNAMEPREFIX,
21. &AdapterName[8]
22. );
// Defines an MS-DOS name for the device.
23. Result=DefineDosDevice(
24. DDD_RAW_TARGET_PATH,
25. &lpAdapter->SymbolicLink[4],
26. AdapterName
27. );
28. if (Result)
29. {
30. // Creates and returns a file handle for the specified device.
31. lpAdapter->hFile=CreateFile(lpAdapter->SymbolicLink,
32. GENERIC_WRITE | GENERIC_READ,
33. 0,
34. NULL,
35. CREATE_ALWAYS,
36. FILE_FLAG_OVERLAPPED,
37. 0
38. );
39. if (lpAdapter->hFile != INVALID_HANDLE_VALUE) {
40.
return lpAdapter;
41.
}
42. }
43. ODS("Packet32: PacketOpenAdapter Could not open adapter /n");
44. GlobalFreePtr(
45. lpAdapter
46. );
47. return NULL;
48. }
The above diagram flow of a function call from the application. This applies to all other functions used to interact with the driver. The function PacketOpenAdapter defines a new DOS device name for the device and calls the CreateFile method to create or open a communication device and get a handle to the device. This function is called from the application prior to sending or receiving packets. The CreateFile method invokes the entry point specified by the IRP_MJ_CREATE in the driver, which calls the NDIS library, exported function NdisOpenAdapter to open the Adapter.
PVOID
PacketAllocatePacket(
LPADAPTER AdapterObject
)
{
LPPACKET lpPacket;
// Allocates memory for the Packet object.
lpPacket=(LPPACKET)GlobalAllocPtr(
GMEM_MOVEABLE | GMEM_ZEROINIT,
sizeof(PACKET)
);
if (lpPacket==NULL) {
ODS("Packet32: PacketAllocateSendPacket: GlobalAlloc Failed/n");
return NULL;
}
// Create an event that will be signaled when the operation is over.
lpPacket->OverLapped.hEvent=CreateEvent(
NULL,
FALSE,
FALSE,
NULL
);
if (lpPacket->OverLapped.hEvent==NULL) {
ODS("Packet32: PacketAllocateSendPacket: CreateEvent Failed/n");
GlobalFreePtr(lpPacket);
return NULL;
}
return lpPacket;
}
The above function PacketAllocatePacket allocates memory for the packet object and calls the CreateEvent function to create an event that is associated with the particular file handle.
VOID
PacketInitPacket(
LPPACKET lpPacket,
PVOID Buffer,
UINT Length
)
{
// Set packet object's buffer to the buffer.
lpPacket->Buffer=Buffer;
// Set packet object's buffer Length to the buffer Length.
lpPacket->Length=Length;
}
This function sets the packet object's buffer to the buffer pointer that is passed.
BOOLEAN
PacketReceivePacket(
LPADAPTER AdapterObject,
LPPACKET lpPacket,
BOOLEAN Sync,
PULONG BytesReceived
)
{
BOOLEAN Result;
// Set offset value to 0.
lpPacket->OverLapped.Offset=0;
lpPacket->OverLapped.OffsetHigh=0;
if (!ResetEvent(lpPacket->OverLapped.hEvent)) {
return FALSE;
}
// Call ReadFile to read a packet.
Result=ReadFile(
AdapterObject->hFile,
lpPacket->Buffer,
lpPacket->Length,
BytesReceived,
&lpPacket->OverLapped
);
if (Sync) {
// They want to wait
Result=GetOverlappedResult(
AdapterObject->hFile,
&lpPacket->OverLapped,
BytesReceived,
TRUE
);
}
else
{
// They don't want to wait, they will call PacketWaitPacket to get
// The real result
//
Result = TRUE;
}
return Result;
}
The function calls the driver's appropriate entry point to read a packet from the network and place it in the buffer specified. This is accomplished by calling the ReadFile method with the handle returned by the CreateFile method.
These are the various routines that are useful towards packet monitoring using the driver PACKET.SYS. Note that no driver specific implementation details have been provided. This section deals only with how an application can be written to monitor all network activity by using the NDIS sample driver PACKET.SYS.
The above section describes how all the packets in an Ethernet network can be captured. Our idea is not only to capture all packets but also to monitor the Internet activity in the network, which means that we have also to identify packets carrying HTTP requests. This requires knowledge about the Ethernet frame structure and how IP, TCP/UDP packets are encapsulated in a frame. This section describes how packets are identified as TCP/IP packets, how HTTP requests are identified and how URL information in a frame is obtained.
To transmit data across a layered network we pass data from our application to a protocol on a protocol stack. After that protocol finishes with your data it passes the data to the next protocol on the stack. As the data passes passes through each layer, the protocols on the stack encapulates the data for the next lower level in the stack. Encapsulation, therefore, is the process of storing your data in the format required by the lower level protocol in the stack.
So we see that the application module encapsulate data from the user in an application message. TCP module encapsulates the application data and attaches the TCP header and sends it to the next layer. As the data passes through IP module in the network layer, it formats the TCP segment into an IP datagram or packet. The Ethernet driver formats the data from the IP module and places the data into an Ethernet frame. This explains how a frame encapsulates an IP datagram and further how the IP packet encapsulates TCP/UDP data. To identify an HTTP request first we have to identify a packet as a TCP/IP packet, check whether it is a TCP packet or not and finally identify whether it is an HTTP request.
To identify a packet as a TCP/IP packet we have to first have a look at the Ethernet frame structure
The Ethernet frame contains a 14-byte header followed by data.
The fields in the Ethernet header are:
· Destination address (6 Bytes).
· Source address (6 Bytes).
· Frame type (2 Bytes).
As the name suggests the destination address field specifies the destination of the Ethernet frame. Similarly the source address field specifies the source address of the frame. The frame type field is the field of our interest. This field identifies the overlying protocol of the frame.
If the packet is a valid IP packet then the value of Frame type field (13th and 14th bytes) will be 08 0016.
After identifying a packet as a TCP/IP packet, our next duty is to find out whether the packet is a TCP packet or any other packet. Since any HTTP request goes as only TCP request we can ignore other packets. To find out whether the packet is a TCP packet we have to parse the IP header. The IP header is shown below.
The important fields in the IP header are:
· Header Length (4 Bits) and Version number (4 Bits)
· Total Packet Length (2 Bytes).
· Protocol to be used as the data passes upwards to the transport layer. The following table specifies the protocol field values for the common TCP/IP protocols that use IP.
|
Protocol
|
Value(Decimal)
|
|
TCP
|
6
|
|
UDP
|
17
|
|
ICMP
|
1
|
|
IGMP
|
2
|
· Header Checksum (2 Bytes).
· Source IP (4 Bytes).
· Destination IP (4 Bytes).
Thus a value of 06 in the protocol field of the IP header specifies that the packet is TCP packet.
After identifying a packet as a TCP packet, we have to find out whether the packet is an HTTP request packet. To find out whether a packet contains an HTTP request we have to examine the TCP header. The TCP header is shown below.
The important fields in the TCP header are
· Source Port (2 Bytes).
· Destination Port (2 Bytes).
· Sequence Number (4 Bytes).
· Acknowledge Number (4 Bytes).
· Hlen, Reserved and Code Bits (2 Bytes).
· Window (2 Bytes).
· Checksum (2 Bytes).
· Urgent Pointer (2 Bytes).
Of the above mentioned fields in the TCP header, the fields of our interest are the source and the destination port fields. These fields specify the port to which a connection is established. Various services of the TCP like the HTTP, FTP, etc use specific port numbers to render their services.
For an HTTP service the port number would be 00 8010 or 00 5016. If the source port field contains the value of 80 (HTTP port number) then the packet is an HTTP response packet. If the destination port field is 80 then the packet is HTTP request packet.
Now that we have found that the packet is an HTTP reqeust packet, it is fairly easy to get the URL contained in the data part of the packet.
Any request we type in a browser goes to the HTTP server as a GET or a POST request. The browser attaches other browser-related information and sends the packet to the corresponding HTTP server. The whole information including the URL of the page requested is encapsulated with in the data part of the packet. Thus just by parsing the data part of the packet we can obtain the URL. The general format of how the URL appears in the data part of the packet is:
GET / HTTP/1.0
The above URL is for the default page of any site we have entered in the browser. If we request any other page in the site or click on any of the links provided in that page then the requested page is also placed in the GET request. For example consider that we request a page sample.html, then the URL appears as:
GET /sample.html HTTP/1.0
Thus by searching for the GET string in the data part of the packet we can obtain the URL requested.
In the promiscuous mode the driver captures all packets that come to the network card. If the network traffic is very high then there are chances of losing packets without capturing them. This has to be taken into consideration. The driver has been implemented in NDIS version 3.0. The driver works fine under Windows NT while does not work with Windows 95 since Windows 95 supports only NDIS V 2.1 and NDIS V 3.1.
ISSUES RELATED TO WINDOWS CE
The NDIS implementation on Windows CE is a subset of the NDIS 4.0 under Windows NT. The code written for Windows NT driver will work under Windows CE but there are a lot of issues that have to be taken into consideration. Under Windows CE the drivers are compiled as DLLs unlike .SYS files under Windows NT. Moreover CE does not provide built-in support for DMA and allocation of contiguous blocks of memory. Further more when writing NDIS drivers for CE the programmers have to take into consideration the power management. That is they have to provide some additional code for power management.
The paper's main focus is on how we can use a NDIS driver to monitor network activity. The paper also lists patches of code from the application that uses the sample driver exported functions to place the network interface card in a non-selective mode there by enabling capturing of all data packets that come to the NIC. The paper also gives the code listing of all functions present in the Packe32.dll that are used by our application. This paper as such does not help the reader to develop network drivers using NDIS but helps the reader understand how an application can communicate with drivers. The paper also throws light on how an Ethernet frame is structured, how IP datagrams are encapsulated within Ethernet packets, how TCP packets are encapsulated within the IP datagram and finally how to extract the URL from an HTTP request packet.
------------------------------------------------------------------------------------------------------------
Copyright Notice:
2002 California Software Labs. All rights Reserved. The contents on the document are not to be reproduced or duplicated in any form or kind, either in part or full, without the written permission of California Software labs. Product and company names mentioned here in are the trademarks of their respective companies.
6651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
