关于评论区地毯式炸链现象的一些测试及初步猜想 - cenglin123/SteganographierGUI GitHub Wiki

[技巧分享] 关于评论区地毯式炸链现象的一些测试及初步猜想 [资源防炸链解决方案倡议]

Author: 层林尽染

Link: https://cangku.moe/archives/211857

Updated: 2024-09-02 13:38:01

摘要：

本文对一个仓库投稿下方评论区分享链接地毯式炸链现象进行了初步研究，通过三轮控制变量的对照试验，采集了共24个样本。试验证实了百度网盘存在非程序正义审核的现象，强行判定加密文件违规。测试表明，隐写文件相比传统加密手段展现出了更强的抗审查优势，在人工复核环节有机会被放过。

文章还讨论了此投稿评论区可能存在不断举报分享链接的机器人账号，导致地毯式炸链。针对大体积资源分享，本文建议采用单元式分散分享方式，并通过模仿正常文件特征码分布来优化隐写文件的混淆效果，进一步降低隐写文件被判定为可疑的概率。经过改进，隐写文件的存活率甚至优于普通正常文件。

本文初步揭示了百度网盘审核机制的特点，为后秒传时代的资源分享提供了新的思路，对传火补档工作应该具有一定的指导意义。

隐写工具：https://cangku.moe/archives/211602


文章结构

fa9cea21947fd80d5219766b8bdd5553.webp


1. 背景：

如今，各大国内网盘审查政策日趋严格，分享链接炸链的可能性越来愈大。

传统来说，我们采用多层加密压缩包来应对审查问题。这样的做法无疑非常麻烦，并且当层数多、文件大时，频繁解压对于硬盘的损耗也难以忽视。

针对此问题，过去产生了多种利用网盘特性进行秒传的解决方案——即不走网盘的分享系统，而是以秒传链接的方式进行分享。

但是随着网盘政策的收紧，大部分秒传方案已经失效或名存实亡。

秒传方案失效以后，基于国内网盘的资源分享重新回到了多层加密压缩包的形式，分享者开始不可避免地要和网盘的分享及审核系统打交道，炸链又开始频频出现，有时候甚至地毯式的发生。

在这样的艰难情况下，本文介绍的文件隐写技术有望成为后秒传时代的安全分享新方案。


2. 地毯式炸链成因探讨

近来此投稿（以下简称投稿 A ）下方评论区内的传火链接地毯式地发生炸链，传火链接在发出后的存活时间一般不超过 2 个小时，尸横遍野无一幸存。这使得它成为了一个研究百度网盘审核机制的极佳对象。

根据笔者近来在此分享下与百度网盘方审核的一系列互动，初步证实了一个较为公认的说法：【百度网盘的审核对违规的判定存在非程序正义的现象】，并且隐写文件确实具有很好的抗审查优势。


2.1 网盘是如何审核压缩包的？

作为目前的共识，我们认为网盘对于压缩包的处理方式主要有 直接扫描法 和 在线解压追查法 两种。

对于没有加密的压缩包，网盘会直接扫描其中内容，假如发现了违规文件，就在黑名单中记录此压缩包的哈希值（哈希值之于文件可以类比为指纹之于人类），此后这个压缩包就无法再次分享、甚至无法下载了，并且由于记录的是文件哈希值，所以简单地改文件名或者后缀名是于事无补的，必须要改变文件的哈希值（比如重新打包上传）。

而对于有密码的压缩包，假如资源接收者有意或无意地在线解压了文件，那么解压出的内容会被扫描系统检查到，进而追查到压缩包本身，然后重复上述流程。

为了避免这样的问题，有经验的分享者会采用多层加密压缩包防止在线解压；同时压缩包也会使用目前百度网盘 PC 客户端无法在线解压的 .7z 格式（不过手机端可以在线解压 .7z ，特别强调一下），这样一来，可以尽量避免压缩包中内容被检测到，从而降低炸链的概率。


3. 试验方案设计

那么，在这样做的情况下评论区依然地毯式炸链，究竟是什么原因呢？没有根据的情况下不能妄下结论，我们做一下对照试验，来研究此问题。

为了准确且低成本地研究这个问题，我们需要设计一个数量较少但仍对照充分的试验方案。

