通过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有高树的片子可以看……
是不是可行?我不知道,等我找到对应的代码,可能要到过年了。