9月8号 秒传txt/115秒传链接导入失败，上传失败，云盘中不存在此Sha1

[yayaleslie]

文件是有的，用小白羊创建的，导入不成功

[liupan1890]

我去测试一下

[liupan1890]

经过抓包测试，程序调用并无错误，参数正常，但阿里云盘返回了跟以前不一样的结果：rapid_upload: false

1.可能是阿里云盘在升级调整，以后可能会恢复

2.可能是阿里云盘正式下线了旧版秒传接口，以后不再支持sha1+size的秒传方式

我记得我昨天还秒传过一堆光盘镜像来着，没想到今天就遇到调整了

当前秒传txt使用的接口为旧接口https://api.aliyundrive.com/adrive/v2/file/create
当前上传本地文件 ( 支持秒传 ) 使用的接口为新接口https://api.aliyundrive.com/adrive/v2/file/createWithFolders
新接口的秒传功能必须存在本地文件才能计算proof_code参数实现秒传，所以如果彻底切换为新接口，以后无法恢复秒传txt的导入功能

--还是有人问，补充说明一下
秒传功能时通过调用create，传入sha1++size实现的
当前阿里云盘调整后，此接口已失效，阿里云盘提供了新的接口createWithFolders

新的接口createWithFolders，需要传入sha1++size++proof_code 3个参数
小白羊v2.8.30上传本地文件时是使用的新接口，所以本地文件可以继续秒传
小白羊v1.6.28上传本地文件时是使用的旧接口，所以本地文件也不能秒传，会完整的走流量上传

是否可以通过新接口恢复秒传链接的导入呢？
答案是不能，新接口是类似随机，提取文件的8个字节内容计算出proof_code。
只要本地硬盘上没有这个文件，就无法计算proof_code，
所以后续也无法通过新接口恢复秒传链接的导入功能

关于 proof_code 计算方法，参见#199

最近阿里云盘一直在推广分享链接，搞了个活动，创建分享链接转发出去，根据保存此链接的人数，定期发放奖励

奖励为2年期的网盘容量，最高可奖励10TB网盘容量

由此可以联想些什么，希望仅仅是临时性调整吧

[liupan1890]

另：本地文件的秒传不受此影响，从本地拖放文件上传仍然可以秒传。
受影响的功能为：秒传文件(txt/json) ,aliyunpan://秒传，115秒传链接，115分享，聚合搜索功能

[maomaochong199]

大变天

[Tensor1024]

我靠!

[CersOps]

前天还在想利用秒传txt间接无限空间这事靠谱靠谱来着。然后找了个不咋需要的大资源试了一下，生成秒传txt，删除云盘文件，腾出来两三百G空间，还挺开心来着，结果昨天就凉了，资源无了。。。。

[xuxudong1110]

晴天霹雳，刚收藏了一堆sha1准备有空转存，没想到就封了

[yayaleslie]

没有秒传，有点难受。。。

[Lyoko-Jeremie]

@liupan1890
看这个 proof_code 的计算，感觉云端要验算的工作也得读取原文件才行
给人有点chia币在P盘的味道

【闻到了硬盘燃烧的味道】

或许这个模式不会弄很长时间

[JsonSong89]

@liupan1890
看这个 proof_code 的计算，感觉云端要验算的工作也得读取原文件才行
给人有点chia币在P盘的味道

【闻到了硬盘燃烧的味道】

或许这个模式不会弄很长时间

参见用户侧代码
#199

start和end由前端用户侧计算,然后你看核心的那句
const buffb = buff.slice(start, end);
云端只需要读取了很少量的二进制流,io占用其实并不高,就足以对前端计算的code进行校验...

[Lyoko-Jeremie]

@JsonSong89
I/O占用确实不高，但是禁不住在大量请求的条件下，如果频繁命中同一个磁盘，HDD那巨长的寻道时间和由此带来的巨长的IO等待队列，绝对够HDD吃一壶的，（更何况Raid模式会导致请求放大）。而且这样对硬盘磁头的损耗会比通常顺序读取的情况下大得多。即使是使用高速缓存，也会存在大量的缓存击穿。

我觉得这样的算法设计，站在架构设计的角度来说是划不来的（有重大缺陷）。

感觉可以DDoS打它一下？

[JsonSong89]

@Lyoko-Jeremie
嗯,磁头损耗这个到确实比较大,不过这个只是读,应该不会放大吧.
而且不知道云服务商还用不用hdd

