mirror of https://github.com/dirtbags/moth.git
211 lines
7.1 KiB
Markdown
211 lines
7.1 KiB
Markdown
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)
|
||
|
||
Let’s 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
|
||
|
||
Let’s 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”. Let’s look at the next 16 bits:
|
||
|
||
3 6 3 A
|
||
0011 0110 0011 1010
|
||
|
||
Now let’s 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 frame’s 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
|