a hexadecimal value of 0015. To translate this to decimal, we find a 1 in the 161 position and a 5 in the 160 position. When these 2 values are added, we have 16 + 5, which gives us destination port 21.

So, we have some kind of ftp exchange. This is the beginning of the 3-way handshake so we have no payload.Yet, it helps to look at the TCP header length found in the high-order nibble of the 12th byte offset of the TCP header. A value of 7 is found here and this must be multiplied by 4 to figure out that there is a 28-byte TCP header. This means that there are TCP options; and examining the following standard output of TCPdump for the datagram, we see that there are options of maximum segment size (mss), two nops to pad 4-byte boundaries, and a selective

acknowledgement (sackOK):

18:26:48.888088 1.2.3.4.2916 > 4.3.2.1.21: S 1223886257:1223886257(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)

Freeware Tools for Packet Dissection

Now that you've manually labored your way through packet dissection, here are some excellent tools to help you out. Just to remind you of why we struggled with our own packet dissections at all, you will sometimes find packets that have been crafted and that are not analyzed accurately by tools whose interpretations rely on properly configured packets.

Ethereal

Ethereal is free, available for both Windows and UNIX, and is particularly user-friendly because it has a GUI to assist in navigating the capture and analysis. Ethereal can read TCPdump binary output captured using the –w option. It can also use TCPdump filters to selectively capture or display records. Ethereal is an especially useful tool because it allows you to analyze a captured record from many different perspectives.

Figure 7.3 shows a snapshot of Ethereal output. In the top screen, you see a highlighted record. If you move to the middle screen, you can view the frame header, the IP header, and the TCP header, including more information about many of the fields. Also, Ethereal is protocol-aware for many protocols and attempts to interpret the payload according to RFC and protocol specs.

Figure 7.3. Ethereal output.

tcpshow

Tcpshow is good at translating the header field values relieving you of having to know what field is where, computing exact lengths, and figuring out hex values. It also attempts to interpret the payload. If the payload is ASCII, it can be translated. But, there are also services such as NetBIOS that have additional layers of translation that are not done by tcpshow and the output is incoherent. Remember that unless you increase the default snapshot length of 68 bytes, most of the time you will not capture the entire datagram. This means that not all of the payload will be available for interpretation by tcpshow.

Tcpshow can be run by using the following command:

tcpdump -enx | tcpshow –nolink

This command reads TCPdump records from the network and feeds them to tcpshow. We use the TCPdump options of -enx to read the frame header for interpretation purposes (the –e option), not resolve hostnames (the –n option), and dump the output in hex (the –x option). The –nolink option in tcpshow says not to display the frame header information like MAC addresses. Here is some output from an ICMP record that was captured:

Packet 1
IP Header	4
Version:
Header Length:	20 bytes
Service Type:	0x00

Datagram Length:	40 bytes
Identification:	0xB5CB
Flags:	MF=off, DF=on
Fragment Offset:	0
TTL:	254
Encapsulated Protocol:	ICMP
Header Checksum:	0xB229
Source IP Address:	1.2.3.4
Destination IP Address:	4.3.2.1
ICMP Header	echo-reply
Type:
Checksum:	0xBC9C
ICMP Data
.<Q...........c.

As you can see, tcpshow provides a lot of assistance in interpreting a packet. It decodes the IP header, liberating you from figuring out field displacements, converting lengths to bytes, and converting hexadecimal to decimal—to name a few of the functions that it performs. And, it attempts to decode the embedded protocol header and data. In this case, the ICMP data is not ASCII-based so tcpshow's interpretation is not intelligible. Ethereal is a much better tool to use to interpret the payload because it is protocol-aware.

TCPdump –X Option

One final tool for payload interpretation is TCPdump itself.Versions of TCPdump later than 3.4 have a new -X option. This simply attempts to interpret payload from hex to ASCII characters. It actually does this for the entire packet, which is not appropriate for numeric-based fields.

But, if your goal is to interpret ASCII-based payloads, this works well without the use of additional tools such as Ethereal or tcpshow. Here is an example of the output from running TCPdump with the –X option:

17:21:53.457019 1.2.3.4.ftp > 4.3.2.1.1607: P 1:81(80) ack 1 win 32120 (DF) [tos 0x10]

0x0000	4510	0078	1691	4000	4006	6b93	0102	0304	E..x..@.@.k.....
0x0010	0403	0201	0015	0647	a940	1471	309a	93ee	...e...G.@.q0...
0x0020	5018	7d78	14fa 0000		3232	3020	7665	7262	P.}x....220.verb
0x0030	6f20	4654	5020 7365		7276	6572	2028	5665	o.FTP.server.(Ve
0x0040	7273	696f	6e20 7775		2d32	2e35	2e30	2831	rsion.wu-2.5.0(1
0x0050	2920	5475	6520 5365		7020	3231	2031	363a	).Tue.Sep.21.16:
0x0060	3438	3a31	3220 4544		5420	3139	3939	2920	48:12.EDT.1999).
0x0070	7265	6164	792e 0d0a						ready...

If you look at the rightmost column, you can see the interpretation of the data that has been passed using ftp. You can also see from the first two lines of this column that the header interpretations are incorrect because these are numeric, not ASCII-based values.