这是怎么回事？本来当时就准备抓包看看的，但是一直没时间，直到现在才能腾出时间来抓包分析一下。
首先拿使用者最多的某软件7.02版来测试，我抓包使用的是著名的开源网络工具Wireshark。关闭所有访问网络的程序（包括Windows Update服务），开始抓包，运行此软件7.02版，出现多次错误提示框，但最后能成功连接代理服务器。停止抓包，我们来看看：
软件发出的第一个数据包是个ping，目的地好像是微软的一个服务器，没收到回应。不过第二个包就是软件真正开始工作了。软件首先向某个DNS服务器发出对某个子域很长且似乎是根据某种算法生成的域名的MX请求。
问题就在于在第二个包发出的极短时间（20毫秒）内收到的第三个包。这个包看上去来自第二个包的目的服务器，但是其DNS响应部分却是个错误的、仅有5字节长度的数据。
注意这个包的TTL是131。让我们再看下一个包，第4个包，看上去也是第2个包的目的服务器所返回的：
包2原本是一个MX请求，而这个包却明显是个A应答，这显然是答非所问；而且仔细看返回的那个IP地址，如果你有看过我的《Google https阵亡和第0层黑IP表更改》就知道，这明显是一个DNS劫持的包。但是在这里，正因为它答非所问，代理软件可以直接将其忽略，因此起不到劫持的作用。其TTL仅为70，很可能和包3来自不同的服务器。
真正的响应包是请求包发出后250多毫秒才收到的，是一个MX应答。
其实际内容明显是加密的数据，用在代理软件里应该是代理IP或者下一层得到代理IP的地址之类。TTL为42，说明真实响应包和包3、包4来自不同的服务器。请注意这个dns服务器的管理人记录，它也证明了这个包才是对包2的真实响应。
此软件同样会通过A包来询问地址，不过这种就会被类似包4的劫持包所劫持（除非软件自己实现了DNS，能够分辨劫持包和真实包）
对其他会出错的代理软件按同理抓包，结果非常类似，都出现了大量错误的DNS响应包。有意思的是，这几个软件中多数通过TCP上的自定义协议、使用随机端口与代理服务器通信，也有使用SSL、TLS通信的，还有一个软件通过UDP，将数据包伪装为ISAKMP协议的数据包与代理服务器通信。
处理畸形的DNS响应不当，以前Windows的DNS服务就出过此类BUG，但是它的结果是发送大量DNS请求，最终能导致远程DNS污染而并不会使DNS服务出错；而这里老大哥使用的方式，应该是通过调试找到了此类代理软件DNS部分（或者其与系统DNS服务间的接口，如果其DNS服务并非自己用UDP实现）的BUG并加以利用。因此在接到用户报告后，这些软件的下一个版本全都修复了此BUG，不再因错误DNS响应包而出错。另外，这些软件的界面线程、错误报告线程和代理服务、网络控制线程应该是分开的，因此如果忽略出错提示，软件仍然有可能成功实现代理服务器功能。
另外在对某软件7.02版的抓包中，发现此软件不仅通过DNS MX请求和A请求来获得代理服务器地址，也能通过一些特定的Web地址来获取。
据我的查证，第一个是Google为移动设备而开发的网页重格式化代理，第二个是Google Translate，通过他们访问某个指定网址获取服务器地址；第三个通过Appspot上的某个应用获得服务器地址；那两个Yahoo视频的用户首页上的个人信息中，存在着加密的数据，应该也是服务器地址相关的。这些地址直接上去都会无法访问，估计老大哥的人一直在跟踪抓包、分析关键词；但是在抓包中似乎访问都成功了，没看到几个异常的、快速出现的TCP RST包跟着，我没有仔细调查其HTTP头的内容，但是肯定在这里面有文章。
懒得继续看，反正他们的加密方式我搞不清。我把所有抓包文件丢上线，想看的自己继续看吧。。http://www.mediafire.com/?9eyq1vd1q13bdcd
