Skip to content
This repository has been archived by the owner on Mar 18, 2023. It is now read-only.

已失效,强制升级 #25

Open
ifuweimin opened this issue Mar 6, 2023 · 9 comments
Open

已失效,强制升级 #25

ifuweimin opened this issue Mar 6, 2023 · 9 comments

Comments

@ifuweimin
Copy link

秒传已升级 /4.0/initupload.php,期待大佬~

@Mrs4s
Copy link

Mrs4s commented Mar 7, 2023

稍微看了下 这次4.0的上传接口已经改为和阿里云盘类似的方案了
具体流程如下

  1. 请求一次 initupload.php 并获取 sign_checksign_key.
  2. sign_check 包含两个参数 分别是 offsetlength.
  3. offset 为起始点读取 length 长度的数据计算 sha1 作为 sign_val
  4. sign_key + sign_valversion 作为参数传入 ec115 计算 token
  5. 拿到token后就是正常上传流程了

image

目前只能希望过了敏感时期重新开放 3.0 接口. 4.0 应该是不能通过一个链接简单秒传了

@ifuweimin
Copy link
Author

稍微看了下 这次4.0的上传接口已经改为和阿里云盘类似的方案了 具体流程如下

  1. 请求一次 initupload.php 并获取 sign_checksign_key.
  2. sign_check 包含两个参数 分别是 offsetlength.
  3. offset 为起始点读取 length 长度的数据计算 sha1 作为 sign_val
  4. sign_key + sign_valversion 作为参数传入 ec115 计算 token
  5. 拿到token后就是正常上传流程了

image

目前只能希望过了敏感时期重新开放 3.0 接口. 4.0 应该是不能通过一个链接简单秒传了

这是安卓app的反编译吗?是不是可以理解成每个人的sign_key不一样,115服务端会校验用户、时间等,无法生成固定的sha1链接了

@Mrs4s
Copy link

Mrs4s commented Mar 7, 2023

稍微看了下 这次4.0的上传接口已经改为和阿里云盘类似的方案了 具体流程如下

  1. 请求一次 initupload.php 并获取 sign_checksign_key.
  2. sign_check 包含两个参数 分别是 offsetlength.
  3. offset 为起始点读取 length 长度的数据计算 sha1 作为 sign_val
  4. sign_key + sign_valversion 作为参数传入 ec115 计算 token
  5. 拿到token后就是正常上传流程了

image
目前只能希望过了敏感时期重新开放 3.0 接口. 4.0 应该是不能通过一个链接简单秒传了

这是安卓app的反编译吗?是不是可以理解成每个人的sign_key不一样,115服务端会校验用户、时间等,无法生成固定的sha1链接了

header sha1 变成随机位置了

@362227
Copy link

362227 commented Mar 8, 2023

稍微看了下 这次4.0的上传接口已经改为和阿里云盘类似的方案了 具体流程如下

  1. 请求一次 initupload.php 并获取 sign_checksign_key.
  2. sign_check 包含两个参数 分别是 offsetlength.
  3. offset 为起始点读取 length 长度的数据计算 sha1 作为 sign_val
  4. sign_key + sign_valversion 作为参数传入 ec115 计算 token
  5. 拿到token后就是正常上传流程了

image
目前只能希望过了敏感时期重新开放 3.0 接口. 4.0 应该是不能通过一个链接简单秒传了

这是安卓app的反编译吗?是不是可以理解成每个人的sign_key不一样,115服务端会校验用户、时间等,无法生成固定的sha1链接了

header sha1 变成随机位置了

是不是那种一键sha1转存脚本,以后不可能有了?

@592767809
Copy link

8ddaea26701654896f14295977edb31

测试了一下,4.0需要先请求一次,然后随机计算一段文件的sha1(3.0的固定前128k)。然后再去请求。尝试进行重放攻击,失败了。目前来看好像无文件转存方式已经废了

@T3rry7f
Copy link
Owner

T3rry7f commented Mar 8, 2023

随机块校验的话那就无解了 ,不出意外一一五转存基本也宣告完结了。

user1121114685 referenced this issue in deadblue/elevengo Mar 8, 2023
@orzogc
Copy link

orzogc commented Mar 16, 2023

8ddaea26701654896f14295977edb31 测试了一下,4.0需要先请求一次,然后随机计算一段文件的sha1(3.0的固定前128k)。然后再去请求。尝试进行重放攻击,失败了。目前来看好像无文件转存方式已经废了

确定吗?怎么我看到的是只请求一次,只不过把preid去掉而已

@592767809
Copy link

8ddaea26701654896f14295977edb31 测试了一下,4.0需要先请求一次,然后随机计算一段文件的sha1(3.0的固定前128k)。然后再去请求。尝试进行重放攻击,失败了。目前来看好像无文件转存方式已经废了

确定吗?怎么我看到的是只请求一次,只不过把preid去掉而已

确定的,你尝试的可能是小文件,可以不需要计算随机sha1,大文件是一定会要的,至于这个界限我没有去测试具体是多少

@O-jiba-K
Copy link

确定足够小的文件不需要随机位置的sha1的话那这个小文件在4.0接口下具体需要怎样的秒传验证要求?如果小文件搞定了的话是不是可以通过大文件分割成小文件的方法曲线救国间接搞定4.0的秒传?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants