从苹果的 Xcode 事件来多了解一点 迅雷下载 的真相

最近的 苹果Xcode 开发工具被感染 XcodeGhost 病毒事件闹得沸沸扬扬,让我等平民百姓也来了兴趣。

事情的经过是这样的:由于一些众所周知的原因,苹果官方站点的 Xcode开发工具 无法正常下载。于是国内某人士就镜像了一份Xcode,并公开了其下载地址,让公众(包括小众和大众)下载。

这看似是一个善举,但是,作者所提供的下载 *不是* 一份干净的、原始的镜像,而是作者修改过的版本(见github上面的说明)。此修改导致的直接后果就是:使用此Xcode编译的苹果app应用都有一段后门程序,该后台程序会直接接收相关的指令并执行(包括但并不限于作者本人所陈述的仅仅是收集app信息(据互联网))。其导致的严重后果可想而知。然而该修改版本的Xcode的使用者竟然覆盖面相当广,包括但不限于腾讯公司(微信)、网易、一些银行机构。并且,使用此Xcode编译出来的app竟被正常地放到苹果的AppStore供大家下载(现已被下架),其受害者不计其数。然而这更让人意想不到的是,此后门程序居然跑了足足有半年之久才被发现。这一度让人们置疑苹果公司的安全审核机制到底出了什么问题。

好了,我不是自媒体,更多相关的信息请搜索。而我今天本来要说的重点是关于迅雷下载的。迅雷下载在带来高速下载的同时其内部的p2p共享机制出了什么问题。

先打开苹果官方的Xcode下载页面(http://adcdownload.apple.com/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg)看看吧:

可以知道的是,这个下载链接已经失效了。我有意把网络请求过程展示了出来,如果你懂这方面(HTTP协议)的话,应该了解该页面的请求是这样的一个过程:

  1. 浏览器请求下载文件 http://adcdownload.apple.com/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg,服务器返回 302临时重定向 到页面 http://adcdownload.apple.com/unauthorized/;
  2. 浏览器请求上述 302 后的页面,服务器返回 301永久重定向 到 HTTPS 安全页面 https://adcdownload.apple.com/unauthorized/;
  3. 浏览器请求上述 301 后的安全页面,服务器返回了 成功(200),并附带了正文内容。
从技术层面来说,虽然中间经过了多次重定向(包括301和302),但最终由于服务器返回的是代表成功的200,并不是标题和正文内容所标识的“未授权”(HTTP代码401)、此文件已不存在(HTTP代码404)、禁止访问(HTTP代码403)。所以这也就意味着:当前所显示的页面正文就是你所请求的文件 http://adcdownload.apple.com/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg 的内容。简单来说就是:/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg 文件的内容就是此页面正文,该 .dmg 文件是一个类型为 text/html 的网页文件。该页面是动态生成的,请求所生成的类型(MIME)由 HTTP头部的 Content-Type 决定,跟所请求的资源的后缀(.dmg)无关。(静态资源多数由后缀确定类型)。

但是,迅雷却未按照HTTP协议的规定正常返回文件(也许是因为其内部的某种共享机制、死链解决机制),下载正常进行,有图有真相:


下载完全正常地进行,没有任何信息显示源(原)文件已经不存在。点击下载项右边的箭头来看看详情页面的任务分块信息:


注意到我加下划线的部分:原始地址来源: 0% 0.00B,这也就说明:当前的下载完全不是来自原始站点(苹果官方),而是来自:镜像加速、P2P加速、离线下载加速。

因此,正如前面所说:如果不是从任务分块信息去仔细发现问题,迅雷不会直接以任何形式的通知告知用户:当前所下载文件的链接已是死链,文件内容完全来自非官方

迅雷解决死链的机制给大家带来了好处。但是其对用户过度透明却犯了严重错误。下载软件最起码的要求应该有一条是:我请求什么,你就应该给我什么,不论你以何种方式的加速。保证请求的正确是前提,加速是你额外理应提供的。

发表于:2015年09月26日 ,阅读量:856 ,标签:迅雷 · 苹果

版权声明:若非特别注明,本站所有文章均为作者原创,转载请务必注明原文地址。