简介
本文描述dnscat2 协议
我称之为dnscat2协议，尽管严格来讲，它不仅仅局限于dnscat或DNS。我需要一种逻辑连接协议，它可以在不确保可靠性且带宽被极度限制的多种底层连接、数据报之上建立。
本协议是为dnscat设计的，采用轮询机制——客户端发送数据包，服务器作出回应，服务器无法知道是哪个客户端发送的数据包，也无法知道如何初始化一个连接，因此这些问题在dnscat2协议中都要考虑。
本协议基于数据报，包含一个16bits的session_id, 可用于追踪多种底层链路之上的连接，并处理底层的丢包、重复和乱序问题。
以下我会给出一些细节——我们需要什么来完成这些工作、连接如何工作的描述、消息中使用的常量和消息本身的结构
挑战
借助DNS协议很有挑战性！下面列举了一些问题：
- 每个消息都需要某种类型的回复
- 重传、丢包和乱序非常普遍
- DNS数据包中只能包含数字和字母，不一定区分大小写
DNS传输协议和dnscat协议都将这些考虑在内，不像其它DNS隧道协议，我不依赖于使用TCP传输层来保证可靠性——dnscat协议有能力在DNS协议之上建立原始连接。
DNS运送协议
dnscat协议是一个独立的协议，可以被应用在任何轮询协议之上，例如DNS、HTTP、ICMP/Ping等——我将这些协议都看作运送协议。在这些不同的协议之上需要将数据稍稍包装一下。本节主要介绍如何将DNS协议作为一个运送通道。
编码
所有的数据被编码成字符串的16进制表示，例如： "AAA" 变为"414141"
域名中的所有点号都应被忽略，因此，"41.4141"、"414.141"和"414141"是完全一样的。
除此之外，不区分大小写，因此"5b"和"5B"也是相同的。客户端和服务器都要处理大小写的不敏感性，因为有些软件会改变请求的大小写！
发送/接收
客户端可以选择是否扩展域名（用户必须有此域名的权威DNS服务器）或者加一个"dnscat."前缀，消息格式如下:
<encoded data>.<domain>
or
<tag>.<encoded data>
任何不符合上述形式的数据，或者是不支持的记录类型，或者dnscat服务器无法识别的扩展域名，服务器可以丢弃或者转发至上层DNS服务器。
dnscat2服务器必须用正确格式的DNS应答报文回复，置位无错误位，并包含一个或多个answer。如果有多个answer，每个answer的每一个字节必须是一字节的序列号（中间DNS服务器很可能会改变记录的顺序）
应答记录类型必须和请求记录类型一致，应答的具体的编码方式取决于记录类型。
DNS记录类型
dnscat服务器支持绝大多数DNS消息类型：TXT, MX, CNAME, A和AAAA，这些类型的请求消息都被封装为DNS记录，不同类型的应答报文格式稍有不同。
TXT应答报文就是16进制编码的数据。理论上，TXT记录可以包含二进制数据，但是Windows DNS客户端会NULL字符截断，因此需要编码。
CNAME和MX记录在请求时是相同编码的：都有一个tag前缀或者域名后缀。这是必要的，因为中间DNS服务器不会转发不正确的域名。MX记录类型在DNS中也有额外的区域——优先级区域，可以随机设置，客户端应该忽略。
最后，A记录和AAAA记录，有点像TXT，就是原始数据，没有前缀后缀。但有两点补充：一是应答报文长度很短（A记录4B，AAAA记录16B），因此需要多个answer，不幸的是，DNS层次体系会
重新排列answer, 因此每个记录必须包含一个字节的序号作为前缀，数值并不重要，只要可以排列得到原始的顺序即可。
二是没有明确的方法可以获取应答报文的长度，因为应答报文实际上是分块的。因此，数据本身的长度也要用一个字节来存储，放在消息头部。如果消息结尾不够一个块的大小，需要填充。
A记录应答报文格式：
0.9.<byte1>.<byte2> 1.<byte3><byte4><byte5> 2.<byte6><byte7><byte8> 3.<byte9>.<pad>.<pad>
0表示块序号， 9表示数据长度， 2和3表示块序号
Errors
如果server遇到错误，根据严重性会采取以下措施:
- 可以忽略的错误（重复的SYN包），回复一个空消息；对于TXT/A/AAAA, 显然是不回复；对于CNAME/MX/NS,因为域名是必须的，所以只回复一个域名。
- 致命错误（例如未处理的异常）， 应该回复带有描述信息的FIN包。
dnscat协议
在上面我定义了一种DNS运送协议，这个协议解决了如何通过DNS报文传送数据。下面我正式介绍dnscat协议。
dnscat 协议
连接
这里的"连接"指的是客户端和服务器之间的逻辑会话。一个连接以SYN包开始，之后包含若干个MSG包，最后以FIN包结束。每个连接用一个唯一的16bits的session_id标识，注意不要将SYN/FIN和tcp连接中的概念混淆，这里指的完全是dnscat中的概念。
总结一下：客户端发送SYN包给server, server回复SYN包，这样一个连接就建立了。客户端发送MSG包给server, server回复MSG包。当客户端决定终止连接，客户端发送FIN，server回复之；当server决定终止连接，它使用FIN包回复来自客户端的MSG包，客户端不再回复。
SYN包中的flags区域在client和server之间交换，这些flag影响整个会话过程。
大部分情况下，意外的数据包会被忽略.
client和server都允许处理多个会话，client经常和server同时展开多个会话；server则可以和不同的client同时展开会话。
一个完整的连接过程如图：
+----------------+
| Client Server |
+----------------+
| SYN --> | |
| | v |
| | <-- SYN |
| v | |
| MSG --> | |
| | v |
| | <-- MSG |
| v | |
| MSG --> | |
| | v |
| | <-- MSG |
| ... ... |
| ... ... |
| ... ... |
| | | |
| v | |
| FIN --> | |
| v |
| <-- FIN |
+----------------+
server决定终止连接：
+----------------+
| Client Server |
+----------------+
| SYN --> | |
| | v |
| | <-- SYN |
| v | |
| MSG --> | |
| | v |
| | <-- MSG |
| v | |
| MSG --> | |
| | v |
| | <-- FIN |
| v |
| (nil) |
+----------------+
收到意外的MSG，server回复FIN：
+----------------+
| Client Server |
+----------------+
| MSG --> | |
| | v |
| | <-- FIN |
| v |
| (nil) |
+----------------+
server收到意外的FIN，忽略之。
+----------------+
| Client Server |
+----------------+
| FIN --> | |
| v |
| (nil) |
+----------------+
SEQ/ACK号
SEQ（sequence 序列）和ACK（acknowledgement确认）号和TCP中的概念十分相似。在连接初始阶段，client和server都选择一个随机的ISN（initial sequence number初始序列号），并发送给对方。
client的SEQ号就是server的ACK号，反之亦然。这样双方都知道下一个应收到的序号是多少。
在一个会话过程中，双方会相互发送数据，当更多的数据排队等待发送，想像你正在将这些数据移动到已发送数据列表中，当消息发送出去之后，系统应当注意自己的序列号和字符队列来决定应该发送什么。如果有还未被对方确认的数据在等待，这些数据应该被重传，直到和当前的序列号匹配。
当收到消息后，接收方必须将消息中的序列号和自己的确认号进行对比，如果序列号比确认号小，说明收到的是重复数据，ACK可能丢失了，没有被对方收到，必须重新发送ACK。如果序列号比确认号大，数据应该被缓存或是悄悄丢弃（当对方发送多个数据包进行测速时），如果相等，则进一步处理。
当消息进一步处理时，接收方根据收到的字节数增加ACK号，并将新的ACK、SEQ和等待的数据发送出去。
当发送方收到对方的ACK，会增加自己的SEQ，从新的SEQ处开发发送数据。
你要知道双方都会持续确认对方发送的数据（通过增加对方的SEQ号），同时发送自己的数据并更新自己的SEQ（通过对方的ACK）
命令协议
在dnscat协议之上有一个称为命令协议的协议。如果在SYN头部设置了OPT_COMMAND位，所有的消息都会被当作命令消息，必须遵循命令协议。
关于命令协议的详细信息请查看command_protocol.md.
加密/签名
待完成
常量
/* Message types */
#define MESSAGE_TYPE_SYN (0x00)
#define MESSAGE_TYPE_MSG (0x01)
#define MESSAGE_TYPE_FIN (0x02)
#define MESSAGE_TYPE_ENC (0x03)
#define MESSAGE_TYPE_PING (0xFF)
/* Encryption subtypes */
#define ENC_SUBTYPE_INIT (0x00)
#define ENC_SUBTYPE_AUTH (0x01)
/* Options */
#define OPT_NAME (0x01)
#define OPT_COMMAND (0x20)
Messages
本节解释了如何为消息类型编码，所有的区域采用大端编码方式，整个数据包通过DNS运送协议传送。运送协议负责处理数据包大小，数据包大小是已知的。
所有的消息包含一个16位的packet_id, 每个packet_id应该不同，这是为了缓存而设置的。
数据类型
正如上面提到的，所有的区域大端编码（网络字节序）。以下数据类型被用到：
- uint8_t - an 8-bit (one-byte) value
- uint16_t - a 16-bit (two-byte) value
- uint32_t - a 32-bit (four-byte) value
- uint64_t - a 64-bit (eight-byte) value
- ntstring - a null-terminated string (that is, a series of bytes with a NUL byte ("\0") at the end
- byte[] - an array of bytes - if no size is specified, then it's the rest of the packet
MESSAGE_TYPE_SYN [0x00]
- (uint16_t) packet_id
- (uint8_t) message_type [0x00]
- (uint16_t) session_id
- (uint16_t) initial sequence number
- (uint16_t) options
- If OPT_NAME is set: (ntstring) 7.
Notes
每个连接的初始化，都是通过一个客户端发送SYN开始，包含一个随机的session_id和随机的初始化序列号，以及请求选项。
-
以下选项被定义：
-
OPT_NAME - 0X01[C->S]
- 数据包包含一个额外的区域：session名，一个自由区域，可以包含可读数据
-
OPT_COMMAND - 0X20[C->S]
- 命令会话，表示是一个命令隧道消息
-
OPT_ENCRYPTED － 0x40 [C-<S and S->C]
- 协商加密方式
- crypto_flags 未定义，为0
- 公钥x和y为大数，直接转为16进制值，左侧填充0
-
-
服务器回复SYN，包含初始序列号和选项
- 如果客户端请求中包含OPT_ENCRYPTED，服务员也必须包含
session_id和初始号必须随机化，使得连接劫持攻击更加困难（两个序列号和session_id每个连接给我们大约48bits的熵）
packet_id对每个packet来说都应该不同，完全是为了阻止缓存。可以是递增的，双方都应该忽略这个值。
如果服务器收到多个完全相同的SYN，则每个都要回复。
如果服务器收到了有相同session_id的不同SYN，应该忽略。
错误状态
如果客户端没有收到SYN应答，意味着请求包或者应答包丢失了，客户端可以选择重传或者生成新的SYN包或会话。
-
如果客户端在收到MSG消息之前收到第二个相同session的SYN，需要当作有效来回复。
- 有效意味着包含相同选项、序列号、相同名称、相同密钥。
如果客户端和服务器在建立连接时收到SYN，应该丢弃。
MESSAGE_TYPE_MSG: [0x01]
- (uint16_t) packet_id
- (uint8_t) message_type [0x01]
- (uint16_t) session_id
- (uint16_t) seq
- (uint16_t) ack
- (byte[]) data
Notes
如果SYN包含OPT_COMMAND,数据区域使用命令协议
MESSAGE_TYPE_FIN: [0x02]
- (uint16_t) packet_id
- (uint8_t) message_type [0x02]
- (uint16_t) session_id
- (ntstring) reason
Notes
一旦FIN发送，client or server就不太回应任何消息。
MESSAGE_TYPE_ENC: [0x03]
- (uint16_t) packet_id
- (uint8_t) message_type [0x03]
- (uint16_t) session_id
- (uint16_t) subtype
- (uint16_t) flags
- If subtype is ENC_SUBTYPE_INIT:
- (byte[32]) public_key_x
- (byte[32]) public_key_y
- If subtype is ENC_SUBTYPE_AUTH:
- (byte[32]) authenticator
Notes
- 如果要使用加密连接，客户端应该立即发送ENC|INIT数据包
- 服务器必须用包含相同子类型的ENC包回复ENC请求
- 如果客户端选择加密，服务器也必须加密；客户端选择认证，服务器也必须认证。
- 服务器必须用相同的密钥回复ENC|INIT包
- 公钥和认证器编码为32字节的16进制字符串，左侧填充0
下面的Ruby代码用于转换整数到字符串：
[bn.to_s(16).rjust(32*2, "\0")].pack("H*")
反之：
[bn.to_s(16).rjust(32*2, "\0")].pack("H*")
MESSAGE_TYPE_PING: [0xFF]
- (uint16_t) packet_id
- (uint8_t) message_type [0xFF]
- (uint16_t) ping_id
- (ntstring) data
Notes
ping_id应该和请求一致