加密方法方面，传统形式的压缩包方案已经被评论区大量案例证明不可行，于是此次试验略过压缩包方案，而采用以下 3 种方法：

1. MP4文件隐写+多层分卷加密压缩包

2. Cryptomator加密

3. Veracrypt加密（密码+密钥文件）


3.1 试验一：是否是因为内容被检测到了才炸链？


试验目的：考察“是否是因为内容被检测到了才炸链？”，本轮试验共有 10 个样本。


样本1~6：证明：地毯式炸链非加密手段之过

先列出采集到的 10 个样本中的前 6 个：

1. 外壳为 11 集 Relife 动画-分卷加密压缩包：https://pan.baidu.com/s/1Qa1Ak0YFOdzmYNfdWtNsIQ?pwd=6666

2. 外壳为电影《这个杀手不太冷》-单体压缩包：https://pan.baidu.com/s/1pwUqlT3L3DYTD1JqzWUvhw?pwd=6666

3. 外壳为长视频-分 2 卷加密压缩包：https://pan.baidu.com/s/1pwUqlT3L3DYTD1JqzWUvhw?pwd=6666

4. 外壳为 11 集葫芦娃动画-双层分卷加密压缩包：https://pan.baidu.com/s/1cT49rPDBdgfa5iwWxsMzIg?pwd=6666

5. Cryptomatot加密（未隐写）-双层分卷加密压缩包：https://pan.baidu.com/s/1_P4wOM3YQl-eFNo3m1Oatw?pwd=6666

6. Veracrypt加密卷，然后长视频隐写，上传并分享到评论区。https://pan.baidu.com/s/1K0U91889Ev52W-iG1rptuA?pwd=6666

先看下图中 1~6 样本的部分，图中绿色框表示此为隐写文件。

937d99c548657c4ef5107571c4022f52.webp


我们重点观察 6 号样本，其分享后很快失效，但是 6 号文件采用的是带有密钥文件的 VeraCrypt 加密之后再隐写的，其中密钥文件的 2 次转存是我自己用小号进行的，因此，网盘审核方是在没有取得密钥文件的情况下，判定文件违规的。

在没有获得密钥文件之前，是 绝无可能 在短时间内破解加密的。（VeraCrypt 的前身 TrueCrypt 曾创下 FBI 都无法解密的记录）

此外我们还可以观察到，所有隐写文件的失效，都不是【审核失败】，而是【正在审核】，这意味着后续仍可恢复访问。

因此，可以认为此投稿的评论区各大分享的炸链，并非加密手段本身的缺陷所致。


样本6~10：证明：网盘审核方的非程序正义行为

由于上面 1~6 号样本的炸链问题，我们开始怀疑网盘方的审核机制存在程序正义的问题，为了证实这一点，我们设计了 6~10 号样本，来检验一下我们的推测是否正确。

我们重点考察三个黄色箭头所指的 6 、7 、9 号样本。

6. 取有内容的Veracrypt加密卷，然后长视频隐写，上传并分享到评论区。https://pan.baidu.com/s/1K0U91889Ev52W-iG1rptuA?pwd=6666

7. 取葫芦娃为内容，分卷加密压缩，逐个隐写，上传并分享到评论区。https://pan.baidu.com/s/1lUjGqTKjb35pfB81le2eBQ?pwd=6666

8. 取有内容的Veracrypt加密卷，直接上传并分享到评论区。https://pan.baidu.com/s/19ZCEmeyuCkyHcARJfNPRLg?pwd=6666

9. 取一个空的Veracrypt加密卷，直接上传并分享到评论区。https://pan.baidu.com/s/1l9c_N4tff-QmfICGbTWLYA?pwd=6666

10. 取葫芦娃为内容，增大体积，直接上传不隐写（即完全正常的分享）。https://pan.baidu.com/s/13Qpmc97onwKF76hLOYHleA?pwd=6666

上述样本概括来说，就是既有含有内容的样本，也有不含内容的纯净样本；有隐写文件，也有直接上传的加密卷。

样本信息可以汇总如下表：


