Manual Network Packet Analysis

One of the essential skills that an analyst or a forensics investigator has to be equipped with is interpreting hexadecimal raw files. Doing a manual analysis of network packets without any tools would be a good start to get yourself comfortable with the hexadecimal representation of the files, and of course, it will make you understand the network traffic better and get a sense of what a normal traffic would look like inside your network.

NOTE: I expect you to be familiar with converting hexadecimal to decimal and vice versa, if not I suggest you to take a look at this tutorial https://www.tutorialspoint.com/how-to-convert-hexadecimal-to-decimal

The Frame Anatomy

A frame is a container of a single network packet that is ready to be transmitted into the network medium or just been received.

Encapsulation of application data descending through the layers. https://en.wikipedia.org/wiki/Internet_protocol_suite

Inside the frame which is a layer-2 data unit, we expect to find a frame header that encapsulates a packet, which is a layer-3 data unit (usually, IP) that contains a layer 3 header encapsulating a segment, which is a layer-4 data unit (TCP/UDP) that consists of a header that may encapsulate a payload (data). I presume that you have the necessary networking background so I’ll not explain the OSI layers.

Some Useful Tips

• 1 byte = 8 bits
• 1 byte = 1 octet
• 4 bits = 1 nibble = 1 hex character.
• You can always use this site hpd.gasmi.net to make sure of your interpretation.
• Always refer to the RFCs, it may be overwhelming at first but believe me, it is the best resource out there.
• I suggest you read and do the labs of the Practical Packet Analysis book by Chris Sanders. It’ll get you very comfortable using Wireshark to analyze network traffic. NOTE: The hexadecimal analysis is out of the scope of this book.

Ethernet Frame

The very first bunch of hex characters (usually, 14 bytes) that you’ll see in any raw packet belong to the ethernet header. In the IEEE 802.3 standard documentation, you will find many fields but in your real live captures, you may not be able to see all of them because some of the fields such as Preamble and SFD are being used for establishing synchronization in layer 1 so, they never go to the memory. Normally, you’ll see it like this:

Basic Ethernet Layer 2 Frame Formate

• Destination MAC Address: 6-bytes that represents the 48-bit destination MAC address. NOTE: an ff ff ff ff ff ff destination MAC means that this is a broadcast message which will be sent to all the devices in the broadcast domain.
• Source MAC Address: 6-bytes that represents the 48-bit source MAC address.
• Type: A 2-bytes number that represents the protocol that has been used to send that specific frame. Mostly, it’ll be 08 00 for IPv4 and 86 dd for IPv6 you can find a list of the protocol types here https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml
• Data: A variable-length field between 46 to 1500 bytes that contain the encapsulated data from the higher layers.
• Frame Check Sequence (FCS): 4-bytes that are being used for detecting errors in the frame. Those 4 bytes represent the frame trailer (located after the data).

For example, let's try to analyze this simple packet and figure out what information it contains:

0x0000   00 21 29 66 71 95 00 25   b3 bf 91 ee 08 00 45 00
0x0010   00 3c 72 8d 00 00 80 01   00 00 0a 0a 00 03 c0 a8
0x0020   00 80 08 00 4d 36 00 01   00 25 61 62 63 64 65 66
0x0030   67 68 69 6a 6b 6c 6d 6e   6f 70 71 72 73 74 75 76
0x0040   77 61 62 63 64 65 66 67   68 69

The first 6 bytes are the destination MAC address 00 21 29 66 71 95 followed by another 6 bytes representing the sender MAC address 00 25 b3 bf 91 ee . the first 3 bytes of the MAC address represents the OUI (Organizationally Unique Identifier) which is a unique identifier for each manufacturer followed by another 3 bytes that represent the HUI (Host unique identifier) which is a unique identifier for each NIC per manufacturer. so,

• The Destination Mac: 00:21:29:66:71:95
• The Destination OUI: 00:21:29
• The Destination HUI: 66:71:95
• The Source Mac: 00:25:b3:bf:91:ee
• The Source OUI: 00:25:b3
• The Source HUI: bf:91:ee

The following 2 bytes are 08 00 which indicates that IPv4 was used for sending the packet.

Hence, we can conclude that the following bytes are the data (the Layer 3 packet).

IPv4 Packet

There are two types of IP protocol IPv4 and IPv6. For simplicity, let’s analyze the IPv4 now and we may analyze the IPv6 in another story.

According to the RFC 791 — Internet Protocol, section 3.1: Internet Header Format a summary of the contents of the internet header follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTE: each tick mark represents a one-bit position.