还有个可能是他们的文件类型根本就是自定义的存储模式,并不是传统的文件系统.
比如给内容->磁道位置弄一个倒排索引什么的
你看oss的文档
https://help.aliyun.com/document_detail/31980.html
本身就已经自带了range入参,网络文件系统天然就需要分片的,
他们在设计oss的时候就有这个功能了,都不是现在新开发的东西.

[sea72]

我是这样理解的
我感觉这业务量就类似于打开一个视频文件，然后拖动一下进度条。
看起来还可以接受。
但是考虑到一次可能要验证好几百个文件，就不清楚了。不过，如果是ssd架构，这问题好像就不存在了。

ddos也好应对，直接把转存这一块业务降级就没了。反正也不是主要业务类型。

[Lyoko-Jeremie]

@JsonSong89 @sea72 我觉得云服务商怎么绕来绕去，文件存储也绕不开 HDD主存+SSD高速缓存，纯SSD存储的代价太高了
倒排索引要切词，这个对于二进制文件存储来说应该是做不到的

倒是Rang索引这个可以做到，大规模分布式文件存储系统肯定是基于文件块存储的，例如MongoDB的GridFs那种模式。（这个我倒是忽视了）

唔~~~~

[liupan1890]

你们是不是有什么误解？？？？？？

真的，误解

1.文件在你的电脑上
2.你要上传这个文件
3.阿里云盘需要你执行上面的校验算法（阿里云盘PC版/网页版/小白羊 自动去执行）
4.执行过程中需要读取这个文件的8个字节的内容
5.上传文件或者秒传文件

所以，意思是，如果你的电脑上没有这个文件，就无法上传/秒传。

以前旧版本你的电脑上没有这个文件，也可以通过sha1+Size秒传

那么你们讨论的磁头，也是你们自己的电脑的磁头。跟云服务商没有关系

最后，因为算法里会根据每个用户的当时的token去计算出读取文件数据的起使位置，也就是每个人上传同一个文件，或者同一个账号在不同的时间上传同一个文件，所计算出的proof_code 都不一样。也就杜绝了通过保存文件的proof_code 让别人实现秒传的方式。每个人必须自己的电脑上有这个文件，才能秒传

这也是不能通过新版接口，去开发出新的秒传功能的原因。

[Lyoko-Jeremie]

@liupan1890 我们在讨论的是这个接口的弱点

说的磁头也是云服务商的磁头，毕竟无论怎么存储，最终还是要落到HDD/SSD和磁带上，不可能凭空存储在“云”上

就好像网络攻防一样，先要讨论攻击模型，然后讨论弱点，再讨论可能的攻击方案

毕竟，任何一个秒传方法都是基于接口设计的弱点来实现的

[Lyoko-Jeremie]

我倒是在想，有没有什么被快速"原像"攻击的HASH函数可以被利用

[JsonSong89]

你们是不是有什么误解？？？？？？

@liupan1890
用户侧发起的proof_code,让服务端也多了一次校验,本来服务端之前只需要比对hash和size这两个"固定常数"即可,现在还得找到原文件去读取动态的proof_code,所以我们在讨论这个读取动态的proof_code成本有多高,如果成本高,则很可能只是暂时行为.
不过目前看来,这个成本不算高,估计以后都没秒传了.

[JsonSong89]

我倒是在想，有没有什么被快速"原像"攻击的HASH函数可以被利用

先不说攻击成本,还有个近乎随机的access_token呢
确实是无解,我反正想不出一丝可能

[liupan1890]

用户侧发起的proof_code,让服务端也多了一次校验,

你说得对，我没从这个角度想过（完全没意识到）

不过继续去分析的话，每一次下载，每一次图片预览，每一次视频预览，都几乎是完整的读取了一遍文件，或者读取了大量的数据（相对于proof_code的8字节）

阿里云盘当然是用的阿里云的PDS,考虑到阿里云主机的本身的更新换代，感觉磁盘消耗就不值一提了

[liupan1890]

因为有近乎随机的access_token，等于每个人都在随机读取文件的8字节，任何快速原像，都没用吧？

只有有了文件的全部数据，才能确保每个人每次上传都能计算出proof_code来，

并且吧，proof_code本身就是读取的8字节，也没办法说通过提前计算出一个文件所有的可能的8字节数据组合，保存下来供他人直接读取的方式去操作，因为这就超过文件体积太多了，都不如直接保存文件上算

