4.Represent each hex character as an increasing power of 16 (160 through 163).

5.Multiply each base by exponent and add all individual products.

163	162	161	160
0	0	5	4

5*161 + 4*160 = 84

In the previous example, we are looking at the length field. We have 4 hex characters because the length is a 16-bit field. We really only need to label the two rightmost hex characters because they are non-zero. After we do this, we find we have a 4 in the 160 position; this is really the 1's position meaning we have 4*1 or 4. The next character of 5 is in the 161 position. So, we multiply 5*16 for a product of 80. We add these two products together to get the final result of 84.

TCP Header Length

Like the IP header, the TCP header can also have options. Also, like the IP header length, the TCP header length is found in a nibble that is a representation of 32-bit words. This value, like the IP header length value, must be multiplied by 4 to get the TCP header length. A TCP header with no options is 20 bytes long. The TCP header length is found in the high-order nibble of the 12th byte offset of the TCP header. This is an important value because it determines where the TCP header stops and where the TCP payload begins.

Here is standard output followed by the hex output from a TCP header with no TCP options:

15:43:40.705372 1.2.3.4.63220 > 4.3.2.1.139: S 776342897:776342897(0) win 3072

4500 0028 e34f 0000 3a06 e534 0102 0304

0403 0201 <f6f4 008b 2e46 0d71 0000 0000

5002 0c00 b85f 0000>

The TCP segment is delimited by the less than and greater than signs. The highlighted value is the TCP header length, and as expected, we find a 5. After we multiply that by 4, we get a standard TCP header of 20 bytes.

Now, look at the hex output for a TCP header with TCP options:

15:48:24.620314 1.2.3.4.3088 > 4.3.2.1:139 S 1212214992:1212214992(0) win 32120 <mss 1460,sackOK,timestamp 7748460 0,nop,wscale 0> (DF)

4500 003c 11a8 4000 4006 70c8 0102 0304

0102 0304 <0c10 008b 4840 eed0 0000 0000 a002 7d78 92b4 0000 0204 05b4 0402 080a 0076 3b6c 0000 0000 0103 0300>

You see that it has a TCP header length of 0xa, which is a decimal 10. This value multiplied by 4 indicates a TCP header length of 40 bytes. If you look at the standard TCPdump output before the hex dump, you see that this TCP header includes such options as maximum segment size of 1460, selective acknowledgement (sackOK), timestamp, a nop (no operation) to pad to a 4-byte boundary, and a window scale (wscale). These options need to be stored in the TCP header.

Increasing the Snaplen

Here's a question: Why do you only see 54 bytes of output in the following hex output displayed even though the default number of bytes capture is 68? Check it out:

4500 0054 064b 0000 4001 bc12 c0a8 8f05 c0a8 8f65 0800 620a 850a 0000 889f 4b39 510f 0100 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819

The answer is that TCPdump captures 14 bytes of the Ethernet frame header, yet it does not display them unless explicitly directed. To display the captured frame header use the command tcpdump –e:

20:55:48.520619 0:10:b5:39:c6:93 0:10:b5:39:c6:9a ip 102 192.168.143.5 > 192.168.143.101: icmp: echo request

There will be times that you will be interested in examining the frame header. One of the reasons for this would be to identify the source MAC address to try to determine where the packet came from—a host or perhaps a router.

In the previous output, which uses Ethernet encapsulation defined by RFC 894, the bolded text is a result of the –e option. First, you see the source and destination MAC addresses (source MAC of 0:10:b5:39:c6:93 and destination MAC address of 0:10:b5:39:c6:9a). You might be thinking that these are bogus MAC addresses because they are so close together, but they are genuine MAC addresses. These are two Compaq PCs ordered at the same time. The MAC addresses are followed by the type of packet that follows the frame header. Some of the types of traffic you are likely to see are IP, ARP, and RARP (reverse ARP). These fields are all stored in the frame header. The final displayed field is the length, in bytes, of the entire frame including the frame header and the data in the encapsulated frame header. In this case, it is a frame header of 14 bytes and a following IP datagram of 88 bytes to give 102. A value of 0x0800 in the type field indicates an IP datagram follows the frame header. The IP packet must be at least 46 bytes in length and the frame length information is not contained anywhere in the Ethernet RFC 894 frame header. The snapshot length, or snaplen for short, is the number of bytes that TCPdump collects. The default snaplen of 68 bytes is usually enough to capture the IP header, embedded protocol header, and some data. But, if there are many options, either IP header options or TCP options, all of the headers might not be captured.

If you want to increase the default snaplen, use the –s TCPdump command line option. As a test case, let's say we want to capture the entire datagram for each record we read or process on an Ethernet network. In this case, we need to increase the snaplen to the maximum size of the datagram plus the frame header. Ethernet has a maximum transmission unit of 1500. If you add 14 bytes for the frame header, the snaplen must be 1514 bytes—tcpdump –s 1514. Now, to check if we've collected the entire datagram, we run TCPdump with a snaplen of 1514:

4500 0054 064b 0000 4001 bc12 c0a8 8f05