• Version: (4 bits, 1 hex character) indicates which type of the IP protocol was used. 4 indicates IPv4 and 6 indicates IPv6
• IHL (Internet Header Length): (4 bits, 1 hex character) indicates the header length in 32-bit words, in other words, how many 4-bytes are occupied by the header? NOTE: The minimum value for this field is 5, which indicates a length of 5 × 32 bits = 160 bits = 20 bytes. As a 4-bit field, the maximum value is 15, this means that the maximum size of the IPv4 header is 15 × 32 bits, or 480 bits = 60 bytes.
• Type of Service: (8 bits, 2 hex characters) has had various purposes over the years and has been defined in different ways by five RFCs and it’s very rarely used today so we’ll not discuss it here. You can refer to Section 22 in RFC 3168 for the historical definition for the IPv4 TOS octet.
• Total Length: (16 bits, 4 hex characters) represents the total length of the packet (Header + Data). Of course, it is represented in hexadecimal so, you’ll need to convert it to decimal to know the exact length. NOTE: the minimum value is 00 14 which indicates a length of 20 bytes (a header without data), the maximum value is ffff which indicates a maximum length of 65,535 bytes
• Identification (IPID): (16 bits, 4 hex characters) A unique identification number used to identify a packet or sequence of fragmented packets.
• Flags: (3 bits) Used to identify whether a packet is part of a sequence of fragmented packets. Bit 0: reserved, must be zero
  Bit 1: (DF) 0 = May Fragment, 1 = Don’t Fragment.
  Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

For fragmented packets, all fragments except the last have the MF flag set. The last fragment has a flags-value of zero and a non-zero Fragment Offset field, differentiating it from an unfragmented packet. If the packet is marked as DF and has no offset, it will have the value of 40 00 NOTE: fragmentation is being maliciously used for various intentions like IDS/IPS evasion and mounting DoS attacks.

The bit 0 was introduced as an April Fools’ joke, proposed for use in RFC 3514 as the “Evil bit”. be used to indicate whether a packet had been sent with malicious intent, thus making computer security engineering an easy problem — simply ignore any messages with the evil bit set and trust the rest.

• Fragment Offset: (13 bits) If a packet is fragmented, the value of this field is used to reassemble the packets in the correct order. NOTE: the flags + the fragment offsets = 16 bits which means 4 hex characters. to analyze these fields, you need first to convert the 16-bits value to binary.
• Time To Live (TTL): (8 bits, 2 hex characters) Defines the lifetime of the packet, measured in hops. If this field contains the value zero, then the datagram must be destroyed.
• Protocol: (8 bits, 2 hex characters) This field defines the protocol used in the data portion of the IP datagram. Commonly, it’ll be 06 indicating TCP, 17 indicating UDP, and 01 indicating ICMP, however, You can refer to RFC 790 — Assigned Numbers for the protocol numbers.
• Header Checksum: (16 bits, 4 hex characters) A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed.
• Source Address: (32 bits, 8 hex characters) the source IP Address.
• Destination Address: (32 bits, 8 hex characters) the destination IP Address.
• Options: (variable length) Although options do have valid uses, especially for network troubleshooting, they are rarely used by legitimate traffic. I’ll briefly mention some IP options and I’ll let you imagine how maliciously they can be used, however, you can refer to RFC 791-Internet Protocol for more information about the IP options.
• Options — Record-Route: tells the router to add its IP address to the options field.
• Options — IP Timestamp: tells the router to write a timestamp into the options field.
• Options — Strict Source Routing: allows the sender to specify the exact route a packet should take to the destination.
• Options — Loose Source Route: allows the sender to specify a list of routers a packet must pass through. It may also traverse other routers if required.
• Padding: (variable length) It’s introduced to ensure that the header contains an integer number of 32-bit words

Finally, the Data! which of course a layer 4 segment.

In our example, we have analyzed the ethernet header of the dump. let’s extract the IP packet out of the dump and analyze it.

0x0000                                               45 00
0x0010   00 3c 72 8d 00 00 80 01   00 00 0a 0a 00 03 c0 a8
0x0020   00 80 08 00 4d 36 00 01   00 25 61 62 63 64 65 66
0x0030   67 68 69 6a 6b 6c 6d 6e   6f 70 71 72 73 74 75 76
0x0040   77 61 62 63 64 65 66 67   68 69

This is a very simple packet, definitely, you will encounter more complicated packets so, you need to determine the IP version (the first 4 bits) that has been used and the length of the IP header (the second 4 bits).

• IP version: 4
• IHL (Internet Header Length): 5 × 32 bits = 20 bytes

We just determined that the first 20 bytes of the packet are the header and the rest of the packet is the data. Why not do we extract the header for simplicity?!

0x0000                                               45 00
0x0010   00 3c 72 8d 00 00 80 01   00 00 0a 0a 00 03 c0 a8
0x0020   00 80

