Understanding WireShark
WireShark is one of the most popular network analyzers available. WireShark was once known by the name Ethereal, but due to copyright issues changed their name to WireShark. WireShark can be downloaded from the following web site:
WireShark supports a wide variety of operating systems. To use WireShark, choose the version for the operating system, then download and install that version.
Preparing the Browser
Most web browsers are configured to display a home page when the browser is first started. This home page will have an undesirable effect when attempting to analyze packets sent by the web browser. The homepage will cause a flurry of network packets to be sent when the web browser is first opened. This amounts to extra data being captured that has nothing to do with the web site being analyzed. To avoid this, set the web browser’s home page to “blank”. This can easily be done using the browser “Internet Options” menu in Internet Explorer, which is shown in Figure 2.1
Figure 2.1: Internet Explorer Options

As seen in Figure 2.1, Internet Explorer can be configured to use a blank homepage by clicking the “Use Blank” button.
To set the home page to blank in Firefox use the “Preferences” menu. This located under the general tab and called “Use Blank Page”.
Now that the browser is set up, WireShark can be started. When WireShark is started, it will appear similar to Figure 2.2
Figure 2.2: WireShark

Now that WireShark has been started, it is time to use it to monitor HTTP traffic. This will be covered in the next sections.
Select an Interface
Before packets can be captured with WireShark, WireShark must be told what interface the packets should be captured from. This will most likely be the Ethernet card. However, if a dial-up modem connection is being used, then it should be specified that as the interface. Select the “Interfaces...” option of the “Capture” menu. WireShark will now appear as the image in Figure 2.3.
Figure 2.3: Select an Interface

Once the correct interface is found, notice its “Capture” button next to the interface. As mentioned previously, the browser’s home page should be set to blank and the browser’s cache cleared. Once these steps have been preformed the “Capture” button can be pressed. This will begin the process of capturing packets.
Capturing Packets
Once the “Capture” button has been pressed, packet capture will begin. Capturing packets is the main task usually performed by a network analyzer. The term “capture” may be a bit misleading. The packets are left “as is” and are not taken out of the network stream. Rather the packets are “spied” upon.
These packets will contain the HTTP requests and responses being transferred between the web browser and the desired web server. While capturing packets, NetShark will appear as the image in Figure 2.4.
Figure 2.4: Capturing Packets

Now that packets are being captured the browser should be started. Proceed to the following URL:
Once the web page has completely displayed, close the web browser. Now select WireShark. WireShark will now appear as the image in Figure 2.5.
Figure 2.5: Captured Packets

As can be seen from Figure 2.5 there are quite a few packets! Almost all of them are of no importance to creating a bot. Sift through the unimportant packets using a filter.
Filtering Packets
Look at Figure 2.5. Notice the “Protocol” column? This column contains a few packets of the type HTTP. These are the packets that are of interest. We will filter out all other packets. To create a filter, click on the “Expression?” button. This will display the image in Figure 2.6.
Figure 2.6: Filter Options

From this window choose HTTP for the “Field Name” list, and “is present” from the “Relation” list. Once these two are chosen, click “OK”. This will return you to the packet list screen, seen in Figure 2.5.
At this point all of the packets are still visible. This is because no filtering has yet taken place. To use the filter, click the “Apply” button near the “Expression” button that was clicked to create the filter. Once the filter is applied, there will be considerably fewer packets. Figure 2.7 shows the filtered packet list.
There should be a total of three GET requests, which request the following documents.
Figure 2.7: Filtered to Only HTTP Packets

The “/” request was the first request.
Examining a HTTP Request
We will now examine an HTTP request in greater detail. Click on the first row, as seen in Figure 2.7. The middle pane should be resized to be larger so that the HTTP headers can be seen. This will result in Figure 2.8 appearing.
Figure 2.8: The Parts of an HTTP Request Packet

As can seen in Figure 2.8 the packet is broken into the following sections:
- Frame 9
- Ethernet II
- Internet Protocol (IP)
- Transmission Control Protocol (TCP)
- Hypertext Transfer Protocol (HTTP)
Of these, the only one that is important is the HTTP part of the packet. Clicking the plus (+) next to this section will expand it. After expanding, the HTTP part of the packet is seen as in Figure 2.9.
Figure 2.9: An HTTP Request

The HTTP headers for this GET request can be seen in Figure 2.9. As the book progresses, many of these HTTP headers will be explained. For example, consider the User-Agent header. This tells the web server what sort of browser is being used. For this example, Internet Explorer was used.
Examining an HTTP Response.
HTTP responses can also be examined using WireShark. Figure 2.10 shows the response packet from the logo GIF file.
Figure 2.10: An HTTP Response

As seen in Figure 2.10 there are a different set of headers that come back from the server. For example there is a header named Server, which tells what version of a web server I am running the HTTP Recipes site from. As seen in Figure 2.10, the HTTP recipes site is running Apache 2.0.
Reassembled PDU
Sometimes the packet will not arrive in one piece. Instead, the packet arrives as several Protocol Data Units (PDU). WireShark will try to reassemble these units back into a single packet. Such a packet is called a reassembled PDU. This packet can be seen on the second row of Figure 2.5. Selecting the reassembled PDU produces Figure 2.11.
Figure 2.11: A Reassembled PDU

When working with a reassembled PDU, the display will not be as nice as a regular packet. The headers of the response are in the bottom pane of Figure 2.11.












