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

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

搜索结果列表项格式：

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

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

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

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

单个文件条目描述我就不细写了，比较有用的字段是文件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有高树的片子可以看……

你还想看

• Windows XP的无线桥接

Windows XP Home Networking: Building Network Bridges
Bridge May Not Work With a Non-Promiscuous Mode Network Adapter

其中，提到了一个东西：”Promiscuous Mode”。原来，网卡工作在普通状态时，只接收属于自己的MAC地址的以太网包。只有当工作在”Promiscuous Mode”时，才不加限制地接收所有的以太网包。大部分的普通网卡都可以工作在”Promiscuous Mode”，可能为了安全起见，大部分的无线网卡都不能工作在”Promiscuous Mode”下。当Windows创建桥接模式时，实际上在系统里面创建了一个虚拟的新的网卡，这个新的网卡有自己的MAC地址，桥里面的所有网卡都以这个新的MAC地址发送以太网包，回送的以太网包自然也是发给这个新的MAC地址，由于普通网卡支持”Promiscuous Mode”，所以可以接收到不属于自己的新的MAC地址以太网包，所以通讯正常，无线网卡会抛弃掉所有不属于自己MAC地址的包，所以在桥接模式下收不到任何发回来的以太网包，自然就不能正常工作了。Windows XP提供了一个解决办法，叫ForceCompatibilityMode（强制兼容模式），在命令行（cmd）下，打入netsh bridge show a，可以看到已经桥接的各个网卡的编号和是否启用强制兼容模式，如果无线网卡显示”已停用”或者”未知”，应记住无线网卡的编号，并在命令行下打入：netsh bridge set a X e，其中X是无线网卡的编号，以启用强制兼容模式。

这个兼容模式的原理是这样的，一旦某个网卡启用了这个模式，当从这个网口向外发送以太网包时，将改写以太网包，把源地址换成网卡自己的MAC地址，并记住这个转换，回复的以太网包的目标地址也是网卡的MAC地址，这样网卡就不会丢弃这个包，当这个收到这个回复包后，再根据原来的记忆，把目标地址换回原来的地址，和IP层的NAT的原理类似。

通过这样设置以后，当拔掉网线，启用无线网络连接后，依然可以上网，并且IP地址不变，整个过程自动完成。

你还想看

• 通过emule做DDOS是否可行？