Today is Halloween! A good day to write about the TCP Ghost Byte. 👻 You didn’t hear about that before?! Don’t worry – I felt exactly the same way. At first, I heard about it a few weeks ago during my preparations for becoming a Wireshark Certified Analyst. I took the official WCA course by Packet Pioneer Chris Greer which I can really recommend.
But let’s get started – the TCP Ghost Byte comes into play when we’re dealing with sequence and acknowledgement numbers. If you want to see the TCP Ghost Byte with your own eyes, it is essential that you understand these fundamentals. I will briefly outline them for you once more. Let’s take a look at the below figures. For a newly established connection both parties typically start with random sequence number values, chosen independently of each other. These numbers are counting the bytes that are transmitted during connection lifetime. Wireshark does not only provide these raw sequence numbers to us but also relative sequence numbers – they’re always starting at 1 which is much easier for humans to understand and follow.
Packet 75 in Figure 1 shows that 10.0.4.16 is sending a segment with length 1771 beginning at sequence number 1 which basically means that it contains bytes 1 to 1771. The next sequence number is 1772. And this is also what 142.251.40.35 needs to send as an acknowledgement in order to confirm that it correctly has received the prior 1771 bytes (see packet 87). A little later, 10.0.4.16 sends the next data segment in packet 117. This segment contains 74 bytes and starts with sequence number 1772. The next sequence number is 1772 + 74 = 1846. This formula applies throughout the entire connection: Sequence Number + TCP Length = Next Sequence Number = Expected ACK.
Figure 2 shows the same capture again. This time, we’ll look at traffic in the other direction. 142.251.40.35 sends a whole burst of TCP segments. Every single segment follows the formula above. After the burst is over, 10.0.4.16 acknowledges the whole data block by sending ACK 5981.
So far so good, but where exactly is the Ghost Byte? Above I wrote: „This formula applies throughout the entire connection“ – Strictly speaking, this isn’t true. Let’s take a look at the beginning of the connection in Figure 3… What do you observe?
Correct, the formula doesn’t apply there. Both, client and server begin with (relative) sequence number 0. Since a SYN contains no data, its length is also 0. But the next sequence number is 1 though?! And this is also what each peer sends an ACK for?! This must be our Ghost Byte. Let’s check the details of the SYN packet in Figure 4:
As you can see, the TCP payload field is collapsed and it has a length of 0 bytes! You have come this far, try it on yourself. Expand that payload field:
TCP payload (0 bytes)
Congratulations! You’ve spotted the Ghost Byte. Good job! By the way, it can also be spotted in FIN segments.
P.S. Yes, Figures 4 and 5 are photo manipulations. 👻
Summary
The term TCP Ghost Byte is used to describe the fact that segments with SYN or FIN flag increment the peers ACK count by one, although the carry 0 data bytes.
And guess what, I smashed the exam.
