[原创] 后AI时代的验证码-AI 助力安全-看雪安全社区

# 后AI时代的验证码

DEMO <mark class="encrypted">ec1K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5H3y4#2)9J5k6e0p5%4y4q4)9J5k6e0p5^5x3#2)9J5k6e0p5&6x3q4)9K6b7e0R3H3z5o6q4Q4x3V1j5`.</mark> （不保证长期可用性，估计过两个月会关）
源代码见附件

## 0x00 Background

后AI时代，传统的混淆与机器视觉已经不再是可靠的人机验证方法。

随着 agent 系统的铺开，基于代码混淆的安全性正在变得日益脆弱。Security through obscurity 本身就不是真正的 security——这一点社区早有共识，但它过去之所以能"凑合用"，是因为逆向分析需要人类专家的时间。VM 保护、花指令、控制流平坦化，本质上都是在抬升分析的人力代价：只要破解所需的人月超过目标的价值，方案在实践上就是"安全"的。但这个前提正在崩塌。Anthropic 在<a href="elink@294K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2S2L8Y4c8Z5M7X3!0H3K9h3y4Q4x3X3g2U0L8$3#2Q4x3V1k6J5k6i4y4W2j5i4u0U0K9q4)9J5c8X3N6D9L8g2)9J5k6o6g2Q4x3X3b7K6i4K6u0V1j5h3&6V1i4K6u0V1N6r3S2W2i4K6u0V1M7%4m8J5k6h3q4V1i4K6u0V1L8$3k6Q4x3X3c8S2k6s2k6S2L8X3y4W2k6q4)9J5k6r3y4&6j5X3g2J5i4K6u0V1j5$3q4H3j5h3u0A6L8r3W2@1K9h3g2K6">《GLM-5.3 and the Spread of Advanced Cyber Capabilities》</a>中披露：

> First, we ran the model on ExploitBench, which measures how well AI models can exploit known vulnerabilities in the V8 engine used by Google Chrome. Here we focus on the models' ability to develop end-to-end exploits successfully, as this is the most relevant capability for attackers, and where we see significant changes between models. We find that GLM-5.3 develops end-to-end exploits in 50 of 410 attempts. Claude Mythos Preview did so at a similar rate—in 56 of 410 attempts.

