mirror of https://github.com/dirtbags/moth.git
211 lines
7.1 KiB
Plaintext
211 lines
7.1 KiB
Plaintext
|
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
|