样本号 类型 内容 加密方式 隐写方式 上传至
6 VeraCrypt加密卷 有 带密钥加密 长视频单个隐写 投稿A评论区
7 隐写文件 葫芦娃 分卷压缩加密 分卷逐个隐写 投稿A评论区
8 VeraCrypt加密卷 有 带密钥加密 --- 投稿A评论区
9 VeraCrypt加密卷 无内容 带密钥加密 --- 投稿A评论区
10 普通MP4文件 --- --- --- 投稿A评论区


假如网盘方的审核机制是程序正义的，即能够能准确检测到违规内容，然后判定文件是否违规，那么上面的样本中存在内容的样本就会被检测出来，然后炸链，而没有内容的样本则会平安无事。

那么是否是因为内容被检测到了才炸链呢？

答案似乎是【否】


为什么？因为所测试的 6~10 号这 5 个样本全部都会炸链


具体来说，隐写文件提示“该文件禁止分享”，然后显示“正在审核”（稍后可自行恢复）；非隐写文件则直接审核失败，彻底锁定。


f5ba4cb48f19a09d5058f66e9198370b.webp


也就是说，这里不管内容实际上到底有没有问题，都会被网盘审核方强行判定为违规（以 10 号样本为典型，完全为葫芦娃视频，但是也违规了）。


小结：地毯式炸链另有原因

现在我们可以合理地质疑网盘方审核的程序正义性问题了。

而且，我们还可以观察到一个特征：每一个分享都有较高的查看数（不是我自己看的），而有较低（只有数个）的转存下载数。只要出现不是我自己进行的转存，随后必然伴随着炸链。

不过，仅仅是知道这些还不够，我们还需要深入探究这种现象的成因。

假如因为违规内容被检测到而炸链，当然合理；但是不仅违规内容没有检测到，连正常内容也炸链了。

这样的现象无疑很是奇怪的，因为大部分时候百度网盘都没有这般凶戾，很多投稿下面几近裸奔的传火链接也没有炸过，这样黑白不分地格杀勿论是很不正常的。

那么，有没有可能其实是笔者【被网盘方审核针对了】呢？因为被针对了，才频频炸链，得出的结论自然有失偏颇。

这大概也是不成立的，因为如上图所见，其他同一时间段的里番分享的查转下数量是远超过这些炸链的分享的，并且，接下来我的其他传火也没有炸链，假如被针对了，那么其他的内容也应该会炸链才对。

同时，文件的查转下虽然有一定数量，但也没有很多（比如上千），某些说法所认为的【因为分享次数过多】而炸链大概也是不成立的。

因此，这样全方位、无差别的地毯式炸链必然另有原因。


3.2 试验二：炸链是否是投稿 A 评论区的问题？


接下来我们进行第二轮对照试验。

试验目的：考察“炸链是否是投稿 A 评论区的问题？”

我们已经排除了加密技术手段层面因素对炸链的影响，我们再提出一个假设：导致炸链的有没有可能不是内容，而是评论区本身呢？

通过观察之前的样本我们可以发现，非隐写文件，不管是专有加密模式的 Cryptomator，乃至于 VeraCrypt（有密钥文件版），都很快审核失败，并彻底锁定。

这说明违规是被强行判定的，百度网盘对于无法解密的文件，假如它被大量举报，就会强行判定文件内容违规。

结合这些分享链接和转存下载量不成比例的查看量，难道说，投稿 A 的评论区存在机器人账号，它们不断地识别网盘链接，然后对其进行举报触发百度网盘的审核机制强行令其违规，所以才导致了地毯式炸链吗？


为了检验这个假设，我们把 4 号样本中的双层加密分卷 7z 压缩包修改哈希值，然后隐写重新上传，作为 11 号样本，然后再分享到另一个投稿 B 的评论区。

根据这样的思路，我们设计了修改哈希值后的 11~15 号样本，作为上面 6~10 号样本的对照组，汇总信息如下表：


样本 类型 内容 加密方式 隐写方式 上传至 体积 审核情况
11 隐写文件 有 分卷双层压缩加密 单文件隐写 投稿B评论区 6.5GB 正在审核
12 VeraCrypt加密卷 有 带密钥加密 --- 投稿B评论区 7GB 审核失败
13 VeraCrypt加密卷 无内容 带密钥加密 --- 投稿B评论区 7GB 审核失败
14 隐写文件 有 双层压缩加密 单文件隐写 投稿B评论区 6.5GB 正在审核
15 7z压缩包 有 双层压缩加密 --- 投稿B评论区 6.4GB 正在审核