最后，唯一的方法就是，找一个有超大体积网盘空间的账号，或者有一堆账号组合获得超大体积网盘空间，
然后把这些文件存储到这个超大的帐号里，这样别人需要秒传时，根据access_token计算出proof_code的起始位置，
最后从这个账号里找到这个文件，下载8个字节（很快的），返给他，他就可以无文件秒传了

但是，这样的方式，简单一想也知道，1.要有大量账号，2.只能提供热门文件，3.要求账号本身先找到并上传/从分享链接导入这些热门文件， 4.需要经常更新资源。。所以肯定还是只能想想看不能实际操作了

[candlewill]

个人愚见：

由于const start = Number(BigInt('0x' + md5a.substr(0, 16)) % BigInt(buff.length)); ，那么存在一个小概率，使得start = length -1，如果这时候出现了：

那么，根据const end = Math.min(start + 8, buff.length);，这时end = length 。这时取[start, end]=[length-1, length)处文件内容，对应文件最后一位的值，就只存在两种情况0或1.

那么，proof_code就只有两种情况了，可以尝试固定proof_code为这两种情况，然后不断刷新，等待access_code变为使start变为length-1的情况出现。

[JsonSong89]

尝试固定proof_code为这两种情况，然后不断刷新

朋友你在开玩笑吧,首先如果是大文件,比如1G大小,那么刚好碰撞到length的概率是多少?8/1G啊(没仔细算,但不可能大于16/1G)
而且每个文件的length都不一样,你为了上传一个文件就不停刷新?

[liupan1890]

刷新access_code并不合适，因为阿里云盘那边会检测到有用户在短时间内，极其频繁的在重复登录。这个操作不正常

借由这个思路，其实，因为已经知道了start和end，也就是知道长度了（1-8）个字节，

每个字节呢又是8位（0/1）组合（组成的数字范围 0-255）
注：读取文件1个字节，是读取到8位数据，每一位数据是0或1，8位最大表示为数值255

所以做多可以有 256 的 8 次方种排列组合（既18,446,744,073,709,551,616 种），既proof_code的取值可能有180亿亿种

所以即使想要使用穷举8字节数据随机去碰撞，也很困难。阿里云盘的接口调用频率稳定的也就每秒调用10次，即使只有数万种组合，在数小时内都很难碰撞到一个文件。大家导入秒传又都是几百个文件一起导入，所以也不现实

当前唯一的方式，就是乖乖的使用阿里云盘分享功能

[pnqx]

现在的秒传相当于：阿里云盘问用户，你要上传的文件的某一部分的内容是什么？如果用户回答正确，就秒传成功。

我来说一下实现秒传共享的思路：

1. 分享者通过小白羊客户端上传要分享的文件，并勾选小白羊客户端的"加入秒传共享计划"，小白羊客户端将文件的sha1发送到第三方中介服务器，同时自身与中介服务器建立长连接（长连接的目的是便于实时双向通信，以及分享者的掉线检测）。
2. 分享的接收者通过小白羊客户端导入秒传链接，计算proof_code需要文件的哪8个字节，发送文件的sha1和偏移量offset到中介服务器。
3. 中介服务器通过sha1找到文件的分享者，请他读取offset的内容，读取完成后中介服务器把offset的内容返回给接收者。
4. 接收者现在有了sha1和offset的内容，可以自行生成proof_code再调用官方的秒传接口。

[liupan1890]

@pnqx 你这个方法都不如直接开115免费账号了

1.涉及到很多人的账号，属于用户隐私---我当然明白，涉及到的都是分享文件，但从程序设计角度，确实会涉及到用户的全部文件。所以这个方案并不可行的

2.涉及到网络，当前很多人的网络还都是大局域网，长连接什么的，加上需要用户上传数据占用用户的宽带（虽然小到可以忽悠略），用户也不会同意的

那么我说的开115是什么？是说在我的服务器上登录一个/几个115的账号

1.115网盘是不怎么限量的，比如我早年的一个账号是免费获得的200TB网盘空间---很早年了，早就不用了。但只是举例子。网上可以很方便的买到一堆免费的大容量的115账号

2.把文件存到115里，还可以支持用户导入115的分享链接，115的秒传链接。这些都把文件导入到115账号里

3.用户要秒传时，从115网盘的账号里查询是否有这个文件，有的话读取这个文件的8个字节，计算好code，返回给用户实现上传，因为读取的数量太少了，所以115账号不需要开通VIP获得高速下载功能，免费115账号即可

4.因为大家其实互相分享地文件好多都是重复的，1000TB的115网盘空间就非常够用了

