Just thought I’d do a quick post on a useful trick. With a bit of practice and some understanding of hex-binary-decimal conversion, it’s possible to read TCP/IP headers manually, in the same way tcpdump and Wireshark do at a really low level.
This is also useful for demonstrating how networking and packet inspection systems know what’s passing through them. Ultimately it has everything to do with the electronics in our networking equipment, which counts the number of binary digits from certain markers and buffers the relevant ones. All the theory, history and various packet-related trivia are probably covered in greater depth on Wikipedia.
Opening a random packet capture file in Wireshark and selecting any TCP/IP packet will bring up a window showing that packet in hex form. Each group of two digits represents a byte of data:
Really doesn’t mean a lot to the untrained eye, does it? Forget about the textbook diagrams of what packet headers should look like – in the real world bytes are what we’re actually looking at, and header fields must be identified within them.
Well, here’s the clever bit: If we selected the various header fields in the centre window in Wireshark, the relevant bytes/hex values will be highlighted, so the byte length for each field can be determined. Below is what happens when the Ethernet header is selected (ignore the ASCII output):
The corresponding 14 bytes in the main window are highlighted, and therefore it can be said the first 14 bytes of the packet form the Ethernet header.
Next, clicking on the IPv4 header results in another series of hex digits being highlighted in the main window:
These form the IPv4 header, which (at least here) is 20 bytes in length.
Finally, selecting the TCP header option gives us a third group of digits. Now we know the TCP header is also 20 bytes in length.
Using this alone, a surprising amount can be learned about any TCP/IP packet. We know the first 14 bytes form the Ethernet header, the next 20 bytes form the IPv4 header, and the subsequent 20 bytes form the TCP header. The header lengths appear to be uniform across TCP/IP packets.
If the hex values were translated or compared with an ASCII table, it would become apparent what the header field entries were. Experienced security analysts could instantly recognise and interpret certain byte patterns, for example the 0x4500 value after the first 14 bytes immediately marks it as an IPv4 packet header.
Knowing this, we’re in a better position to answer a certain question that appears in some packet analysis exams: Identifying SYN-ACK-FIN flags within raw packets.
Let’s break the TCP header down further. As established, it’s 20 bytes in length, and within those 20 bytes can be found:
* First 2 bytes: Source port
* Second 2 bytes: Destination port
* Bytes 13 and 14 (0x5018) represent the TCP flags, and this is actually determined by setting ‘flags’ along a collection of eight bits. It follows that the same principle applies to another TCP/IP packet, and byte 48 of a given packet or frame should define the status flag.
The Krypt 
Thanks for taking the time to enlightening my journey!