We’ll use the IP header anatomy explained above to analyze this header.

• Type of Service: 00 Not Set.
• Total Length: 00 3c which equals 60 in decimal. and indeed the packet is 60-byte long (header + data).
• IPID: 72 8d
• Flags & Fragment Offset: 00 00
• Time To Live (TTL): 80 = 128 (decimal)
• Protocol: 01 which ICMP. wait, what?! a layer-3 protocol is encapsulated inside an IP packet! we’ll discuss it. 😉
• CheckSum: 00 00 Validation Disabled.
• Source IP: 0a 0a 00 03 you need to convert each octet on its own to convert it into the decimal representation of the IP so the IP will be 10.10.0.3
• Destination IP: c0 a8 00 80 which is 192.168.0.128

Obviously, this packet doesn’t have any options nor padding. Form our analysis, we concluded that this specific packet contains an ICMP protocol data so, why not we understand the anatomy of the ICMP header?!

ICMP

Although the ICMP is a layer-3 protocol, it is being encapsulated inside an IP Packet which is quite odd as the IP packet encapsulates a layer-4 segment!

By the definition of RFC 792-Internet Control Message Protocol, ICMP, uses the basic support of IP as if it were a higher-level protocol, however, ICMP is actually an integral part of IP. The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable.

There are many types of ICMP messages but we are going to discuss the one that we need in our analysis example. however, I encourage you to take a look at the rest of them on the RFC 792-Internet Control Message Protocol.

The header of the ICMP will vary according to the message type. but the first 4 bytes will always be the same.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |     Code      |          Checksum             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Type: the ICMP type
• Code: the ICMP subtype code
• Checksum: this is being used for error detection. It is calculated from the ICMP header and data with value 0 substituted for this field.

You can refer to the Internet Control Message Protocol page on Wikipedia, Control Messages section for a complete list of the types and codes.

Echo and Echo-Reply

The Echo and Echo-Reply messages are being used for the ping command. mainly, to check the connectivity between two hosts.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |     Code      |          Checksum             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Identifier          |        Sequence Number        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Data ...
 +-+-+-+-+-

• Type: 8 for an echo message, and 0 for an echo-reply message
• Code: 0 for both echo and echo-reply messages
• The identifier and the Sequence Number: are being to match echos and replies, may equal zero. NOTE: most Linux systems use a unique identifier for every ping process and an increasing sequence number within that process. Windows uses a fixed identifier, which varies between Windows versions and a sequence number that is only reset at boot time. Can be used for OS fingerprinting.
• Data: usually, the payload of the packet is generally filled with ASCII characters. The data received in the echo message must be returned in the echo reply message.

In our example, we have analyzed the ethernet and the IP headers of the dump. let’s extract the IP data (the ICMP packet), which is the rest of the packet, out of the dump, and analyze it.

0x0000
0x0010
0x0020         08 00 4d 36 00 01   00 25 61 62 63 64 65 66
0x0030   67 68 69 6a 6b 6c 6d 6e   6f 70 71 72 73 74 75 76
0x0040   77 61 62 63 64 65 66 67   68 69

Unlike the IP header, the ICMP header does not reserve a field for the header length because it varies depends on the message type. Once we determine the message type, we can anticipate the offset of the data. so, let’s begin with determining the message type:

• Type: 08 which is an echo request message. hence, the data should be at 9th-byte. In your investigations, you need to analyze the data to detect attacks and security incidents such as tunneling. Sound like another interesting story. 🤔
• Code: 00
• Checksum: 4d 36
• Identifier: 00 01
• Sequence Number: 00 25

Here we are, we managed to parse a bunch of hexadecimal numbers indicating interesting information. Just like the computer does! Very easy and straight forward, isn’t it?

Can you Analyze the following packet on your own? do yourself a favor and try 😉

0x0000   00 25 b3 bf 91 ee 00 21   29 66 71 95 08 00 45 00 
0x0010   00 3c 06 7b 00 00 7f 01   6a 11 c0 a8 00 80 0a 0a
0x0020   00 03 00 00 55 36 00 01   00 25 61 62 63 64 65 66 
0x0030   67 68 69 6a 6b 6c 6d 6e   6f 70 71 72 73 74 75 76 
0x0040   77 61 62 63 64 65 66 67   68 69 

Conclusion

Hexadecimal may seem like gibberish and very complicated at first, but after analyzing a couple of packets with the help of some cheat-sheets, of course, you will find it very easy and sometimes amusing! not to mention that this skill is necessary for any cybersecurity analyst or a forensics investigator.

NOTE: I’ve written this story as a cheat-sheet for myself while practicing and thought it might help somebody. I’d appreciate your feedback. Thank You!