moth/packages/net-re/7/index.mdwn

211 lines
7.1 KiB
Plaintext
Raw Normal View History

More Binary Protocols
=====================
The previous page introduced you to decoding binary protocols by showing
how DNS encodes text. We will now examine Ethernet, IP, and TCP, to
better understand binary protocols.
Generally, you will use tools like wireshark or tcpdump to decode IP and
TCP, but understanding how these work will help you decode other unknown
binary protocols and file formats in the future.
In this page, we will dissect the following captured network frame:
00 11 bc 56 5f 00 00 01 e8 13 0c 89 08 00 45 00
00 3c 13 b3 36 3a 3f 06 13 be 6a 56 5e af ef c9
b0 04 17 af 00 50 cf 16 e8 db 00 00 00 00 a0 02
16 d0 ec 87 00 00 02 04 05 b4 04 02 08 0a 93 40
fb 68 00 00 00 00 01 03 03 07
Octets
------
This page introduces the new term “octet” to refer to 8 bits. The words
“octet” and “byte” are usually interchangeable, but in some cases a byte
may be 7 bits, 6 bits, 16 bits, or something else. Networking documents
usually refer to “octets” in order to avoid any confusion about the
number of bits.
Ethernet
--------
Ethernet consists of:
* Destination address (6 octets)
* Source address (6 octets)
* EtherType (2 octets)
* Data
* CRC Checksum (4 octets)
Lets examine the first 14 octets of our captured ethernet frame:
00 11 bc 56 5f 00 00 01 e8 13 0c 89 08 00
This can be broken down into the two 6-octet addresses and the EtherType:
dst: 00:11:bc:56:5f:00
src: 00:01:e8:13:0c:89
typ: 0800
The destination and source should be recognizable as “MAC addresses”.
An EtherType of 0x0800 indicates the data is an IPv4 packet. Most
frames you encounter will have an EtherType of 0x0800.
Internet Protocol (IP version 4)
--------------------------------
IP introduces to us the notion of 4-bit and 13-bit integers. The
following chart from RFC 971 shows the fields of an IP header. The
numbers at the top are the *bit* offset of each field.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The next few octets of our network frame are:
__ __ __ __ __ __ __ __ __ __ __ __ __ __ 45 00
00 3c 13 b3 36 3a 3f 06 13 be 6a 56 5e af ef c9
b0 04 17 af 00 50 cf 16 e8 db 00 00
Lets begin to break this down. The first two fields are 4-bit
integers: half-octets, also called nybbles (because they are half a
byte). These are easy to extract from hex, since one hex digit is
exactly 4 bits. Similarly, one octet is 8 bits, and two hex digits.
Two octets is 16 bits, and four hex digits.
Version: 0x4
IHL: 0x4
TOS: 0x00
Length: 0x003c
ID: 0x13b3
Leaving our undecoded snippet as follows:
__ __ __ __ 36 3a 3f 06 13 be 6a 56 5e af ef c9
b0 04 17 af 00 50 cf 16 e8 db 00 00
The next field, “Flags”, is a *3-bit* field, leaving 13 bits for
“Fragment Offset”. Lets look at the next 16 bits:
3 6 3 A
0011 0110 0011 1010
Now lets split that up after the first three bits:
1 1 6 3 A
001 1 0110 0011 1010
Therefore, our first three bits are the hex value bits are the hex value
`0x1`, and the remaining 16 bits are the hex value `0x163A`.
Flags: 0x1
Fragment Offset: 0x163A
The next few fields are relatively simple:
TTL: 0x3F
Protocol: 0x06
Header Checksum: 0x13BE
Now our snippet is:
__ __ __ __ __ __ __ __ __ __ 6a 56 5e af ef c9
b0 04 17 af 00 50 cf 16 e8 db 00 00
Finally, we get to the IP addresses:
Src: 6a.56.5e.af (106.86.94.175)
Dst: ef.c9.b0.04 (239.201.176.4)
We have now decoded 20 octets, or 4 words. The IHL field contains the
length of the IP header in words. Since IHL in this frame is 4, this IP
header has no options, and we are done decoding it. All remaining data
belongs to the TCP protocol (protocol 6).
Transmission Control Protocol (TCP)
-----------------------------------
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After parsing the Ethernet and IP headers, our frames unparsed octets
are:
__ __ 17 af 00 50 cf 16 e8 db 00 00 00 00 a0 02
16 d0 ec 87 00 00 02 04 05 b4 04 02 08 0a 93 40
fb 68 00 00 00 00 01 03 03 07
The first 4 fields are decoded just like previous fields:
Src: 0x17AF (6063)
Dst: 0x0050 (80)
Seq: 0xcf16e8db
Ack: 0x00000000
We can now examine the next 2 octets to extract Data Offset and the
flags:
a 0 0 2
1000 0000 0000 0010
offs|reserv UA PRSF
RC SSYI
GK HTNN
Decoding to:
Data Offset: 0xA
Flags: SYN
Then, carrying on:
Window: 0x16D0
Checksum: 0xEC87
Urgent: 0x0000
There follows 20 bytes of options, and no data.
Question
========
The key for this page is the source IP in the following frame:
00 11 bc 56 5f 00 00 01 e8 13 0c 89 08 00 45 00
00 2c 00 00 40 00 3d 06 aa 51 3c 00 0d 41 4d 01
08 30 c6 d6 d2 e6 06 57 7b 2d 00 76 d2 c9 60 12
16 d0 84 c5 00 00 02 04 05 b4 00 00