哪款 BT Client 的[校验]功能可信?

[YGHMXFAL]

前情提要:

书接上回,曾经发过一帖,求问如何校验网盘离线下载得数据是否正确,当时找到得办法是:

添加 torrent,设置存储目录为已有数据(由网盘离线下载得到)所在目录,触发 BT 客户端的校验

今天闲得蛋疼,一顿操作,发现这个办法也不可靠

环境:

WIN 10 X64+transmission(4.0.6)+qbittorrent(4.6.6)

这仨货都已经检查了 HASH/数字签名

操作:

①先使用[迅雷]随便下载好一部电影,比如[破墓.MP4],退出迅雷

②再使用 qbittorrent 添加同一个 torrent 到下载队列,设置[临时存储目录]为[迅雷下载目录],设置另外一个不同地目录为[最终存储目录],开始下载任务

③可以看到 qbittorrent 立即开始校验数据,校验结束后,也看到[破墓.MP4]确实被移动到了[最终存储目录]

到这里为止一切正常

④打开终端,执行命令:

date +'%s' &>>'破墓.MP4'

也就是追加一条时间戳(或者随便什么数据)到视频尾部

sha512 '破墓.MP4' &>HASH

记录被破坏视频的摘要值

⑤再从 qbittorrent 中[强制重新校验]该下载任务,结果不报错?

再重新计算该视频的摘要值,发现和第④步中记录的摘要值一致

也就是说,qbittorrent 识别不出这样地意外?这个所谓地“校验”完全不可靠啊?

⑥在 transmission 中重复同样地测试,也是同样地结果

⑦GITHUB 上找到了几个 torrentcheck 的 fork,其中有几个会检查[数据长度],因此能够探测到这种“意外”

你们有兴趣就复现一下?

[v2tudnew]

确实能复现，也许是因为 BT 客户端是按区块校验，而你这种方式是追加了数据。
所有区块完整的情况下对于客户端来说就是完成任务了。
试试篡改中间数据看看？

[YGHMXFAL]

@v2tudnew #1 确实没想到居然多了 piece 就直接不管了,篡改中间数据肯定要报错(吧)