这回发生审核失败的时间相比于投稿 A 延后了一些（大概3个小时），但就结果而言，换一个投稿评论区似乎并没有改善问题。


3.3 试验三：是否单次分享文件体积过大导致炸链？


试验目的：考察“是否是由于单次分享文件体积过大”导致炸链。

由 11~15 号样本，产生一个新的质疑方向：有没有可能是文件体积过大，所以才被重点审查呢？因为之前传火分享的内容大小基本在 3 个 GB 以下，是否由于文件过大，才导致了炸链呢？

为了验证这个猜测，我们设计了 16、17 号样本，把文件分卷压缩后隐写，然后分开用不同的链接进行分享。这里来需要额外说明的是，正在审核表示偶尔会出现“此文件禁止分享”，但是不会审核失败，稍后间断性地能够恢复分享功能，可以称之为“生死叠加态”。


样本 类型 内容 加密方式 隐写方式 上传至 体积 存活情况
16-a 隐写文件 有1/3 分卷双层压缩加密 单文件隐写 投稿A评论区 3GB 叠加态
16-b 隐写文件 有2/3 分卷双层压缩加密 单文件隐写 投稿A评论区 3GB 存活
16-c 隐写文件 有3/3 分卷双层压缩加密 单文件隐写 投稿A评论区 0.5GB 存活
17-a 隐写文件 有1/3 分卷双层压缩加密 单文件隐写 投稿B评论区 3GB 叠加态
17-b 隐写文件 有2/3 分卷双层压缩加密 单文件隐写 投稿B评论区 3GB 存活
17-c 隐写文件 有3/3 分卷双层压缩加密 单文件隐写 投稿B评论区 0.5GB 存活


根据试验三的结果，我们又发现一个特点：所有会进入生死叠加态的文件都是第一个文件，后面的文件都能持续存活。

于是我们有了新的推测：百度网盘的系统会扫描文件中的压缩包头部特征信息，锁定文件通知审核人员。但是由于隐写伪装，最后被审核人员当作误报重新放了出来。


样本 18~19：单元分散式分享法


按照这个思路，我们设计了 18~19 号样本，进行分卷压缩时，把第一卷和后面的卷分成不同单元进行分享，然后将第一卷进行多层压缩并隐写。

这样即使第一卷单元失效，补档也很方便。如果使用隐写文件，可以等待链接恢复正常后对第一卷进行换源，换源后分享即宣告正常。


样本 类型 内容 加密方式 隐写方式 上传至 体积 存活情况
18-a 隐写文件 有1/14 分卷双层压缩加密 单文件隐写 投稿A评论区 0.5GB 叠加态
18-b 隐写文件 有13/14 分卷双层压缩加密 逐个隐写分卷 投稿A评论区 6.0GB 存活
19-a 隐写文件 有1/15 分卷双层压缩加密 逐个隐写分卷 投稿A评论区 10MB 存活
19-b 隐写文件 有14/15 分卷双层压缩加密 逐个隐写分卷 投稿A评论区 6.4GB 存活


19 号样本使用 7z 的命令行压缩法，使得第一个文件大小只有 10 MB，这样即使进入生死叠加态也方便补档。

这样做也带来了一个出乎意料的的结果：19 号样本，全单元良性存活。

这是非常重大的阶段性成果，因为头一次，我们找到了让分享链接稳定存活的可能性。

这自然也就引出了下一个疑问：这是为什么呢？

2024-05-16 补充：原因见此


3.4 隐写文件的优势


在进一步研究这个问题之前，我们先把试验放一放，讨论一下隐写本身。

我们先看看隐写文件被冻结后自行恢复正常的样子，可以观察前后两张图中的 6 号样本。


失效时
f5ba4cb48f19a09d5058f66e9198370b.webp

恢复后
3e921f13471fc5e52359d931ef516b65.webp