c0a8 8f65 0800 620a 850a 0000 889f 4b39 510f 0100 0809 0a0b 0c0d 0e0f 1011 1213

1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

3435 3637

If we dump the collected record in hexadecimal, we find we've collected more than the default 54 bytes. The actual datagram length is found in the 2nd and 3rd bytes offset of the IP header. We discover a hex 54 in this field, which we recently computed is a decimal 84 bytes. And, we see that we've collected all 84 bytes.

Dissecting the Whole Packet

We have covered all the fundamentals required to dissect a packet. Okay, get the scalpel out and let's see if we can attempt a couple of IP packet dissections. Here's a short review of what we need to do to accomplish our dissection:

●Identify the embedded protocol in the packet. This is found in the 9th byte offset of the IP header.

●Determine what the embedded protocol is based on the value found.

●Identify where the header(s) stop(s), and examine the IP header length.

Tells where the IP header stops and the embedded protocol begins.

●Examine the embedded protocol header length

Tells where the embedded protocol payload begins.

One of the first steps in discovering what type of activity is embedded in the datagram is to discern the embedded protocol. Remember, you have an IP header and you will find the embedded protocol in the 9th byte offset into the IP header. Remember that the most common values you will see here are 01 for an embedded ICMP message, 06 for an embedded TCP segment, and a hex 11 or decimal 17 for an embedded UDP datagram.

After you've discovered this, you need to know how many bytes are in the IP header. Usually, this is 20 bytes, but it can be more if there are IP options. The IP header length field is found in the low-order nibble of the 0 byte offset of the IP header. Remember that this is expressed as a 32-bit word, so this value has to be multiplied by 4 to translate to bytes. If you count off this number of bytes into the IP header, you will discover where the IP header stops and the embedded protocol begins.

Next, you need to examine the embedded protocol. You'll have to get the proper header configuration for the protocol and translate the values that you find in the hexadecimal output. For UDP, the header length remains static at 8 and the payload follows. But, a header has a different format depending if the protocol is ICMP, TCP, or UDP.

TCP header lengths can vary, so you'll have to find the TCP header length field. This is 12 bytes offset into the TCP header, specifically, the high-order nibble. Again, like the IP header length, this is expressed as a 32-bit word and the value will have to be multiplied by 4 to convert it to bytes. This informs you where the TCP header stops and the payload starts.

Here is the hex dump of our specimen for dissection:

4500 0054 f23b 4000 ff01 d121 0102 0304

0403 0201 0000 9f00 d646 0000 b4cb 863a 56af 0e00 0809 0a0b 0c0d 0e0f 1011 1213

1415 1617 1819 1a1b 1c1d 1e1f 2021 2223

2425 2627 2829 2a2b 2c2d 2e2f 3031 3233

3435 3637 0000 4e00

Let's approach this in two different parts. In the first part, we'll attempt to discover the

embedded protocol and the length of the IP header. We see that the embedded protocol is ICMP because we have a 0x01 value (bolded) in the protocol field 9 bytes offset into the IP header. That indicates that an ICMP echo reply message follows the IP header (last 2 bytes of 0201). Because the IP header is 20 bytes, we discover where the IP header stops and the ICMP header and data begin. The ICMP header begins at the 2 bytes 0000 following the final 2 bytes of the IP header.

In our second step of dissection, we need to examine the ICMP message header. Remember that each individual character you see in the hex output represents a nibble or 4 bits. So, two hex characters are one byte. Use Figure 7.2 to assist in decoding the ICMP message.

Figure 7.2. ICMP header layout.

When examining ICMP, the ICMP header format can vary depending on the ICMP message type and code. The first two bytes of the ICMP header are really pertinent when trying to assess what type of ICMP message you have. These are the message type and message code fields. There are many possible different values for these fields that can be found at www.iana.org/assignments/icmp-protocols; however, we see a very common one in the above record. An ICMP message with a type of 00 and a code of 00 is an ICMP echo reply. The standard TCPdump

output for this output is as follows:

1.2.3.4 > 4.3.2.1: icmp: echo reply (DF)

Let's try one more exercise in packet dissection:

4500 0030 df3c 4000 8006 633f 0102 0304

0403 0201 0b64 0015 48f3 05b1 0000 0000

7002 2000 50b6 0000 0204 05b4 0101 0402

This is a different protocol than ICMP. What is of most interest is the embedded protocol destination port. This tells you the purpose of this particular packet. Although the TCP and UDP headers are different, they share a similar characteristic of having the source port in bytes 0 and 1 offset of the embedded header and the destination port in bytes 2 and 3 offset of the embedded header.

Once again, we find an IP datagram with a 20-byte IP header. But, this time we find that we have TCP as the embedded protocol as ascertained by looking at the bolded protocol field in the previous hex dump.

The significant piece of information that helps us assess the function of the TCP segment is the destination port. This is found in the bolded value of 0015 positioned in offset bytes 2 and 3 of the TCP header.

We determine that the decimal translation is port 21, which is ftp. The destination port field has