因为115给的容量太多了，几个免费账号也就够用了。或者狠狠心花几千开一个115会员，一个账号就给 1150 TB网盘空间了。总之这样设计会比较可行。这个方案依赖我去注册115账号和我的服务器

有这个方案还可以引申一下，要求用户自己注册一个免费的115账号，然后在自己电脑上的小白羊里登录一下，登陆后就可以秒传导入115分享链接和导入115秒传链接到阿里云盘账号里。如果用户不想注册115账号，也只是不能导入115的文件，选择留给用户也行

[pnqx]

@liupan1890

1. 隐私方面，只有分享者主动标记的文件才会被分享。阿里官方的分享链接功能不也是主动分享的吗？
2. 网络方面，我不懂你说的”大局域网“是什么意思？是怕”大局域网“内的用户连不上中介服务器？

你说的”开115“方案也挺好，只是这个方案无法秒传只存在于阿里云盘内的文件。

[liupan1890]

对的，最多只能导入115，并且只是假想的思路

实际上，小白羊并不提供分享功能，小白羊里的分享，只是对官方分享链接的辅助，比如帮你记录一下你导入过的分享链接（方便以后重新导入），比如帮你通知其他人你创建了新的分享链接。但是所有的分享都是使用官方分享功能。

前期的秒传导入，秒传链接也不是小白羊创建的，而是大家使用115网盘插件创建的秒传链接或者115的分享链接。

阿里官方升级接口的目的是杜绝不受监管的分享。小白羊也不想去突破什么。

[JsonSong89]

@pnqx 的这个想法其实很不错.
不过作者的顾虑也能理解,不知道未来小白杨可不可以支持插件功能,可以把这个放在插件体系里面去做.

[CheatAbuser]

@pnqx 你这个方法都不如直接开115免费账号了

1.涉及到很多人的账号，属于用户隐私---我当然明白，涉及到的都是分享文件，但从程序设计角度，确实会涉及到用户的全部文件。所以这个方案并不可行的

2.涉及到网络，当前很多人的网络还都是大局域网，长连接什么的，加上需要用户上传数据占用用户的宽带（虽然小到可以忽悠略），用户也不会同意的

那么我说的开115是什么？是说在我的服务器上登录一个/几个115的账号

1.115网盘是不怎么限量的，比如我早年的一个账号是免费获得的200TB网盘空间---很早年了，早就不用了。但只是举例子。网上可以很方便的买到一堆免费的大容量的115账号

2.把文件存到115里，还可以支持用户导入115的分享链接，115的秒传链接。这些都把文件导入到115账号里

3.用户要秒传时，从115网盘的账号里查询是否有这个文件，有的话读取这个文件的8个字节，计算好code，返回给用户实现上传，因为读取的数量太少了，所以115账号不需要开通VIP获得高速下载功能，免费115账号即可

4.因为大家其实互相分享地文件好多都是重复的，1000TB的115网盘空间就非常够用了

因为115给的容量太多了，几个免费账号也就够用了。或者狠狠心花几千开一个115会员，一个账号就给 1150 TB网盘空间了。总之这样设计会比较可行。这个方案依赖我去注册115账号和我的服务器

有这个方案还可以引申一下，要求用户自己注册一个免费的115账号，然后在自己电脑上的小白羊里登录一下，登陆后就可以秒传导入115分享链接和导入115秒传链接到阿里云盘账号里。如果用户不想注册115账号，也只是不能导入115的文件，选择留给用户也行

115的免費賬號不能通過SHA1+size的方式秒傳大於5G的單文件，只有VIP才有這個特權。

[CheatAbuser]

对的，最多只能导入115，并且只是假想的思路

实际上，小白羊并不提供分享功能，小白羊里的分享，只是对官方分享链接的辅助，比如帮你记录一下你导入过的分享链接（方便以后重新导入），比如帮你通知其他人你创建了新的分享链接。但是所有的分享都是使用官方分享功能。

前期的秒传导入，秒传链接也不是小白羊创建的，而是大家使用115网盘插件创建的秒传链接或者115的分享链接。

阿里官方升级接口的目的是杜绝不受监管的分享。小白羊也不想去突破什么。

如果用戶要在阿里雲秒傳的文件在自己的115賬號裡已經有同樣的一份文件了，有沒有辦法登錄用戶自己的115賬號，從115的資源裡讀取阿里雲要求的proof code實現秒傳文件到阿里雲？115免費賬號下載限速，如果能把115的資源轉存到阿里雲就能不限速地下載。