这是一个创建于 3350 天前的主题，其中的信息可能已经有所发展或是发生改变。
首先说，一般的迅雷 http 下载是没太大问题的。
但是，迅雷默认开启 p2p
投毒者破解了迅雷协议，故意弄一个高上传带宽固定 ip 的机器，去响应 [正确] 的 xcode 下载的 p2p 请求，但是返回的是 [修改过] 的 dmg 包。。。。。。。。。。。。
纯转
但是，迅雷默认开启 p2p
投毒者破解了迅雷协议，故意弄一个高上传带宽固定 ip 的机器，去响应 [正确] 的 xcode 下载的 p2p 请求，但是返回的是 [修改过] 的 dmg 包。。。。。。。。。。。。
纯转
 |
1
aisk 2015-09-21 13:10:36 +08:00
迅雷不会验证整个文件的 hash 吗？
|
 |
2
yksoft1 2015-09-21 13:12:12 +08:00
官方 XCode 下载是要登录 Apple ID 、用 Session 验证的，迅雷的离线服务器会登录这个么
|
 |
3
iF2007 2015-09-21 13:12:34 +08:00
p2p 就不校验 Hash 了？
|
 |
4
est OP @aisk 黑盒。目前没确切证据表明迅雷会校验。但是倒是 /t/222018 这个帖子有案例说明下载出来文件对应不上。
再更新一个例子： http://a.com/1.rar 有 100G ，通过迅雷下载，下载前一瞬间，其实 1.rar 内容已经变了，大小不变。这个时候我记得迅雷依然会通过 p2p 加速下载老版本的。 |
|
5
est OP @iF2007 看一篇老文章作为参考：
http://blog.binux.me/2012/03/hash_algorithm_of_xunlei/ > cid 主要用于文件的索引。观察代码可知， cid 并没有 hash 整个文件，而是根据文件的头 /中 /尾部的 0x5000 字节的内容计算 Hash 。这样就可以在不下载完整个文件，就能够查询到其他服务器上可能的相同文件。于是在下载支持 range 的文件的时候，即使该地址没有被索引到，但是通过 cid ，依旧可以被 p2sp 加速。 |
 |
7
EPr2hh6LADQWqRVH 2015-09-21 13:15:38 +08:00  2
我支实在太欢乐了，奇技淫巧层出不穷，还是核平了吧
|
 |
8
breeswish 2015-09-21 13:17:51 +08:00
@est 迅雷官方人员说迅雷会校验的，以及最先说 xcode 从迅雷上下载被投毒的那位后来澄清了，是他自己下载了两次，第二次用迅雷下的是百度网盘上的
我遇到过迅雷下载和官方下载不一致的，情况是： 1. 链接以前可以下载 2. 后来链接被墙了 3. 再后来链接里下载的内容发生了更新 于是用迅雷下载回来了一个老版本… |
 |
10
66beta 2015-09-21 13:34:30 +08:00
迅雷怎么会不校验呢？滤网行动可是积极参与了
|
 |
12
dikcen 2015-09-21 14:15:32 +08:00
补充一个亲身经历的例子：官网下载 acrobat pro ，用迅雷下来一个“管家”。不说 hash ，一个几百 M ，一个五十多 M 。怀疑迅雷没有合适的“验正”机制。
|
 |
13
songco 2015-09-21 14:25:44 +08:00
没问题的方式应该是:
1. 用迅雷下载某个 url 2. 从 url-->hash 数据库中查找 3. 通过查找到的 hash 用 p2p 网络进行加速 我觉得很可能在第 2 步迅雷为了提高速度进行了"优化", 比如在某些情况下只用文件的部分信息进行匹配(比如文件名, 或者文件开头) |
 |
14
yexm0 2015-09-21 14:38:30 +08:00 via Android
迅雷官方已经辟谣。
|
 |
15
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 服务器都还需要刷新时间！ ！！！！！！！！！！！！！！！！ 所以这个问题，是一种“体制问题”，本来就没有必要怪罪它太多，反正迅雷就是用来下载电影电视剧的。 这个锅，就是得要开发者自己背起来。 反正一边图方便，一边图安全，想得美。要是想安全啊，就是应该不使用迅雷。 但是肯定有人说我说的驴头不对马嘴，因为楼主说的是迅雷是否故意（或者被动）投毒的问题。 我只能说：现在没有更多的证据，这个只能存疑。 |
|
16
Gandum 2015-09-21 14:55:14 +08:00
哦，对了，忘记说了：
ISP 会给你发假数据包甚至替换掉整个资源，特别是那些下载到应用宝，或者电脑管家的，自己注意了。 反正我宁愿信任民企的操行，这些国企，下面随意一个地方都能乱插广告，搞劫持，就这种玩意。 |
 |
17
imn1 2015-09-21 15:10:26 +08:00 1
相反， http 估计不会校验（确切说不会对大字节全文件 hash ），但 p2p 会校验， p2p 是多源片段下载，不校验几乎没一个正确了
|
 |
18
AKQJT 2015-09-21 16:27:27 +08:00
以前不是有人用迅雷 DDOS 嘛 都是利用协议漏洞 引导到其它地址下载文件
|
 |
19
florije 2015-09-21 17:09:36 +08:00
不要乱说话好不好~~他们那么大企业能不搞校验么~~
迅雷公布 XcodeGhost 污染源链接列表 http://weibo.com/p/1001603889523175065085 |
 |
20
Antonidas 2015-09-21 17:46:17 +08:00
我说一个不知道是迅雷的锅还是移动宽带的锅：
以前玩 BF3 的时候，登 battlelog 需要下一个浏览器插件，我用迅雷下和直接下下来的东西完全不一样，大小都不同，更别说用了。 看到有人说迅雷下下来的那个是以前用过的版本，貌似是哪里有缓存，这个就不清楚了。 |
Select Language