本文属原创，如转载请注明出处，谢谢

1．先来几个名词的解释
1.1 P2P
用于不同PC之间共享文件的协议统称。P2P分3类：带服务器的P2P协议（如BitTorrent）、
纯粹的P2P协议（如kademlia）、混合P2P（如emule）。

1.2 Kad网络：
Kad是Kademlia的简称，现在用来代指不需要任何服务器的P2P的文件共享网络。
在Kad的网络中，完全不需要任何服务器，她需要UDP的端口支持，直接在各个PC
上搜索寻找文件。网络拓扑如下图：




1.3 eD2K网络：
Edonkey2000是早期实现网络中点对点文件共享所经常采用的一个工具，后来她所用
的网络结构被称作eD2K网络。eD2K需要一个中心服务器，用来记录哪些PC保存哪些
文件的信息。各台PC下载文件之前，先向中心服务器查询这些信息，然后根据返回的
的结果中PC的地址列表发起文件传输请求。网络拓扑如下：


现在很流行的BitTorrent就是采用的eD2K这种网络结构。

1.4 Hybrid网络：
eD2K网络和Kad网络综合起来就是Hybrid网络，而且需要下载文件的PC同时可以从这两种网络中下载同一个文件，并且能够保持同步。Edonkey的升级版本Emule就是采用的这种结构。网络拓扑结果如下图：





我们这次分析的eDonkey和eMule中，eMule可以看作eDonkey的升级版，eMule有众多的版本jMule，lMule，dMule等等，但eMule始终兼容eDonkey的协议。
2．eDonkey、eMule通讯模式简述
2.1 客户端与服务器端通讯
eDonkey和eMule所共有的是ED2K的网络结构，在这个结构里，客户端与服务器端，客户端和客户端之间，都分别可以用TCP和UDP协议进行通讯，但是最开始一定是客户端向服务器端发起连接。
典型过程（TCP）：

1．客户端在安装时，会自动配置一系列的服务器列表。
2．客户端启动后，向服务器发出请求连接，并且在连接建立后分配到一个客户端ID。
3．客户端向中心服务器传输自己的共享文件列表，服务器保存这些信息到数据库，这个数据库里存放着N多的文件信息以及活动的客户端列表。（协议格式下面相信介绍）
4．客户端同时发送自己想要下载的文件列表。
5．服务器端向客户端发回拥有（不一定是完全拥有）所请求文件的客户端列表。
6．客户端之间开始传输数据（传输的协议格式下面详细介绍）

针对高ID和低ID，各自与服务器建立连接的过程稍微有所不同，画两个图解释一把。
高ID的客户端与服务器端的通讯过程：

低ID的客户端与服务器的通讯过程：


无论是高ID还是低ID模式，最终都会以id change的报文来结束第一次握手，id change的报文会分配给该客户端一个客户端ID，后续会以这个ID来进行进行交互。
另外还有一种是拒绝连接的，比较少见，在服务器已经不可用时会遇到。
NOTE：
1．
另外，客户端一旦和服务器建立了连接，客户端和其他客户端交流文件时，这个连接一直保持。
2．
文件ID： 一个128位的哈希值，用来标识网络上唯一的一个文件。
用户ID： 一个128位的随机值，用来在服务器上唯一标识一个客户端。
客户端ID：一个32位的值，分为高ID和低ID。如果客户端能主动发起连接，就能得到一个高ID，并且这个ID一般不会改变，除非她的IP地址发生了变化。所以高ID经常分配给那些在公网上有地址的那些客户端。

2.2 客户端之间通讯：
1．客户端之间建立TCP的三次握手
2．客户端之间交换信息（客户端通过hello报文和eMule info报文）
3．其中一个客户端开始发出文件请求报文，过程如下：





红色的虚线部分是eMule的扩展的协议部分。
eMule协议扩展了eDonkey协议，允许客户端之间交流信息，包括server列表，客户端信息以及文件信息等，这些内容在eDonkey中是要靠服务器来完成的。
另外，在eMule中，服务器现在有了一个额外的功能：在同时在没有公网地址客户端（这些客户端是lowid，往往是内网用户）之间充当一个桥，把她们连接起来（加重了服务器的负担）。
eMule中还有Kad的网络结构，在这种网络结构中，各个客户端都是同等地位，没有了server的概念，通讯过程与eD2k网络中客户端之间的通讯模式类似。
典型过程：
1．客户端A向其他IP地址发送UDP报文，端口为默认4672，协议为0xe4，type为0x20
2．其中一个客户端B运行着同样的kad网络，则做出应答，协议为0xe4，type为0x28
3．两个客户端交换信息
4．客户端A向B发起连接请求，建立3次握手
5．以下的通讯方式与eD2K网络结构中通讯方式相同，如



