原来迅雷投毒是真的。。。

2015-09-21 13:08:27 +08:00
 est
首先说,一般的迅雷 http 下载是没太大问题的。

但是,迅雷默认开启 p2p

投毒者破解了迅雷协议,故意弄一个高上传带宽固定 ip 的机器,去响应 [正确] 的 xcode 下载的 p2p 请求,但是返回的是 [修改过] 的 dmg 包。。。。。。。。。。。。

纯转
7712 次点击
所在节点    信息安全
21 条回复
aisk
2015-09-21 13:10:36 +08:00
迅雷不会验证整个文件的 hash 吗?
yksoft1
2015-09-21 13:12:12 +08:00
官方 XCode 下载是要登录 Apple ID 、用 Session 验证的,迅雷的离线服务器会登录这个么
iF2007
2015-09-21 13:12:34 +08:00
p2p 就不校验 Hash 了?
est
2015-09-21 13:13:17 +08:00
@aisk 黑盒。目前没确切证据表明迅雷会校验。但是倒是 /t/222018 这个帖子有案例说明下载出来文件对应不上。

再更新一个例子:

http://a.com/1.rar 有 100G ,通过迅雷下载,下载前一瞬间,其实 1.rar 内容已经变了,大小不变。这个时候我记得迅雷依然会通过 p2p 加速下载老版本的。
est
2015-09-21 13:14:51 +08:00
@iF2007 看一篇老文章作为参考:

http://blog.binux.me/2012/03/hash_algorithm_of_xunlei/

> cid 主要用于文件的索引。观察代码可知, cid 并没有 hash 整个文件,而是根据文件的头 /中 /尾部的 0x5000 字节的内容计算 Hash 。这样就可以在不下载完整个文件,就能够查询到其他服务器上可能的相同文件。于是在下载支持 range 的文件的时候,即使该地址没有被索引到,但是通过 cid ,依旧可以被 p2sp 加速。
breeswish
2015-09-21 13:15:13 +08:00
@yksoft1 登录后点击下载获得的下载地址不需要登录也可以下载
EPr2hh6LADQWqRVH
2015-09-21 13:15:38 +08:00
我支实在太欢乐了,奇技淫巧层出不穷,还是核平了吧
breeswish
2015-09-21 13:17:51 +08:00
@est 迅雷官方人员说迅雷会校验的,以及最先说 xcode 从迅雷上下载被投毒的那位后来澄清了,是他自己下载了两次,第二次用迅雷下的是百度网盘上的

我遇到过迅雷下载和官方下载不一致的,情况是:

1. 链接以前可以下载
2. 后来链接被墙了
3. 再后来链接里下载的内容发生了更新

于是用迅雷下载回来了一个老版本…
iF2007
2015-09-21 13:19:14 +08:00
@est
66beta
2015-09-21 13:34:30 +08:00
迅雷怎么会不校验呢?滤网行动可是积极参与了
est
2015-09-21 13:59:58 +08:00
@breeswish 虽然和这次 xcodeghost 可能无关,但是我觉得迅雷投毒是可行的。
dikcen
2015-09-21 14:15:32 +08:00
补充一个亲身经历的例子:官网下载 acrobat pro ,用迅雷下来一个“管家”。不说 hash ,一个几百 M ,一个五十多 M 。怀疑迅雷没有合适的“验正”机制。
songco
2015-09-21 14:25:44 +08:00
没问题的方式应该是:
1. 用迅雷下载某个 url
2. 从 url-->hash 数据库中查找
3. 通过查找到的 hash 用 p2p 网络进行加速

我觉得很可能在第 2 步迅雷为了提高速度进行了"优化", 比如在某些情况下只用文件的部分信息进行匹配(比如文件名, 或者文件开头)
yexm0
2015-09-21 14:38:30 +08:00
迅雷官方已经辟谣。
Gandum
2015-09-21 14:49:39 +08:00
因为部分地区的移动宽带网络下, ISP 会故意给你发假数据包,使你下载不下来或者下载错误的文件,逼你放弃迅雷。没错,我就是这样的移动用户,而且我一定要和移动斗到底,所以我很早之前就开始关注“迅雷是否验证 hash"的问题。

首先用 torrent 或者 magnet 进行 BT 下载,是可以进行整个文件的 hash 验证(这也是移动这个老逼养的会被我抓住,而且我认定问题就在移动不在迅雷的原因)
BT 在设计的时候,就提供了这样的功能。

问题就是 HTTP/HTTPS 下载,以及迅雷将 HTTP 下载后的结果转化为 BT 下载的问题。

为什么?因为 HTTP 本来就没有验证整个文件 hash 的能力啊
好吧,就算是 header 里面写了 hash ,那么这个 header 也可以伪造啊

所以你把 HTTP 的内容换掉,然后让迅雷再去离线,然后说迅雷,你下载的怎么还是上一个文件呢?这种实验,根本没啥意义,因为 HTTP 不能预先提供整个文件的 hash ,所以验证 hash 也得等到下载完,那么迅雷可能会对于每个用户的请求都重新下载一遍吗?更不要说是同一个用户的两遍请求?

!!!!!!!!!!!!!!!!
!连 DNS 服务器都还需要刷新时间!
!!!!!!!!!!!!!!!!

所以这个问题,是一种“体制问题”,本来就没有必要怪罪它太多,反正迅雷就是用来下载电影电视剧的。
这个锅,就是得要开发者自己背起来。

反正一边图方便,一边图安全,想得美。要是想安全啊,就是应该不使用迅雷。





但是肯定有人说我说的驴头不对马嘴,因为楼主说的是迅雷是否故意(或者被动)投毒的问题。
我只能说:现在没有更多的证据,这个只能存疑。
Gandum
2015-09-21 14:55:14 +08:00
哦,对了,忘记说了:
ISP 会给你发假数据包甚至替换掉整个资源,特别是那些下载到应用宝,或者电脑管家的,自己注意了。

反正我宁愿信任民企的操行,这些国企,下面随意一个地方都能乱插广告,搞劫持,就这种玩意。
imn1
2015-09-21 15:10:26 +08:00
相反, http 估计不会校验(确切说不会对大字节全文件 hash ),但 p2p 会校验, p2p 是多源片段下载,不校验几乎没一个正确了
AKQJT
2015-09-21 16:27:27 +08:00
以前不是有人用迅雷 DDOS 嘛 都是利用协议漏洞 引导到其它地址下载文件
florije
2015-09-21 17:09:36 +08:00
不要乱说话好不好~~他们那么大企业能不搞校验么~~
迅雷公布 XcodeGhost 污染源链接列表 http://weibo.com/p/1001603889523175065085
Antonidas
2015-09-21 17:46:17 +08:00
我说一个不知道是迅雷的锅还是移动宽带的锅:
以前玩 BF3 的时候,登 battlelog 需要下一个浏览器插件,我用迅雷下和直接下下来的东西完全不一样,大小都不同,更别说用了。
看到有人说迅雷下下来的那个是以前用过的版本,貌似是哪里有缓存,这个就不清楚了。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/222412

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX