[Tips]通过emule做DDOS是否可行？

by 云舒

2008-07-23

http://www.ph4nt0m.org

今天抽空看了下emule协议几个可能会出问题的地方，初步感觉是可能真的有问题。下了代码回来看了，不过代码太大，目前还没找到地方，没法对想法进行印证。我简单的说下，看哪位代码牛人能够在项目中找到对应的代码。

首先是在客户端连接到服务器之后，搜索文件时，服务器返回结果的报文。报文中返回的结果是一个集合，每个集合表示一条记录。但是每条记录中，并不包含拥有 该文件的客户端的IP地址，而是返回的拥有该文件的客户端的ClientID和端口。这里我猜测ClientID的计算是可逆的，搜索发起者可以根据这个 ClientID计算出IP地址，然后连接，请求下载文件。具体报文结构如下：

名称	大小（字节）	默认值	注释
协议类型	1	0xE3
大小	4		不包含报文和大小域的报文大小
类型	1	0x16	操作码 OP SEARCHRESULT 的值
结果数	4	N/A	此报文中包含的结果数目
结果列表	可变	N/A	一个结果的列表

搜索结果列表项格式：

名称	大小（字节）	默认值	注释
文件HASH	16	N/A	用于识别文件的 Hash 值
客户端 ID	4	N/A	eMule服务器分配给客户端的ID
客户端端口	2	N/A	客户端的监听的TCP端口
标志数	4	N/A	其后的属性标志个数
标志列表	可变	N/A	标志列表

其次的第二个地方是下载文件的地方，客户端要求下载一个文件时，服务器会返回一个源查找结果报文。该报文也是只包含源的ClientID和端口，客户端应该是按照ClientID计算出IP地址，再去连接下载文件的。具体报文如下：

名称	大小（字节）	默认值	注释
协议类型	1	0xE3
大小	4	N/A	不包含报文头和大小域的报文大小
类型	1	0x42	操作码 OP FOUNDSOURCES 的值
文件HASH	16	N/A	相关文件的 Hash 值
源数量	1	N/A	拥有该文件的机器的数量
源列表	可变	N/A	源列表内容，每一条是一个可用源

每一条源的报文格式如下：

名称	大小（字节）	默认值	注释
客户端 ID	4	N/A	共享该文件的客户端的 ID
客户端端口	2	N/A	共享该文件的客户端端口

可以看到，搜索某个文件时，服务器返回的搜索列表中按照ClientID来区分不同的其它客户端。在开始下载一个文件时，服务器返 回的可用源列表中，每个源也是以一个ClientID来表示的。也就是说，没一个ClientID就可以确定一个源，区分开彼此。而emule可以根据这 个ClientID找到对应的客户端，去连接指定端口，请求文件。那么，现在的问题是这个ClientID是哪里来的？

原来这个ClientID在正常情况下，是我们连接到emule服务器时，服务器分配给我们的。但是注意到，在连接之后，我们可以像服务器提供我们所拥有的文件列表，报文格式如下：

名称	大小（字节）	默认值	注释
协议类型	1	0xE3
大小	4		不包含报文和大小域的报文大小
类型	1	0x15	操作码 OP SEARCHRESULT 的值
文件数	4	N/A	共享列表中的文件数，这个数不超过 200
文件列表	可变	N/A	可选的文件列表,单个项的描述见下

单个文件条目描述我就不细写了，比较有用的字段是文件Hash码，ClientID，以及端口。这样看来，我们在连接到服务器之 后，告诉它baidu的IP地址，TCP80端口，有赤壁下载，或者有XXX片下载，别人下载的时候，emule客户端会不会从服务器返回的可用源列表 中，找到这条记录，并且去连接？

关键问题到了ClientID的计算，协议中这样描述的：假设 IP 地址为 X.Y.Z.W,则客户端 ID 按公式 X+28*Y+216*Z+24*W (Big Endian[6])计算。如果想法是正确的，那么我们可以先计算出百度的IP地址的ClientID，端口设置为80，然后通知服务器，这个 ClientID有高树的片子可以看……

是不是可行？我不知道，等我找到对应的代码，可能要到过年了。