隐写的优势在此体现得淋漓尽致，即使因为不明原因，导致被网盘审核机制非程序正义地强行判定违规，稍后的人工复查部分仍有可能被放过，存在恢复链接的可能性。假如是文件夹分享，还能显示具体是哪个文件被强行违规了。

此时可以在链接恢复正常后根据先前反馈的违规文件信息进行换源补档等操作，而无需取消分享。即使不换源，只要分享是文件夹，不要点开文件夹触发强制审核，那么分享可以正常转存。即使不慎点开了文件夹，触发了强制审核，提示“此文件禁止分享”的红字，只要稍等 5~10 分钟，链接即可恢复正常。

（补充说明：补档需要等待链接恢复正常再进行操作，否则由于内容前后不一致，导致被审核放弃，会一直处于正在审核的状态中，这样等同于炸链）


这再次证明了一个观点：


自然界最好的防御不是叠甲，而是伪装
乌龟再坚硬的外壳也抵御不了人类不讲道理的石砸斧劈
枯叶蝶和竹节虫在不动时却能屡屡躲过天敌的搜索
伪装的目的并不是让人挑不出毛病，而是让对方误判，从而求得一线生机


相比之下，即使如传统加密技术天花板的 VeraCrypt ，也会因为非程序正义审核失败而被彻底锁定，哪怕内容的确毫无问题，哪怕进行申诉，也无济于事。因为被锁定的文件其哈希值已经进入了网盘程序的黑名单，无法再次被分享，甚至没有机会再次进入人工审核流程。

可以说，目前没有比隐写更加能够抵抗审查的办法了。

传统的加密手段解决的是程序层面的问题，而隐写试图解决的是人层面的问题。


[collapse title="无问题的VeraCrypt文件审核且申诉失败"]

申诉失败（9号-无内容-纯VeraCrypt加密无隐写） 无法再次分享  
72f448680c8ab0bedb7a1a052d535c8f.webp 9672949ea8d0c0f36e39984dbddc49d1.webp

[/collapse]


3.5 如何改进隐写方法


到目前为止，我们的隐写方法只是简单地把 ZIP 压缩包附在 MP4 外壳之后，从前面的几个样本的情况来看，百度网盘是可以扫描并检测出这样的文件的，但是这种情况对于网盘而言可能仅算可疑，而不能直接判违规。

因为压缩文件的特征码并不复杂，在文件比较大的时候，可能某部分会“凑巧”匹配到相应的特征码，假如网盘一检测到特征码就立刻判违规，那么会有大把的正常文件被违规，这就成事故了。

所以，推测网盘遇到这样的情况时，会把可疑文件先冻结，然后通知人工审核复查，此时文件的生杀就交到这位接手的人工审核身上了。

我们之前提过，当人工审核无法解密文件时，会倾向于直接判定内容违规，即使如 VeraCrypt 也只能秀才遇到兵有理说不清，因为对方根本不和你理论。

而隐写文件则不同，人工审核一眼能看到正常可播放的 MP4 文件，这样直接判违规的概率就小了很多。这可能就是为什么，样本中被冻结的隐写文件基本没有审核失败的，都显示正在审核，然后大部分过一会就能解冻。

但是这依然不是最终的解决办法，因为查转下和举报的次数一增加，此文件又会被系统冻结，然后重复上述流程，一直在生与死之间仰卧起坐。


换位思考：如何判定隐写文件


MP4 文件隐写用来应对人层面的问题已经足够了，接下来就需要从对程序层面入手了。即最好不要让系统判定文件可疑，这样和网盘方审核互相不折腾你好我好大家好。

那么具体该怎么办呢？干想很难有进展，我们不如换位思考一下，从网盘方的角度来处理一个可疑文件，看看有没有思路。

首先，要判定一个文件是压缩包，那么就需要检测它的特征码，目前好像没有针对压缩包的现成工具（20240521打脸，其实是有的：binwalk），那么我们自己整一个简易脚本。

[collapse title="压缩包特征码检测脚本"]

[code lang="Python"]

# -*- coding: utf-8 -*-
"""
Created on Thu May  9 18:35:59 2024

@author: 12601
"""


#%% 压缩包特征码检测


定义已知压缩包特征码