在eMule和eDonkey协议中，UDP协议报文主要用来让服务器保鲜、加强客户端之间的文件请求和检索，来减轻服务器的负担。
默认情况下，TCP端口4661是eDonkey的服务器开放的端口（恩，实际中大部分都不
是）；TCP端口是客户端上开放的端口；UDP端口4665用来向eDonkey的服务器发送信息。

3．eDonkey协议报文格式以及特征码提取
3.1客户端登陆服务器的报文

字段名称字段大小（字节）默认值说明
协议10xe3
大小4无本报文中，除去协议字段和大小字段后的负载大小。
类型10x01登陆时的请求类型
用户ID16无这就是用户ID，是一个128位的HASH值
客户端ID40第一次连接的时候，客户端ID被初始化为0
TCP端口24662客户端所用的TCP端口，由于是可配的，所以不建议做为特征码
字段数目44剩余的字段数
名字可变的无用户的昵称，恩，也是可配的。
版本80x3c版本号，在eDonkey协议中被广泛支持。
端口84662客户端所用的端口号，同上。
标识80x01标识所有的tag号，同上。

所以提取特征码如下：
.{0,0}|e3|.{4}|01|.{16}|00 00 00 00|
方向为：
Client->Server
举例：


3.2 服务器回应的报文协议格式以及特征码提取：
字段名称字段大小（字节）默认值说明
协议10xe3
大小4无本报文中，除去协议字段和大小字段后的负载大小。
类型10x38该报文在服务器中操作类型码
信息列表大小2无信息列表的负载内容大小。
信息列表可变的无这个信息列表可以是以\r或者\n分割开的服务器的列表，这些列表信息往往以”WARNING”、”server version”、”error”、”[emDynIP”开头。
其中，在建立起成功连接时经常发送version，而在服务器拒绝连接或者客户端拥有一个低ID时经常发送warning
所以，服务器返回的特征码可以提取如下：
.{0}|e3|.{4}|38|.{2}warning
或者.{0}|e3|.{4}|38|.{2}server
或者.{0}|e3|.{4}|38|.{2}warning
或者.{0}|e3|.{4}|38|.{2}error
或者.{0}|e3|.{4}|38|.{2}\[emDynIP

举例如下：


3.3客户端提供本地可用的共享文件列表报文
该报文在和服务器的连接建立后发送，或者在共享文件列表发生变化时发送。
字段名称字段大小（字节）默认值说明
协议10xe3
大小4无本报文中，除去协议字段和大小字段后的负载大小。
类型10x15该报文在服务器中操作类型码
文件个数4无信息列表的文件个数。
文件列表可变的无这个信息列表可以是以\r或者\n分割开的服务器的列表，这些列表信息往往以”WARNING”、”server version”、”error”、”[emDynIP”开头。
其中，在建立起成功连接时经常发送version，而在服务器拒绝连接或者客户端拥有一个低ID时经常发送warning
提取特征码如下：
{0}|e3|.{4}|15|
漏报可能性比较大，约为1/65535，个人不建议使用。

3.4请求服务器列表报文
协议格式
协议大小默认值说明
协议号10xe3
大小401字段协议号和大小后续的负载内容长度
类型10x14请求的操作类型码
特征码提取如下：
datasize eq 6
.{0}|e3 01 00 00 00 14|
举例：

3.5服务器列表反馈报文
协议格式
协议大小默认值说明
协议号10xe3
大小4无字段协议号和大小后续的负载内容长度
类型10x32请求的操作类型码
Server数目1无当前报文中列举的server的数目
各server实体数据Server数目*6无每个server的实体数据里包括4个字节的IP地址以及2个字节的port
特征码提取如下：
Datasize gt 12
.{0}|e3 |.{4}|32|
该规则误报可能性较高。

举例：


3.6 服务器状态反馈报文
协议格式
协议大小默认值说明
协议号10xe3
大小409字段协议号和大小后续的负载内容长度
类型10x34请求的操作类型码
用户数4无当前登陆到server的用户数目
文件数4无当前server上的文件数目
特征码提取如下：
datasize eq 14
.{0}|e3 09 00 00 00 34|
3.7 Hello报文
协议格式
协议大小默认值说明
协议号10xe3
大小4无字段协议号和大小后续的负载内容长度
类型10x01请求的操作类型码
用户哈希大小116
用户哈希16无
客户端ID4无客户端32位的ID
TCP端口2无无它
选项数4无选项数
选项列表可变无各个选项的列表，包含着各个客户端的属性
服务器IP4无所用服务器IP地址
服务器端口2无所用服务器端口
该报文是客户端之间进行连接后的报文，但是与登陆服务器的报文剧类似，他们都有相同的操作类型码0x01，在整个的协议中，只有这两个报文有相同的操作类型码。
特征码提取如下：
datasize gt 39
.{0}|e3 |.{4}|01 10|

3.8 请求部分文件实体报文
协议格式
协议大小默认值说明
协议号10xe3
大小40x29字段协议号和大小后续的负载内容长度
类型10x47请求的操作类型码
文件标识16无当前报文中列举的server的数目
第一部分偏移量4无第一部分在文件中的偏移量
第二部分偏移量4无第二部分在文件中的偏移量
第三部分偏移量4无第三部分在文件中的偏移量
第一部分结束偏移量4无第一部分在文件中结束的偏移量
第二部分结束偏移量4无第二部分在文件中结束的偏移量
第三部分结束偏移量4无第三部分在文件中结束的偏移量
特征码提取如下：
datasize eq 46
{0}|e3 29 00 00 00 47|
举例如下：


3.9 发送所请求文件内容报文
协议格式
协议大小默认值说明
协议号10xe3
大小4无字段协议号和大小后续的负载内容长度
类型10x46请求的操作类型码
文件标识16无当前报文中列举的server的数目
开始偏移量4无下载数据开始的偏移量
结束偏移量4无下载数据结束的偏移量
文件数据可变无实际下载数据
特征码提取如下：
datasize gt 30
.{0}|e3|.{4}|46|
NOTE：
这种报文是实际传输数据的报文，是eDoneky主要的活动。在客户端之间传送数据时，首先发送的就是这种报文。

3.10请求文件部分HASH值
协议格式
协议大小默认值说明
协议号10xe3
大小4无字段协议号和大小后续的负载内容长度
类型10x51请求的操作类型码
文件标识16无请求的文件ID
特征码提取如下：
Datasize eq 22
.{0}|e3|.{4}|51|
3.11 文件下载请求报文
协议格式
协议大小默认值说明
协议号10xe3
大小40x11字段协议号和大小后续的负载内容长度
类型10x54请求的操作类型码
文件标识16无当前报文中列举的server的数目
特征码提取如下：
datasize eq 22
.{0}|e3 11 00 00 00 54|

3.12 文件请求报文
当客户端之间进行文件传输时，请求文件时发送的报文。
协议格式
协议大小默认值说明
协议号10xe3
大小4无字段协议号和大小后续的负载内容长度
类型10x58请求的操作类型码
文件标识16无当前报文中列举的server的数目
文件部分状态3无可选。如果扩展请求的标识版本表示eMule信息报文大于0时，该选项存在。
文件源个数2无可选。如果扩展请求的标识版本表示eMule信息报文大于0时，该选项存在
特征码提取如下：
datasize eq 22
.{0}|e3 11 00 00 00 58|
或者
datasize eq 27
.{0}|e3 16 00 00 00 58|

NOTE：
抓包进行eDonkey和eMule的协议解析时，开始时建议只留一个服务器，如果有多个服务器报文繁多，很不容易区分到底属于那个流。

4．eMule协议报文格式以及特征码提取
4.1 客户端之间的TCP扩展协议
4.1.1 发送压缩文件报文
协议格式
协议大小默认值说明
协议号10xc5
大小4无字段协议号和大小后续的负载内容长度
类型10x40请求的操作类型码
文件标识16无文件标识
文件部分开始偏移量4无文件部分开始的偏移量
压缩部分大小4无压缩部分大小
压缩部分内容可变无压缩部分内容
特征码提取如下：
datasize gt 30
.{0}|c5|.{4}|40|
举例：


NOTE：
这种报文用来实际传输数据，是eMule中的主要活动报文。
4.1.2 请求源文件报文

协议格式
协议大小默认值说明
协议号10xc5
大小4无字段协议号和大小后续的负载内容长度
类型10x81请求的操作类型码
文件标识16无当前报文中列举的server的数目
特征码提取如下：
Datasize eq 22
.{0}|c5|.{4}|81|

eMule扩展协议：
eMule的扩展协议中，包括了许多新增内容。
允许客户端之间交流server列表，其他的客户端和文件信息。
服务器端做为了一个桥，连接起处于防火墙后面并且不能接受连入的连接的那些客户端。

4.2 客户端之间的UDP扩展协议报文
4.2.1 重新请求文件报文
协议格式
协议大小默认值说明
协议号10xc5
大小4无字段协议号和大小后续的负载内容长度
类型10x40请求的操作类型码
文件标识16无当前报文中列举的server的数目
文件部分开始偏移量2无文件部分开始的偏移量
特征码提取如下：
datasize eq 24
.{0}|c5|.{4}|40|

4.1.2 重新请求文件回应报文

文件在该客户端找到，协议格式：
协议大小默认值说明
协议号10xc5
大小4无字段协议号和大小后续的负载内容长度
类型10x91请求的操作类型码
所在队列位置2无所要请求客户端在请求队列中的位置
特征码提取如下：
datasize eq 8
.{0}|c5|.{4}|91|


文件在该客户端找到，协议格式：
协议大小默认值说明
协议号10xc5
大小4无字段协议号和大小后续的负载内容长度
类型10x92请求的操作类型码
特征码提取如下：
datasize eq 6
.{0}|c5|.{4}|92|

4.2.3队列满报文
协议格式
协议大小默认值说明
协议号10xc5
大小4无字段协议号和大小后续的负载内容长度
类型10x93请求的操作类型码
特征码提取如下：
datasize eq 6
.{0}|c5|.{4}|93|

5．特征码汇总
红色字体的部分为不容易误报，且该类报文在正常的通讯中是必要的。
1．eDonkey部分
1．客户端登陆服务器的报文特征码：
datasize gt 56
.{0,0}|e3|.{4,4}|01|.{16}|00 00 00 00|
2．服务器回应登陆报文征码可以：
datasize gt 8
.{0}|e3|.{4}|38|.{2}warning
或者.{0}|e3|.{4}|38|.{2}server
或者.{0}|e3|.{4}|38|.{2}warning
或者.{0}|e3|.{4}|38|.{2}error
或者.{0}|e3|.{4}|38|.{2}\[emDynIP
3．客户端提供本地可用的共享文件列表报文特征码：
datasize gt 10
{0}|e3|.{4}|15|

4．请求服务器列表报文特征码：
datasize eq 6
. {0}|e3 01 00 00 00 14|

5．服务器列表反馈报文特征码：
datasize gt 12
.{0}|e3 |.{4}|32|

6．服务器状态反馈报文特征码：
datasize eq 14
.{0}|e3 09 00 00 00 34|
举例：
7．Hello报文特征码：
特征码提取如下：
datasize gt 39
.{0}|e3 |.{4}|01 10|
8．请求部分文件实体报文特征码：
datasize eq 46
.{0}|e3 29 00 00 00 47|

9．发送所请求文件内容报文特征码：
datasize gt 30
.{0}|e3|.{4}|46|

10．请求文件部分HASH值报文特征码：
datasize eq 22
.{0}|e3|.{4}|51|

11．文件下载请求报文特征码：
datasize eq 22
.{0}|e3 11 00 00 00 54|

12．文件请求报文特征码：
datasize eq 22
.{0}|e3 11 00 00 00 58|
或者
datasize eq 27
.{0}|e3 16 00 00 00 58|
2．eMule独有部分
除去与eDoneky重合的报文外，eMule独自拥有的报文格式：
1．发送压缩文件报文
TCP报文
datasize gt 30
.{0}|c5|.{4}|40|
2．请求源文件报文
TCP报文
datasize eq 22
.{0}|c5|.{4}|81|

3．重新请求文件报文
UDP报文
datasize eq 24
.{0}|c5|.{4}|40|

4．重新请求文件回应报文
UDP报文
datasize eq 8
.{0}|c5|.{4}|91|
或者
datasize eq 6
.{0}|c5|.{4}|92|

5．队列满报文
UDP报文
datasize eq 6
.{0}|c5|.{4}|93|