
界面样式
功能简介
这个工具目前只做一件事情,就是对输入文件的每一 bit 都进行位反转操作,然后再把反转完的文件下载回你的电脑里,其速度取决于电脑性能。
被处理过的文件没有办法直接打开,需要用这个工具再进行一次位反转操作才能恢复正常。
我的主要目标是提供一种更容易操作的防爆方法。如果没有对安全性的额外要求的话,理论上可以直接打一个不加密的 zip 包,然后使用这个工具把 zip 包处理一遍再分享出去,分享出去的 zip 包几乎不可能直接在网盘内解压,也几乎不可能被其他压缩软件直接打开(毕竟网盘和压缩软件不知道这个文件是位反转过的)。
使用方法
内容分享者的使用步骤:
- 你作为内容上传者已经将资源打包完成,比如说压缩包的名字叫“A.zip”
- 打开工具网址
- 选择“Compress & Encrypt/压缩并加密”模式
- 点击文件输入框,找到并选择“A.zip”
- 点击“Execute/执行”
- 正常情况下,浏览器会开始下载文件,文件名会有一个前缀“enc_”表示这个文件是经过一次加密的,等待文件下载完成后分享这个文件即可
- 在分享文件时附带工具地址
内容下载者的使用步骤:
- 下载被处理过的文件,比如说就是上文中的“A.zip”
- 打开分享者提供的工具网址
- 选择“Decrypt/解密”模式
- 点击文件输入框,找到并选择“A.zip”
- 点击“Execute/执行”
- 正常情况下,浏览器会开始下载文件,文件名会有一个前缀“dec_”表示这个文件是经过一次解密的,可以用通常的方法打开
为什么需要访问一个网站
我研究了一阵子,最后没有找到能够完全离线处理大文件的方法,只能退而求其次使用 Service Worker ,这个 Service Worker 能够模拟服务端向客户端发送文件。
这个工具目前只是 StreamSaver.js 的一个简单封装,使用 stream 去读写文件,这样处理大文件的话应该不会爆内存。
性能与内存占用情况
我的 CPU 是 i9-10900K ,处理速度在 20MB/s~30MB/s 之间浮动:

处理速度
我使用的浏览器是 Edge 129.0.2792.79 ,加解密 2 GB 的文件内存占用在 1.3GB 左右(不过我开了几十个 tab ,由这个工具实际占用的内存应该比较少):