head_signatures = {
"RAR4": b'\x52\x61\x72\x21\x1A\x07\x00',
"RAR5": b'\x52\x61\x72\x21\x1A\x07\x01\x00',
"ZIP": b'\x50\x4B\x03\x04',
"7Z": b'\x37\x7A\xBC\xAF\x27\x1C',
"GZIP": b'\x1F\x8B',
"BZIP2": b'\x42\x5A\x68',
"XZ": b'\xFD\x37\x7A\x58\x5A\x00',
}


扫描文件中的压缩包特征码


def find_head_signature(filepath):
results = []
with open(filepath, 'rb') as file:
content = file.read()
for format_name, signature in head_signatures.items():
position = content.find(signature)
if position != -1:
results.append((format_name, position))
return sorted(results, key=lambda x: x[1])


将字节位置转换为 MB


def bytes_to_mb(byte_position):
return byte_position / (1024 * 1024)


获取文件大小并转换为 MB


def get_file_size_mb(filepath):
import os
file_size_bytes = os.path.getsize(filepath)
return bytes_to_mb(file_size_bytes)


推断最可能的格式


def determine_most_likely_format(head_signatures_detected):
head_formats = [fmt for fmt, _ in head_signatures_detected]
common_formats = head_formats
if common_formats:
return common_formats[0]
return None


while 1:
print('=====================')
file = input('请输入要检测的文件>>>\n').strip('"').strip("'")
head_signatures_detected = find_head_signature(file)
total_size_mb = get_file_size_mb(file)


most_likely_format = determine_most_likely_format(head_signatures_detected)

if most_likely_format:
    print(f"此文件最可能的格式为: {most_likely_format}")
else:
    print(f"未能匹配到已知的压缩包格式. 文件总大小为 {total_size_mb:.2f} MB.")

# 显示检测到的头部特征码
if head_signatures_detected:
    primary_signature = head_signatures_detected[0]
    print(f"匹配到 {primary_signature[0]} 格式的头部特征码, 位置: {bytes_to_mb(primary_signature[1]):.6f} MB / {total_size_mb:.2f} MB (Head)")
    if len(head_signatures_detected) > 1:
        print("此外还匹配到以下可能的特征码 (Head):")
        for format_name, position in head_signatures_detected[1:]:
            position_mb = bytes_to_mb(position)
            print(f" - {format_name} 格式, 位置: {position_mb:.6f} MB / {total_size_mb:.2f} MB (Head)")</pre><p>[/code]</p><p>[/collapse]</p><p>这个脚本能够遍历整个文件，然后匹配各种常见压缩文件的特征码。我们拿各类去掉后缀的压缩包来试一试</p><p>[collapse title="压缩包特征码检测结果" show="true" ]</p><p>[code lang="Python"]</p><pre>=====================



请输入要检测的文件>>>
D:\ANE_TEMP\comic\异界之美少女大召唤(zip)
此文件最可能的格式为: ZIP
匹配到 ZIP 格式的头部特征, 位置: 0.000000 MB / 3.54 MB (Head)
此外还匹配到以下可能的特征 (Head):
  • GZIP 格式, 位置: 0.014082 MB / 3.54 MB (Head) ===================== 请输入要检测的文件>>> D:\ANE_TEMP\comic\异界之美少女大召唤(7z) 此文件最可能的格式为: 7Z 匹配到 7Z 格式的头部特征, 位置: 0.000000 MB / 2.76 MB (Head) 此外还匹配到以下可能的特征 (Head):
  • GZIP 格式, 位置: 0.055288 MB / 2.76 MB (Head) ===================== 请输入要检测的文件>>> D:\ANE_TEMP\comic\异界之美少女大召唤(rar) 此文件最可能的格式为: RAR5 匹配到 RAR5 格式的头部特征, 位置: 0.000000 MB / 3.03 MB (Head) 此外还匹配到以下可能的特征 (Head):
  • GZIP 格式, 位置: 0.193130 MB / 3.03 MB (Head) =====================

    [/code]

    [/collapse]

    全部都能准确检测到头部特征码。（所以大家要记住简单的改后缀是没用的）

    接下来，我们使用这个脚本来检测隐写文件，果然，在外壳视频和压缩包交界的地方(10 MB左右)检测到了 ZIP 的头部特征码，看来这就是造成隐写文件可疑的原因了。

    [collapse title="隐写文件的检测结果" show="true"]

    =====================
