Network devices send data down the cable by converting the data into a signal. But how do they do this? And what else might be hiding in the signal? Just like a doctor needs to look at blood cells to identify blood-borne diseases, a network pro needs to look at what’s in the network signal to detect network intrusions, perform audits, and generally diagnose problems. And the key to all of this is packet analysis. Keep reading while we put your network signal under the microscope.
Here’s your first assignment:
We’ve seen before that network signals contain network data. This data is encoded into a format that computers can use, so if we can decode the signal, we should be able to extract the hidden message. But how do we do this?
The NIC starts by taking the message that needs to be sent across the network. It then turns the message into binary numbers, a series of 0’s and 1’s. After that, it encodes these numbers, and sends corresponding voltage signals through an attached network cable.
So if we know what the signal is, how do we find the original message?
To find out what the message is, we need to decode the rogue network signal. Here’s what we need to do.
Take the rogue signal.
The signal is the series of voltage changes that’s been transmitted along the cable. The message is hidden inside it.
Divide the signal into equal slices using a clocking mechanism.
By this we mean a device that pulses regularly. The clock provides a regular heartbeat.
Convert the signal into a series of 0’s and 1’s.
To do this, look at the voltage level where the clock pulse meets the signal. The voltage level at this point determines whether the value is a 0 or a 1.
The way in which we find the stream of 0’s and 1’s depends on the method used to encode the signal in the first place. So how do we know what this is?
The signal is transmitted over Ethernet. This is a standard that engineers and manufacturers use when designing computers and network gear, and the protocol includes features such as Manchester phase encoding. So if the signal is sent using the Ethernet protocol, it uses Manchester encoding.
The protocol for 10BaseT Ethernet specifies that the signal will be encoded using Manchester encoding.
Let’s look at how this works:
In NRZ encoding, the binary data is represented by the high and low voltage levels; high is a 1, low is a 0. In Manchester encoding, it is the TRANSITION to a voltage that represents data.
You don’t have to know the exact details of how encoding works.
What is important for you to understand is that data in a computer is represented one way but is encoded into a signal when it is transmitted on a network.
Knowing that the signal uses Manchester encoding means that we know the series of 1’s and 0’s that the signal represents. What we need to do next is translate this into something more meaningful. To do this, we need to understand how to translate binary numbers.
If you see a binary number like 0 or 1, this is the same as a decimal number 0 or 1. But how do we write a number like 2 in binary?
Binary is a base 2 system. This means that each digit in a binary number represents an increasing power of 2. The right-most digit in the binary number represents 20, the next represents 21, the next 22 and so on.
To convert from binary, here’s what you need to do.
Multiply each digit in the binary number by the corresponding power of 2.
Add the whole lot up together.
And there’s your decimal number equivalent.
So far we’ve looked at how we convert the signal into binary, and from binary to decimal. What we really want to do though is convert the signal into something more meaningful such as words. So how can we turn numbers into characters? The answer lies with ASCII...
We can convert a signal into numbers, but what can we do when we need text? We use something called the American Standard Code for Information Interchange (ASCII). Computers use this format when transferring text messages to one another.
In computer-speak, each binary digit is called a bit, and eight bits together form a byte.
Each byte needs to be translated to an ASCII character. To do this, we convert each byte into its decimal equivalent, and then look up the corresponding ASCII in an ASCII table, just like the one in Appendix B.
So the ASCII character represented by 01100001 is the letter a.
The trouble with translating bytes into ASCII characters in this way is that the 0’s and 1’s quickly become overwhelming. It can be fiddly converting bytes into decimal numbers, and this means it’s easy to make mistakes. So is there an easier way?
There is another character encoding scheme.
Another major character encoding scheme is Unicode. It allows for millions of characters.
Hexadecimal numbers are based on 16 digits, 0-15:
So if you see a hexadecimal number like B, you know that it just means 11 in decimal.
Hex is a base 16 system, which means that each digit represents an increasing power of 16. The right-most represents 160, the next represents 161, and so on.
Once you learn to use hexadecimal, you realize just how cool it is. Hex and binary make great partners, which simplifies conversions between binary and ASCII. Hex is like a bridge between the weird world of binary and our world (the human, readable world).
Here’s what we do:
Break the byte in half.
Each half-byte is called a nibble. [Note from Editor: you’re kidding, right?]
Convert each half into its hexadecimal equivalent.
Because the binary number is broken into halves, the highest number you can get is 15 (which is “F” in hex).
Concatenate the two numbers.
Concatenate is a programmer’s word that simply means “put them beside each other from left to right.”
Look the number up in an ASCII table.
The table to the right is just a sample. To find common ASCII codes, use the handy ASCII conversion table we’ve provided in Appendix B.
It’s not just a matter of decoding the binary; we have to consider the appropriate protocol too...
In order to effectively communicate, network devices use protocols, a set of guidelines, or rules, for the network conversation. These procotols cover such things as how fast data can be sent and how data will be structured when it’s sent.
Most protocols define a size limit for messages, which means that the messages need to be broken into separate packages and labeled with information about where the message came from and where it’s headed.
Network messages come in two kinds of packages: frames and packets.
From Sharpen your pencil.
A network frame contains nested structures that allow us to pack and unpack the data efficiently. Like a series of nested dolls, each smaller structure is enclosed by the next largest structure.
The payload of a frame is actually a structure nested within the frame. We call it a packet, and the EtherType field lets us know what type of packet the payload contains.
We have to do a bit more digging into this frame before we can get to the actual message.
Packets come in several different types. You can see that there is a lot of information packed inside these packets. All of those “fields” contain information that helps the packet get across the network. You will notice that many of the same fields exist in the three packet types shown here.
TCP is used for most IP network communications that require a reliable connection. By reliable, we mean that no information is lost.
There are many different types of IP protocols, around 139 of them. These are just three of the most common ones.
You can find a full list of IP protocols here:
So far we’ve looked at how frames are structured, how to tell which part of the frame contains the data, and how to convert the data into ASCII. So is that everything we need to decode the message the mole sent?
The entire message may need more than one frame.
Sometimes messages are spread across frames. So why’s that?
An Ethernet frame can hold about 1500 bytes of data. So any data that is larger than that will have to be broken apart.
There’s another reason too. In order to have a reliable transfer of data, the sender and receiver communicate using the TCP protocol on how the transfer is going. If there are errors in the packets, the sender will notify the receiver and it will resend the packets that had errors. Imagine if there was one large packet with all the data. If the connection is poor it might never get sent.
To reassemble the entire message, we need to collect together all the frames, making sure they’re in the right order.
So what do we mean by the right order? Why should they be out of order? Let’s take a look.
Individual packets on a large network with multiple routers can take different routes to get to the destination. Some paths are longer or have lower bandwidth and take longer for the packet to transit. These means that the packets could arrive at the destination out of order.
A computer sends some data on the network.
Because of the amount of data, it’s broken into three separate packets.
The packets take different routes.
The red and green packets take a different route to the blue packet.
The packets arrive at their destination.
But they arrive out of order.
Each packet contains a sequence number, and it’s this sequence number that tells you the correct order of the packets. This means that you can use the sequence number inside a packet to put all the packets back together in the right order. So if we can decode the packets in the right order, we’ll have the secret message.