文件大小 2.2GB ,快处理完成时的内存占用情况
如何部署一个自己的版本
这个工具一共由 5 个文件构成:
- https://volatile.saya.pw/index.html
- https://volatile.saya.pw/StreamSaver.min.js
- https://volatile.saya.pw/ponyfill.min.js
- https://volatile.saya.pw/mitm.html
- https://volatile.saya.pw/sw.js
若要自己部署,你需要找一个能够帮你 host 静态文件的服务提供商,比如说 github page 或者 gitee page 。我的自己使用的方法是境外服务器 + cloudflare 。
然后把这 5 个文件下载下来,放进你自己的服务器里就行了。
其中 index.html 文件内有具体的业务逻辑,没有做任何压缩或混淆,你可以随意修改,制作一个属于你自己的加解密工具,只要记得在分享文件时带上你自己的工具链接就行。
下一步计划
接下来,我会尝试让使用者能够以一种简单的方式去定义处理数据的过程。目前的加解密过程是写死的,就是简单的位反转,但这样的话实际上只是又创建了一个固定的私有文件格式而已,我希望加密的过程是可以由用户自己定义的。
此外,我希望在这套工具内集成一个压缩软件(可能会使用 wsam 去实现),内容分享者可以直接把文件夹拖拽进页面,然后页面会直接进行压缩和加密操作(这也是为什么第一个模式的名字叫“压缩并加密”,而不是仅仅叫“加密”)。
最后,工具的可用性也有待提高,比如说如果能直接拖拽文件,而不是必须通过点击文件输入框选择文件的话,易用性应该会更高。
感觉不如直接用C++或Rust直接写一个简单的程序,你这性能也太差了
以上评论亮了
感觉不如直接用C++或Rust直接写一个简单的程序,你这性能也太差了
@Mart 随手写了个同样功能的玩具,感兴趣的可以试试
https://pan.baidu.com/s/1coIsO7xSNDOspMK07T1cng?pwd=mart
@Mart 嗯,现在性能确实不行,只是堪堪能用的地步,我这么做主要图的是易用性,我之后打算用 wsam
好想法,走浏览器处理感觉还是得早日上wasm,还有就是用户自定义加密过程,拿出一个可逆的加密过程其实自由度没有那么高,假设要密钥加密那还不如直接设置解压密码
@Besthope 谢谢,我确实打算后面用 wasm ,我想表达的“加密”可能和解压密码那种不太一样,我的想法是通过一种可逆的转换把文件变成一种私有格式,这种转换要比较容易让用户去自定义,然后其他软件都没法正常打开转换后的文件,而不是做到那种真正的加密
这要是改每4位才反转一次,速度岂不是直接翻4倍
出院!
emmmmm,我来说说的的看法,首先我们的目标不是加密,而是防止资源被爆破,所以说我们得站在百度网盘这个监管者的视角来看,接下来是我的猜测,首先百度网盘判断文件是否违规的情况:
第一为判断文件哈希值,如果哈希值和违规资源数据库里的哈希值匹配上来的话,直接干掉。
第而为文件类型,例如MP4,JPG,PNG等等这种常见的媒体格式,直接使用ai或者其他识别方式识别其内容,然后判断是否违规。然后是压缩包和应用程序,例如apk,rar,exe,zip类,首先zip和rar这种压缩包格式,尝试识别其内容或者内容的crc32的值来和已有的违规资源数据库进行判断,如果压缩包内有这种违规资源就直接干掉,如果压缩包加密,并开启了名称加密,则根据举报量来判断是否违规。如果是apk这种文件的话则会先根据这个app的包名来判断是不是违规资源,其次是根据举报量,exe的话则直接根据举报量,百度网盘判断一个文件是否为某种文件的方法是根据文件的特征,这个特征判断一般来比较呆,例如你将一个rar文件的文件名,后缀,以及文件开头添加几个字节,百度网盘就识别不出来了,简单来说就是你上传上去后无论如何都无法进行在线解压操作,只有下载之后才行,如果你隐藏了这个文件的特征后,百度网盘无法识别这到底是个什么文件,就只能根据举报量来判断了,而如果你将一个压缩包伪装成一个视频或者一张图片之后(是伪装,而不是改个后缀什么的),百度网盘则会使用对图片或者视频的判断方法,这样才是最安全的,因为百度网盘大概只会判断这个表层的视频或者图片是否违规,无法识别这文件内部藏着的文件,就成功绕过了。不过这些都是我个人的猜测,实际还是实验为准吧
@狩野桐花(cancan2333) 其实我觉得,那种伪装成图片、视频或者音频的方式,对人来说迷惑性确实很强,但是对机器来说,机器可以拿已知的文件格式一个一个去套,最后会发现 rar + #模式 刚好能正确处理这个压缩包,然后压缩包里有 3 个文件,这种伪装有可能骗不过自动检查,不过我也不知道百度网盘究竟做到了什么地步
@LittleSaya 实际上应该是可以绕过的,因为你将文件伪装后无法使用百度网盘的在线解压功能,他无法正常识别
@狩野桐花(cancan2333) 修改文件头的办法存在兼容性问题,例如大佬你用的rar文件(在头部添加了1到10的无用byte)和一部分加上了视频伪装的zip文件,虽然不知道为什么bandizip都能识别,但终究会出现一些问题,例如bandizip读取大佬的分卷rar文件会提示文件损坏,以及这两种文件都无法被7z正常读取
虽然这种方式的确是增加了检测所需要的成本,不过也可能会顺带迷惑资源的下载者
虽说如此我也不觉得像这样对整个文件使用另一种方式做整体混淆或加密是一个很好推广的办法(需要足够简单、通用、有效、高效、易于推广),只能多加实验和探索 