通过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有高树的片子可以看……

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

相关日志

发表评论