换言之，哪怕是 GLM 这样的开源模型，也已经可以端到端地完成漏洞分析与利用开发。VM 等方案在此前或许能够通过抬升分析代价，使得破解对于某个体量的个人或实体在实践上不可行；但归根结底，这只是 obscurity 的一种。随着所谓 "advanced cyber capabilities" 的扩散，能够 7×24 不间断工作的智能体集群已经事实上可用，分析代价从"人月"变成了"GPU 小时"——而 GPU 小时是可以横向扩缩容的。事实上，许多头部大厂的方案也已经被攻破了：[验证码识别之"点击运动最慢的元素"分析](https://bbs.kanxue.com/thread-292908.htm)、[验证码识别之"旋转最快的物体"](https://bbs.kanxue.com/thread-292909.htm)、[滑块验证码逆向分析与协议还原实践](https://bbs.kanxue.com/thread-292336.htm)、[Tbooking验证码逆向分析](https://bbs.kanxue.com/thread-291472.htm)等帖，记录的都是这类防线在智能体面前的实际溃退。

而另一方面，基于视觉谜题的 captcha 在 VLM 的冲击下早已不堪一击。无论是文本识别、目标检测还是图像分割，本身就是现代化 VLM 研究的主旋律——你精心设计的新题型，恰恰是模型厂商求之不得的高质量数据分布。一个好的 scheme 非常容易被 VLM 的 vendor 出于纯粹的数据合成目的而吸收，失效于无形；computer-use 类智能体叠加模型厂商对交互数据的收集，更使得所有"有真实用户"的系统都在为攻击方免费产标注。所谓"我消灭你，与你无关"。

AI 系统本身带来的安全事件也是真实存在的，而非理论推演：[OpenSecurity 2.0 无人值守完成 CTF 所有 Web 挑战](https://bbs.kanxue.com/thread-293120.htm)，以及 <a href="elink@9aeK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8$3c8W2L8%4S2A6i4K6u0W2j5$3!0E0i4K6u0r3j5X3I4G2k6#2)9J5c8X3N6H3N6q4)9J5k6o6g2Q4x3X3b7$3i4K6u0V1M7$3!0D9i4K6u0V1K9s2g2Y4k6$3W2F1k6#2)9J5k6r3k6S2j5$3g2Q4x3X3c8T1M7X3g2S2j5$3R3`.">GPT-5.6 Sol Hugging Face Breach</a>，都在提示同一个事实——攻击侧的能力基线已经被整体抬高了。

因此，在后AI时代，我们急需一种这样的验证码：它的谜题本身要难以求解，不能是 VLM 常见任务（OCR、segmentation、classification）的平凡实例，否则等于给厂商送合成数据；它不能过度依赖客户端代码的保密性——客户端代码一定会被读、被喂给 agent、被完整还原，这一点应当作为设计前提而非需要防御的意外，反而可以适当地依赖服务端代码与权重的保密性；它还应当让欺骗的经济学不成立，攻击者付出的计算代价不能显著低于防御方的验证代价。

## 0x01 设计目标：公平性与可验证性

在具体展开方案之前，有必要先把"验证码到底要干什么"这件事想清楚。我们认为，一个合格的验证码必须同时满足两点，而后AI时代的种种失败案例，恰好可以归入对这两点的背离。

第一点是公平性：不能让客户端不公平地消耗服务端的资源。学界有不少设计看上去非常美好，但代价模型是失衡的。比如 <a href="elink@3a9K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6G2M7r3g2F1M7X3g2$3K9h3g2%4i4K6u0W2L8X3g2@1i4K6u0r3k6X3!0J5N6h3#2Q4x3@1k6A6k6q4)9K6c8o6S2x3b7h3x3#2K9%4A6B7K9s2Z5`.">Spatial CAPTCHA</a>（ICLR 2026），其服务端验证本身需要类 RAG 的检索加重渲染的行为；又比如 <a href="elink@c27K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6k6h3g2W2P5s2m8D9L8%4u0W2i4K6u0W2K9h3g2W2k6g2)9J5k6h3!0J5k6#2)9J5c8X3c8G2j5%4g2E0k6h3&6@1i4K6u0r3z5e0t1#2y4K6p5%4x3R3`.`.">Capture the Bot</a>（IEEE Intelligent Systems 2021），验证一次竟然需要在模型上做多次反向传播来生成对抗样本。这类方案把绝大多数计算压在了防御方一侧，攻击者只需以近乎为零的成本发起请求，就能让服务端燃烧昂贵的算力——这在经济学上是不可持续的，甚至本身就构成了一个 DoS 面...你看，我们设计一个验证码，本来就是为了保护ai模型试用之类的业务对不对？结果为了生成一个验证码，就把一个模型反反复复的跑多次...这种方法至少在我看来是存在问题的。我们期望的应该是：验证码的服务端耗时与客户端耗时之间最多相差常数级别。本方案的检查点取在 2 的幂次处，原因正在于此——按时间轴指数稀疏地布置检查点，恰好让"伪造检查点所需的真实计算"与"服务端复算"之间只差一个至多为 2 的常数因子；指数间隔保证了对数级的额外通信与校验开销，而 2 本身是一个常数。同时还要注意，公平性不能靠"禁止刷新"来维持：客户端永远有权要求换一个题目，所以每一次领题、每一次提交都必须各自携带自己的代价证明，而不能依赖对会话行为的限制。

第二点是可验证性：验证码一定要能真的验证。与学界形成鲜明对比的是，业界的很多 scheme 正如引言中所说，puzzle 真的就只是纯 puzzle——某些不点名的厂商的滑块，随便猜都有百分之十的 ASR，这种方案肯定是有问题的。而如果你选择做轨迹识别，那么轨迹就一定要难以伪造：不能说随便一个 FGSM 加 ensemble 就过了，对不对？要挡住这类攻击，轨迹就必须带有时间上的前后依赖，让每一个采样点都背负整个历史状态的约束，使"逐点微扰"式的对抗修改无处着力。当然，你也可以彻底不做状态——但那样的话，你的 puzzle 本身的难度构建无论如何都要撑起来，否则就退回到了纯 puzzle 的老路上。

为了解决这种种问题，我们的方案把两点要求同时落到了一个物理小游戏上：玩家拖动一根软绳的绳头，靠惯性把绳末端的小球甩进一个变速运动的目标区域并驻留数秒。绳链是混沌动力学，每个采样点都深度依赖此前全部输入历史——这直接给出了轨迹的时间前后依赖，使伪造与对抗微扰必须在整个闭环控制系统内求解；而游戏的通关过程本身就是一段必须真实发生的连续仿真，服务端以常数倍的代价即可确定性复算并抽查其过程证据——这给出了公平性。谜题不是 VLM 的平凡任务，引擎完全公开、判别器整体藏于服务端，混淆被有意放弃，取而代之的是可验证的计算与统计意义上的人类性。下面就从谜题、AI 与算法三个层面分别展开。

![图片描述](upload/attach/202610/994475_3UM22Q64K24UEV4.webp)

## 0x02 谜题设计：连续控制，而非视觉识别

游戏画面很简单：一根由若干节构成的软绳从顶部垂下，玩家按住并拖动绳头，靠惯性把绳末端的小球"甩"进目标区域。屏幕下方有三个沿李萨如曲线变速运动的靶形，形状与颜色均随机且不重复，其中一个是随机指定的目标。小球需要在目标内累计停留约 3.5 秒才算通关，中途脱离目标还会缓慢倒扣进度，单次尝试设有时间上限。

![图片描述](upload/attach/202610/994475_2MSZ75GKWYYE4S3.webp)

这个谜题有几个精心挑选的性质。其一，它不是任何标准 VLM 任务的实例——不是识别、不是分割、不是关键点检测，而是一个强化学习意义上的连续控制问题。屏幕上的语义信息（哪个形状是目标）对 VLM 来说一目了然，但"看清楚"并不等于"做得到"：要让一条带重力、带速度上限、带约束迭代的物理软链的末端，精确追上一个变速运动的目标并保持驻留，需要的是数十秒的闭环控制，而不是一帧截图的推理。其二，绳链是混沌动力学，演化对输入高度敏感，攻击者无法预先离线规划一段开环轨迹然后回放——输入必须在环内根据当前状态实时生成。这就把"解题"从一次性离线问题变成了持续的在线问题。其三，它对人很友好：拖拽、甩动、微调是触屏与鼠标用户的肌肉记忆，无需阅读任何规则。

## 0x03 轨迹建模：作为一维时间序列的人类性

在讨论判别器之前，先回答一个更根本的问题：指针轨迹究竟是什么模态的数据？

一段轨迹是均匀采样的多元序列，每个采样点携带坐标与按键状态。它至少有两种同样合法的看待方式：可以把它 rasterize 成一张二维图像，交给二维卷积乃至 ViT 处理；也可以保持其本来面目，把它当作一维（多通道）时间序列。我们坚定地选择后者，理由有三。第一是代价对称：渲染加二维卷积的服务端开销比一维卷积高出至少一个数量级，而上一节确立的公平性原则要求验证代价与客户端代价只差常数——判别器自身必须足够廉价，不能成为新的不对称来源。第二是归纳偏置的匹配：轨迹的本质是控制信号随时间的演化，人类性寓于延迟、震颤与修正的时序结构之中，而非寓于空间形状；渲染成图引入的空域冗余既不增加信息，反而为逐像素的对抗微扰打开了方便的攻击面，与我们对时间前后依赖的坚持背道而驰。第三是泛化：一维表示配合差分化（见下）天然抹平了绝对坐标与关卡布局，而图像表示则会把这些无关信息一并编码进去。

既有工作大致沿三条路线展开。其一是手工特征路线：提取速度、加速度、加加速度的统计矩与曲率分布，再辅以 SVM 或梯度提升树——这是业界滑块类产品的事实标准，其软肋在于特征集合是公开可枚举的，攻击者用模仿学习或生成模型对有限的特征维度做分布对齐即可绕过，防御纵深完全系于特征工程的保密。其二是图像化路线：把轨迹渲染为图片后套用成熟的视觉骨干网络，除前述代价与攻击面问题外，它还继承了视觉模型对对抗扰动的全部脆弱性。其三是序列模型路线：RNN 及其变体在长序列上饱受梯度病态之苦，而直接套用大型 Transformer 又与"判别器必须廉价"的约束相冲突。换言之，我们需要的恰是一个时间序列分类领域里"足够强又足够小"的架构。

这把我们引向了 Inception 一脉。Inception 模块的核心思想是用并行的多尺度卷积核同时覆盖不同的感受野，再用逐点卷积完成跨通道的信息混合与降维；InceptionTime 等工作把这一思想系统地移植到了一维时间序列分类上，证明了其在极小参数量下的统治力。我们采用的 Inc1D 判别器正是这一脉络的实例化：对一维信号而言，多尺度卷积核的并行具有非常具体的物理含义——小核捕捉高频段的生理震颤与采样噪声结构，中等核对应百毫秒量级的修正子运动与速度剖面形态，大核则覆盖秒级的策略性移动与滞后模式；不同频率成分被并行分支分而治之，再由逐点卷积混合，这正是"mix"之所在。配合差分化输入——模型看到的是速度序列而非位置序列——判别器被迫学习"运动的方式"而非"运动的内容"，这对跨关卡、跨分辨率的泛化至关重要。整个网络仅十余万参数，单条轨迹的推理成本可以忽略，与公平性约束自洽。

![图片描述](upload/attach/202610/994475_YH6395JZTEU2VNZ.webp)

如此安排的另一个红利是保密性的重新分配：轨迹数据必然流经服务端，因此判别器可以整体驻留在服务端——权重、阈值乃至输入预处理方式都不进客户端。攻击者无法下载模型、无法在本地白盒地搜索对抗样本，只能以"完整玩一局"为粒度进行黑盒查询；而每一次查询的代价由算法层保证（见下节）。要对这样的 oracle 做蒸馏或对抗搜索，查询预算是第一堵绕不过去的墙。

## 0x04 算法设计：隐藏的工作量证明与天然的抗对抗性

算法层面有两个值得单独展开的设计。

第一个是把验证本身做成一个隐藏的工作量证明，直接回应公平性要求。由于游戏物理对输入历史是强依赖的，玩家在浏览器里完成的几十秒实时仿真，其过程性结果只有真正跑过仿真的人才能产出；防御方在服务端以完全确定性复算这一过程，并按 2 的幂次时刻抽查中间状态，二者必须严丝合缝地一致。这意味着任何提交背后都必须站着一份与服务端验证开销同阶的真实计算——攻击者最多只能省下常数倍的算力，无法形成数量级上的不对称。换言之，攻击者向服务端发送的每一个请求，都内生地携带了"我已经付出过代价"的证据；批量空转、垃圾洪泛之类零成本消耗防御方资源的经典 DoS 向量，在协议层面被直接消除。这个方案不依赖任何客户端代码的保密——引擎可以完全公开，因为它保护的从来不是秘密，而是"计算确实发生过"这一事实。

第二个设计是控制问题对 AI 原生攻击的天然抗性，直接回应可验证性要求。上一节的判别器在理论上仍是一个统计模型，攻击者会想用 FGSM 之类的对抗扰动去欺骗它。但在这里，输入不是一张可以任意翻转像素的静态图片，而是一段必须驱动物理系统真正通关的连续控制信号：对抗扰动叠加在轨迹上，轻则破坏控制的稳定性让任务失败，重则改变系统的演化方向，使梯度意义上的"有效方向"与任务意义上的"可行方向"持续冲突。对抗样本攻击所依赖的"输入空间可自由微扰"这一前提，在一个有强时间前后依赖的闭环控制系统里天然不成立。更重要的是，判别器整体驻留服务端，攻击者面对的是一个白盒不可得、只能以昂贵真实对局为单位查询的黑盒 oracle——梯度无从直接求取，查询预算又被协议层的工作量要求严格限流。AI 原生攻击的两条腿，梯度与查询，在这里同时被抽掉了。

## 0x05 效果与数字

在冻结的测试集上，判别器等错误率约为 13.8%；人类通过率约 91.2%——人类偶尔一次过不了，重玩一局就是，反正游戏本身不难；机器探针的绕过率，混合探针池约 6.6%，其中最强的探针仅 0.7%。

![图片描述](upload/attach/202610/994475_76R8JTE2J5Y68XP.webp)

换言之，即使攻击者训练出能稳定通关的 RL agent——这本身已是不小的工程量，连续控制、混沌环境、长时间目标驻留——它每尝试约十五到一百五十次才能蒙混过一次；而每次尝试都需要完整地进行一局最长一分钟的实时游戏。对撞库、爬取等典型滥用场景而言，单 IP 的通过速率被压到了完全不可接受的水平；而对于偶发被误伤的人类，"再玩一局十秒钟小游戏"的成本趋近于零。安全性的不对称，第一次站到了防御方这边。（当然你上人工调参+PID肯定是有非RL解的...唉唉自动控制原理）

## 0x06 局限与讨论

诚实地说，这个方案并非银弹。EER 13.8% 不是密码学意义上的安全界：判别器能防住冻结的探针集，不代表能防住针对它自适应训练的对抗 policy，只不过自适应攻击需要大量 oracle 查询，而查询被工作量要求限流，两层防御是乘性叠加的。精细指针控制对部分运动障碍用户不友好，生产部署需要无障碍替代通道。打码农场这类真人廉价劳动力对所有行为类方案都是根本性威胁，轨迹分析只是把"机器伪装成人"的成本抬高，这部分最终要靠业务层的其他风控信号。此外判别器本身也存在被长期蒸馏的风险，权重轮换、输入管线扰动、多模型集成都是可行的续命手段。但是，它至少能重新夺回部分主动权：服务端的更新/轮换对客户端而言是完全不透明的，因而能多多少少让对抗回归前AI时代，即，破解过程总是需要人类专家参与？

无论如何，本方案真正想展示的其实是方法论：后AI时代的 captcha，应当把安全性建立在客户端必须真实完成且可严格验证的计算之上、建立在服务端保密的统计判定之上，而不是建立在客户端代码读不懂之上。混淆死掉了，但验证不必陪葬。

## 碎碎念

本文讨论的系统为实验性研究原型，旨在探讨后AI时代人机验证的设计范式，不构成任何生产环境的安全承诺。请勿将其用于超出授权范围的用途。判别器探针集里其实还有些有趣的现象——不同 RL 算法的轨迹"指纹"差异很大——篇幅所限没有展开，有兴趣的坛友可以留言，后续可能单开一贴。本文允许转载，无需额外询问，但请标明出处。

然后就是...帖子以我觉得比较重要的内容为主，一些比较琐碎的实现，还劳烦各位坛友移步下载附件中的源码查看，谢谢w

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

上传的附件：

waf_foss_src.zip （357.53kb，8次下载）

最新回复 (2)
mb_rjdrqvpa 雪币： 9178 活跃值： (10682) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 91 粉丝 3 关注私信	mb_rjdrqvpa 2 楼试了一下你的验证码demo，人玩起来都费劲，花了几次几十秒才通过 2天前 0
the_hs 雪币： 2979 活跃值： (2258) 能力值： ( LV6，RANK：90 ) 在线值：发帖 19 回帖 23 粉丝 53 关注私信	the_hs 1 3 楼 mb_rjdrqvpa 试了一下你的验证码demo，人玩起来都费劲，花了几次几十秒才通过这个scheme确实是有这个问题，不过我看recaptcha未必就好到哪去就是了（） 1天前 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复