请输入要检测的文件>>>
D:\ANE_TEMP\comic\output.mp4
此文件最可能的格式为: GZIP
匹配到 GZIP 格式的头部特征, 位置: 0.045341 MB / 13.90 MB (Head)
此外还匹配到以下可能的特征 (Head):
  • ZIP 格式, 位置: 10.365262 MB / 13.90 MB (Head) =====================

    [/collapse]

    那么要怎么解决呢？干想很难有进展，我们还是换位思考一下，假如你是网盘审核系统的设计者，你应该如何区分正常文件和可疑文件？肯定要找到二者的不同，所以我们先拿正常的 MP4 文件去过一下我们自制的简易检测器。


    [collapse title="正常的MP4文件检测结果" show="false"]

    =====================
请输入要检测的文件>>>
D:\TEMP\隐写者测试\cover_video\葫芦娃\葫芦兄弟01.1986.mp4
此文件最可能的格式为: GZIP
匹配到 GZIP 格式的头部特征, 位置: 0.089262 MB / 47.92 MB (Head)
此外还匹配到以下可能的特征 (Head):
  • BZIP2 格式, 位置: 7.478891 MB / 47.92 MB (Head) ===================== 请输入要检测的文件>>> D:\TEMP\隐写者测试\cover_video\葫芦娃\葫芦兄弟02.1986.mp4 此文件最可能的格式为: GZIP 匹配到 GZIP 格式的头部特征, 位置: 0.055298 MB / 49.26 MB (Head) 此外还匹配到以下可能的特征 (Head):
  • BZIP2 格式, 位置: 9.982191 MB / 49.26 MB (Head) ===================== 请输入要检测的文件>>> D:\TEMP\隐写者测试\cover_video\葫芦娃\葫芦兄弟04.1986.mp4 此文件最可能的格式为: GZIP 匹配到 GZIP 格式的头部特征, 位置: 0.005783 MB / 48.79 MB (Head) 此外还匹配到以下可能的特征 (Head):
  • BZIP2 格式, 位置: 38.151652 MB / 48.79 MB (Head) ===================== 请输入要检测的文件>>> "D:\TEMP\隐写者测试\cover_video\1-5min\【池沼影院】被人类欺骗的哥布林 [BV1Xm421E7pc].mp4" 此文件最可能的格式为: GZIP 匹配到 GZIP 格式的头部特征, 位置: 0.099542 MB / 2.87 MB (Head) ===================== 请输入要检测的文件>>> "D:\TEMP\隐写者测试\cover_video\1-5min\【芙莉莲】再一次建立了一个新老滚存档的芙莉莲【上古卷轴5】 [BV1Am42147vV].mp4" 此文件最可能的格式为: GZIP 匹配到 GZIP 格式的头部特征, 位置: 0.155127 MB / 3.67 MB (Head) ===================== 请输入要检测的文件>>> "D:\TEMP\隐写者测试\cover_video\5-10min\【多多のVLOG】好久不见的线下漫展！ [BV14f421U7W3].mp4" 此文件最可能的格式为: GZIP 匹配到 GZIP 格式的头部特征, 位置: 0.350672 MB / 22.85 MB (Head) 此外还匹配到以下可能的特征 (Head):
  • BZIP2 格式, 位置: 6.175072 MB / 22.85 MB (Head)

    [/collapse]


    可以看到，正常 MP4 文件的假如碰巧匹配到了特征码，其位置应该是混乱无规律的，各种情况都有。而隐写文件则总是在视频与 ZIP 文件交界的地方匹配到。

    因此，也就产生了解决的思路：只需要尽量模仿正常 MP4 文件，让隐写文件也拥有结构混乱的特征码，并且在进行批量隐写时，也尽量使用长短大小不一的视频就可以了。

    具体来说，在文件末尾增加的随机字节中，在随机位置插入 2 条随机种类的压缩文件特征码，量要卡在解压软件能读取的极限大小。

    我们使用 20 、21 、22 号样本来检验我们的方法。此外还新增 23、24 两个普通 MP4 文件作为对照。


    样本 类型 内容 加密方式 隐写方式 上传至 体积 存活情况
    20 隐写文件 有15/15 分卷双层压缩加密 逐个隐写分卷 投稿A评论区 6.5GB 存活
    21 隐写文件 有11/11 单层压缩加密 分文件单独隐写 投稿A评论区 6.9GB 存活
    22 隐写文件 有7/7 分卷双层压缩加密 大外壳逐个隐写分卷 投稿A评论区 7.4GB 存活
    23 普通MP4文件 --- --- --- 投稿A评论区 627MB 叠加态
    24 普通MP4文件 --- --- --- 投稿B评论区 627MB 叠加态


    目前看来还是有效的，相比之下，23、24 号样本普通葫芦娃却反而更先进入了生死叠加态，看起来这样处理后的隐写文件比正常 MP4 文件的可疑度还要更低。


    4. 结论


    通过本文对百度网盘审核机制的一系列试验，我们可以得出以下结论:

    (1) 百度网盘的审核机制存在非程序正义的现象。在没有获得密钥的情况下，网盘方会强行判定加密文件内容违规。

    (2) 此投稿的评论区各大分享的地毯式炸链，并非加密手段本身的缺陷所致，而是有其他原因。评论区可能存在不断举报分享链接的机器人账号，触发了网盘的强制审核。

    (3) 隐写文件展现出了很强的抗审查优势。即使被非程序正义地判定违规，隐写文件也有机会在人工复核时被放过，恢复分享。相比之下，传统加密手段无法应对人为不讲理的审核。

    (4) 通过模仿正常文件的特征码分布，优化隐写文件的混淆效果，可以进一步降低隐写文件被判定为可疑的概率。目前看来，处理得当的隐写文件比普通文件更不容易引起网盘的怀疑。

    (5) 对于较大体积资源的分享，采用单元式分散分享的方式可以最大程度降低炸链的影响。即使个别分享单元失效也很容易补档恢复。

    综上所述，本文通过一系列试验初步揭示了百度网盘审核机制的特点，证明了隐写文件优秀的抗审查能力，并就如何进一步改进隐写方法、应对审查制度提出了一些建议，为后秒传时代的资源分享提供了新的思路。

    以上内容已经在最新版本的程序中更新。


    附录


    A. 奇特的保存者

    为什么文中怀疑评论区存在机器人呢，因为根据对分享炸链规律的长期观察，分享进入审核状态有一个特点：每次只要某个特定的人保存了文件，链接就立刻会进入审核。这个人很独特，因为我用 2 个小号来保存文件甚至举报文件，都不会使得链接立刻进入正在审核的状态。而这个人不同，只要他一保存，链接立即就进入生死叠加态。不管这个链接到底含没含有资源，哪怕仅是纯粹的葫芦娃，链接也会立刻进入审核状态。

    情况记录1

    b055f986d22362ab29e3c8081c05f2a1.webp

    情况记录2

    0b5f12af2745a2e82000fe0f2e951d34.webp

    情况记录3

    35749530d1a4382a6a990a7ad98e7fc7.webp


    隐写技术相关系列文章（时间顺序）

    [1] [技巧] 用文件隐写来规避网盘和谐

    [2] [工具分享] 隐写者：把资源嵌入MP4文件的隐写工具 [资源防炸链解决方案倡议&规避网盘审查技巧探讨]

    [3] [技巧分享] 隐写分享压力测试阶段性报告 [资源防炸链解决方案倡议]

    [4] [技巧分享] 后秒传时代如何避免资源分享炸链？ [资源防炸链解决方案倡议]

    [5] [技巧分享] 关于评论区地毯式炸链现象的一些测试及初步猜想 [资源防炸链解决方案倡议]

    [6] [技巧分享] 关于此评论区地毯式炸链的真实原因及补档相关说明 [资源防止炸链解决方案倡议]

    [7] [技巧分享] 后秒传时代的安全分享路在何方？ [资源分享传火呼吁&隐写文件用法释疑]

    [8] [技巧分享] 网盘资源分享的几种安全级别、倒卖者举报的原理，及分享建议 [资源防炸链解决方案倡议]

    源代码：

    https://github.com/cenglin123/SteganographierGUI


⚠️ **GitHub.com Fallback** ⚠️