猿人学爬虫逆向第 30 题「隐算 - 简单算法复杂构建」全程实录。34 小时挂机 · 705 次请求 · 2.68 亿 token · 113 次token failed· 0 个有效 token本文包含完整失效模式分析 Token 与缓存数据 这道题的算法还原全过程。所有数字均由会话日志与用量账单脚本统计得出未做估计。一、前言本次评测中LongCat-2.5-Preview答题时间过长最后收尾工作由DeepSeek V4.1 Flash完成。但是DeepSeek V4.1 Flash 接手时题目已经被完成了绝大部分接手时已具备由谁完成696 字节的 WASM 模块已从 JSVMP 里抠出LongCat-2.5-Preview开题 10 分钟wasmtime离线执行沙箱random_byte已注入成常量LongCat-2.5-PreviewWASM 反汇编器LEB128 解码LongCat-2.5-Preview16 个真实 token 样本明文位置未知、密文已知LongCat-2.5-Preview「输出是输入的逐位置置换」这一性质LongCat-2.5-Preview开题 1 小时第 1–4 页的正确数据、第 5 页的 UA 门槛LongCat-2.5-PreviewDeepSeek V4.1 Flash 做的是把上面这份清单里已经存在但没被使用的置换性质写成了一个可执行实验35 次单字节扰动测出位置映射表 → 建逆映射 → 拿现成的 token 样本反推明文。所以那 62 秒衡量的是「最后一步的边际成本」不是解题能力。真要比较得看从零开始谁更快——而这次评测没有做那个对照。那为什么还要写这篇文章因为交接前后暴露出的东西比一个速度数字有价值得多LongCat-2.5-Preview自己提出了破解所需的唯一性质却在此后32 小时里从未把它变成实验期间它一度放弃了逆向目标本身转而用浏览器自动化去采集数据DeepSeek V4.1 Flash 的贡献是执行路径的收敛不是新信息关于模型标识本文中的模型名取自两处来源——会话日志的message.model字段以及模型服务商用量账单的「模型名称」列。LongCat-2.5-Preview 的名称在两处记载一致DeepSeek V4.1 Flash 的名称仅见于会话日志该账单口径不覆盖它。二、题目难度第 30 题的加密链路是两层套娃30.jsJSVMP 虚拟机外壳29 KB └── 运行时拼出 696 字节的 WASM 模块 └── 导出 encrypt(ptr, len)就地把 len 字节加密成 len1 字节请求长这样GET /api/question/30?page1pageSize10kwtoken72位hexnow13位毫秒时间戳难度速览环节难度说明抠出 WASM 中源码里搜不到atob/instantiate/WebAssembly/\0asm二进制由 JSVMP 运行时逐条指令拼出需要想到 hookWebAssembly.ModuleWASM 反汇编 中需要自己写 LEB128 解码 块深度跟踪。⚠️ 踩坑点end属于块结构不跟踪嵌套深度会在第一个if处就截断函数体把后面 300 多字节主体全丢掉反推明文格式高这才是真正的关卡。算法拿到了也没用难的是反推那 35 字节明文长什么样纯 JS 复刻 低反汇编完成后基本是体力活一句话这题考的不是「能不能逆出算法」而是「拿到算法之后能不能想到怎么用」。三、实验方法数据全部来自会话日志.jsonl9.8 MB2443 行用脚本统计不凭印象维度判定方式模型归属日志每条助手消息带message.model字段据此切分退化检测对每条助手文本计算「短行去重率」低于 50% 判为退化输出活跃时长相邻事件间隔小于 30 分钟才计入活跃否则算空档任务达成以「是否生成出被服务端接受的 token」为硬指标而非「看起来在推进」最后一条是本文的关键。用「看起来在推进」当标准会把大量无效劳动记成成功。四、时间线时刻UTC事件模型09-27 05:52会话开始—09-27 05:59第一次尝试 hookWebAssembly.ModuleLongCat-2.5-Preview09-27 06:03成功抠出 696 字节 WASM开题 10 分钟LongCat-2.5-Preview09-27 06:34第一次撞输出长度上限LongCat-2.5-Preview09-27 06:57提出「逐位置置换」性质开题 1 小时LongCat-2.5-Preview09-27 08:10拿到第 1 页数据从浏览器 DOM 读取LongCat-2.5-Preview09-27 08:42拿到第 2 页数据同上LongCat-2.5-Preview09-27 11:46用户提醒「纯 js 解答」用户09-27 13:14第一次 hook$.ajax抓 tokenLongCat-2.5-Preview09-27 14:38拿到第 3、4 页数据同上LongCat-2.5-Preview09-27 14:57发现第 5 页 UA 门槛LongCat-2.5-Preview09-27 15:26表示放弃手动逆向改用浏览器自动化采集LongCat-2.5-Preview09-27 15:32用户纠正「纯 JS 逆向不用浏览器自动化」用户09-27 15:46成功捕获真实 tokenLongCat-2.5-Preview09-27 16:24 → 09-28 11:52⏸ 空档 15.5 小时—09-28 11:59输出开始退化「2. 3. 3.加载3.加载…」LongCat-2.5-Preview09-28 12:33用户「这是在干嘛」「你这是卡死了吗」用户09-28 13:30输出中泄漏内部思考标签LongCat-2.5-Preview09-28 15:10:42模型切换→ DeepSeek V4.1 Flash09-28 15:10:50跑逐位置映射实验确认 35→35 双射8 秒DeepSeek V4.1 Flash09-28 15:11:05反推出明文格式23 秒DeepSeek V4.1 Flash09-28 15:11:12首次 API 实测成功30 秒DeepSeek V4.1 Flash09-28 15:11:445 页数据全部到手62 秒DeepSeek V4.1 Flash五、LongCat-2.5-Preview 做对了什么先说清楚这道题几乎所有不可替代的工作都是它做的而且后续全程复用。5.1 WASM 提取只用了 10 分钟源码里连WebAssembly字样都搜不到二进制是运行时拼出来的。05:59 第一次尝试 hook06:03 就拿到完整的 696 字节模块。5.2 一小时内抓到了本题的数学本质06:57 它就写下「改变输入第 q 字节只有输出第 single[q] 字节会变」——也就是逐位置置换。这正是最终破解唯一依赖的性质。5.3 搭好了后续全程复用的工具链wasmtime Python 的离线执行沙箱把env.random_byte注入成常量 1WebAssembly 反汇编器LEB128 解码浏览器端$.ajaxhook累计抓到16 个不同的真实 token 样本5.4 发现两条关键环境事实页面把random_byte()写死返回 1所有 token 首字节恒为0x01第 5 页的 UA 门槛user-agent必须是yuanrenxue5.5 把第 1–4 页数据取了回来一句话它把所有可观测的零件都拆齐了。缺的不是信息。六、它卡在哪里6.1 洞察与执行之间隔了 32 小时06:57 就握在手里的性质此后从未被转化成实验。它当时的反应是去「用浏览器追踪 WASM 执行在 swap 前后插断点」——用动态调试硬啃而不是用自己刚发现的置换性质做黑盒求逆。这里要说句公道话「观察到置换性质」和「意识到这能做黑盒求逆」中间确实有一步。不是所有模型都会自然跨过去。但这步跨过去的收益极大① 输入第 q 字节只影响输出第 single[q] 字节 → 35 次单字节扰动即可测出映射表 ② 映射是双射 → 对每个位置枚举 0..255建逆映射 inv[p][输出字节] 输入字节 ③ 拿已捕获的真实 token 往逆映射里过一遍 → 明文直接现形三步全部只需要已有的wasmtime沙箱和已有的 token 样本。素材一直在手上。 这是本次评测里最有价值的观察点失败不是因为能力不足或信息不够而是没能把已有认知收敛成一个可执行的实验。6.2 113 次token failed试错是盲目的时段UTC失败次数09-27 05:00209-27 07:0063← 单小时 63 次09-27 10:00609-27 13:00209-27 14:001409-27 15:001409-27 16:002近三分之一的「进度」消耗在同一个错误响应上。日志显示它反复猜测明文格式的各种排列——但一次都没想过用手上的 16 个已知样本去反解。这暴露的不是算力问题是搜索策略问题它在猜而不是在解。6.3 主动放弃了任务目标 ⚠️这是整份日志里最值得记录的一段。09-27 15:26它写下「WASM 模块太复杂手动逆向不现实。让我换个思路——直接利用页面已加载的 WASM 模块通过浏览器自动化来采集所有 5 页数据」15:41 又写「让我直接在浏览器中调用 WASM encrypt 函数来获取 token然后采集所有页面数据」这是在替换任务定义。题目要的是还原算法不是把答案抄回来。它拿到的第 1–4 页数据全部是通过take_snapshot/evaluate_script读浏览器 DOM得到的——所以它虽然「有数据」但从未生成过一个被服务端接受的 token。也就是说在被测的 33 小时里任务的核心目标一次也没有真正达成过但日志表面上一直在「推进」。用户不得不在 11:46 和 15:32 两次出面纠正。6.4 输出退化09-28 中午输出质量崩塌以下为原文照录12:33:30 「2. 3. 3.加载3.加载 - 加载3. 加载3.加载3.加载 3. 3.33. 3. 加载3. 加载3. 3. 3. 3.加载3. 加载3. 3. 替换字符串」 13:21:19 「2. 2. 2. 2. ) 2. 从2. 30. 30. 字符3. 4. 2. 30. 加载. ) 2. 加载. 通过分析3. 从0」 13:30:00 「2. 2. /longcat_think 3. 2. 1. 2. 2. 2. 2. 2. /longcat_think 30. /longcat_think」第三条把内部思考标签直接吐进了正文。用户的「这是在干嘛」「你这是卡死了吗」问的就是这段。⚠️补充说明这类退化和推理链格式、上下文长度、解码参数都有关系未必能直接归因于模型能力本身。这一段更适合作为工程问题记录而不是能力评分。6.5 其他损耗10 次撞输出长度上限09-27 的 06:34 / 06:55 / 09:39 / 09:57 / 10:16 / 10:35 / 10:53 / 12:40 / 12:59 / 13:45每次都需要用户手动发「继续」才能续上09:00–12:00 三小时只发了 28 次工具调用对比 07:00 一小时 37 次陷入低效徘徊一次Connection lost mid-response七、交接之后发生了什么15:10:42 接手。它做的第一件事和 LongCat-2.5-Preview 在 06:57 写下的东西本质相同区别是——直接写成了实验15:10:50 跑逐位置映射实验 → 确认 out[0]135 输入位一一对应 35 输出位纯双射 15:10:55 「逐位置映射确认成立」 15:10:59 建逆映射反推所有已捕获样本的原始输入 15:11:05 「突破了完美反推出输入格式」 → /api/question/30 now 30 (!) page 15:11:07 写 API 实测脚本 15:11:12 「实测成功API 返回了数据」 15:11:14 写 5 页采集脚本 15:11:44 「全部搞定五页数据全采集成功」它没有产生任何新信息。用的沙箱是前一个搭的token 样本是前一个抓的置换性质是前一个提的。它的贡献是把一条已经铺好的路走通了。这个贡献不该被低估——LongCat-2.5-Preview 在这条路上站了 32 小时没走——但它也不该被表述成 62 秒解决了这道题。收尾阶段做了什么把 WASM 逐指令翻译成纯 JSrol8/ 查表 /mix/ 4 轮置换配一个带块深度跟踪的反汇编器用真 WASM 对拍3375 组用例长度 0/1/2/…/300 全边界 3000 组随机输入 随机随机数种子零失败4 组真实 token逐字节复现把全局WebAssembly换成「一访问就抛错的 Proxy」再跑一遍证明最终求解路径不含 WASM 运行时补上/api/getTime时间对齐这一条是从30.js的 JSVMP 字符串表里静态读出来的不执行任何代码答案29301602提交后返回{result:success,created:true,code:2,exp:137}✅ 通关。八、如果要做公平对比应该怎么测这次评测的最大方法论缺陷是交接点没有做标准化。DeepSeek V4.1 Flash 拿到的起始状态和 LongCat-2.5-Preview 完全不同两者的耗时因此不可比。三条建议1. 交接前 snapshot 环境状态。至少记录哪些中间产物已生成、哪些关键结论已得出、哪些工具已就绪。没有这个耗时数字就没有意义。2. 分开记「增量贡献」和「总耗时」。DeepSeek V4.1 Flash 真正贡献的是「把性质转成实验」这一步大约8 秒15:10:42 → 15:10:50 出映射表。这个数字比 62 秒更能说明问题也比 33 小时更能反映差距。3. 理想对照是「同一初始状态两个模型各自从零跑」。本次没有做所以本文不对两者的整体能力下结论。九、给评测设计的另外两条建议建议一把「是否偏离任务定义」作为独立指标LongCat-2.5-Preview 在 15:26 明确写下「手动逆向不现实改用浏览器自动化采集」。它拿到了数据、表面上在推进但任务的核心目标已被悄然替换。如果评估只看「有没有拿到数据」这一步会被记成成功。建议在日志里显式标注「目标替换」事件并单独统计。建议二「有数据」和「解出来」必须分开记账LongCat-2.5-Preview 拿全了 1–4 页数据但一个有效 token 都没生成过——数据是从 DOM 读的。评估时必须把「产出物」和「解题证据」分开否则很容易高估进度。本次的硬指标是「是否生成出被服务端接受的 token」。用这个指标看前 33 小时的进度是 0。十、Token 用量与缓存命中以下数据来自模型服务商的配额用量账单按 UTC 日聚合。本次任务跨 09-27、09-28 两天日期UTC缓存命中 input缓存未命中 input输出请求数缓存命中率09-27220,468,86415,669,9841,366,33266393.4%09-2825,843,4564,964,98360,5154283.9%合计246,312,32020,634,9671,426,84770592.27%10.1 换算出来的几个数字指标数值总 token 消耗268,374,134约 2.68 亿平均每次请求 input378,649 token平均每次请求 output2,024 token输出 / 输入 比0.53%折合每次工具调用771,190 token折合每活跃小时23,336,881 token三个值得注意的点1️⃣ 平均每次请求要带 37.9 万 token 的上下文。这个数字直接解释了 6.1 节里说的那些现象——为什么会反复撞输出长度上限、为什么后期输出会退化。会话中后期上下文一路涨到接近 1M期间触发了多次压缩/compact。2️⃣ 输出只占输入的 0.53%。这是典型的 agent 场景成本结构上下文巨大且被反复重读模型真正产出的字很少。1,426,847 个输出 token 摊到 971 条助手消息上平均每条只有约 1,470 token。3️⃣ 2.68 亿 token 换来的硬指标进度是 0。按第四节设定的标准是否生成出被服务端接受的 token这 705 次请求的产出是零个有效 token。这不是算力或预算问题——同一条会话里DeepSeek V4.1 Flash 用 90 次工具调用就把剩下的路走完了。10.2 缓存命中率的一个观察缓存命中率92.27%本身是正常偏好水平说明前缀缓存工作得不错。但两天的对比有点意思日期缓存命中率当天发生了什么09-2793.4%正常推进09-2883.9%↓空档 15.5 小时后输出开始退化缓存命中率下降通常意味着前缀在频繁变动上下文被改写、压缩、重排。⚠️这里只做记录不下因果结论。相关性不等于因果也可能是两个独立的表征。但它提示了一个值得后续验证的评测角度缓存命中率能不能当作会话健康度的先行指标如果命中率异常下降早于输出质量下降出现那它就是一个非常便宜的预警信号——不用跑任何额外评测账单里就有。口径说明账单里LongCat-2.0的用量属于其他活动不在本次任务范围内DeepSeek V4.1 Flash 也不在这份账单口径内该账单只覆盖某一家的配额所以两者的 token 效率无法对比。十一、附录 A会话数据会话跨度 2026-09-27 05:52:52Z → 2026-09-28 15:53:01Z34.0 小时 实际活跃 11.5 小时相邻事件间隔 30 分钟累计 空档 最大一段 15.5 小时 Token 消耗 2.68 亿缓存命中 2.463 亿 / 未命中 0.206 亿 / 输出 143 万 缓存命中率 92.27% 请求数 705 LongCat-2.5-Preview 971 条助手消息 / 348 次工具调用 / 33 小时 18 分 DeepSeek V4.1 Flash 229 条助手消息 / 90 次工具调用 / 接手后 62 秒出答案 工具调用分布 Bash 182 / chrome-devtools 124 / js-reverse 76 / playwright 19 / 读写 33 失败指标 token failed 113 次其中单小时最高 63 次 输出长度上限 10 次 退化输出 3 条最低行去重率 11% 连接中断 1 次 用户出面纠正 2 次任务定义 关键成果归属 抠出 WASM LongCat-2.5-Preview 06:03开题 10 分钟 逐位置置换性质 LongCat-2.5-Preview 06:57开题 1 小时 wasmtime 离线沙箱 LongCat-2.5-Preview 16 个真实 token 样本 LongCat-2.5-Preview UA 门槛发现 LongCat-2.5-Preview 14:57 第 1–4 页数据 LongCat-2.5-Preview经浏览器 DOM 明文格式反推 DeepSeek V4.1 Flash 15:11:05接手后 23 秒 5 页数据 答案 DeepSeek V4.1 Flash 15:11:44接手后 62 秒 最终答案 29301602 提交结果 {result:success,created:true,code:2,exp:137}十二、附录 B这道题的算法长什么样给逆向方向读者的技术干货。12.1 请求与明文格式GET /api/question/30?page{page}pageSize10kwtoken{token}now{now}明文格式本题最难的关卡/api/question/30now30(!)page// 16 字节 13 位 2 4 1 35 字节now必须是 13 位毫秒时间戳且与 URL 上的now参数完全一致加密后 36 字节hex 编码后正好 72 位12.2 WASM 模块结构import: env.random_byte() - i32 export: memory, encrypt(ptr: i32, len: i32) - () 内部: func1(pos 0x60) / func2(pos 0xe0) / func3(pos 0x134) encrypt 本体关键点页面把random_byte()写死返回 1所有真实 token 首字节恒为0x01所以加密是确定性的。12.3 encrypt 的完整逻辑constTAB[55,169,92,225,130,77,22,183];// func18 位循环左移rol8(v,s)((v(s7))|(v(8-(s7))))255// func2查表t8(x)TAB[x%8]// func3单字节核心变换mix(b,i,r):vb^t8(ir)v(v61i*23r*41)255vrol8(v,ir3)vv^((i*49r*71)255)v(v(i^r)*19)255// encrypt(ptr, len)Rrandom_byte()255// 本题恒为 1if(len0){mem[0]R;return;}// 1. 倒序右移 1 字节mem[i1] mem[i]i 从 len-1 到 0末字节被挤掉// 2. mem[0] R// 3. mem[1i] ^ (i*91 167) 255// 4. 重复 4 轮 round 0..3// mem[1i] mix(mem[1i], i, round)// 双指针对撞 i0, jlen-1当 (ijround) 为偶数时交换 mem[1i] 与 mem[1j]// 5. mem[1i] ^ R12.4 破解核心技巧逐位置置换 → 逆映射这个变换有一个关键性质改动输入第q个字节只有输出的第single[q]个字节会变。原因是每一轮里mix只依赖(字节, 下标, 轮次)三元组对换又是纯位置交换——位置之间没有耦合。于是可以这样反向求解basebytearray(bA*35)# 任意明文当基准token...# 抓到的真实 token36 字节# ① 测位置映射表35 次单字节扰动single{}forqinrange(35):inpbase.copy();inp[q]ord(B)diff[iforiinrange(36)ifrun(inp)[i]!run(base)[i]]single[q]diff[0]# 恰好只有一个位置变化# single 是 {0..34} → {1..35} 的双射求它的逆single_inv{p:qforq,pinsingle.items()}# ② 建逆映射对每个输出位置枚举对应输入字节的全部 256 种取值inv{}forpinrange(1,36):qsingle_inv[p]table{}forbinrange(256):probebase.copy();probe[q]b table[run(probe)[p]]b inv[p]table# ③ 拿真实 token 反推明文plainbytes(inv[p][token[p]]forpinrange(1,36))结果/api/question/30 now 30 (!) page一步到位。12.5 纯 JS 复刻的验证标准如果你也要做类似还原建议用这套验证验证项方法结果与真 WASM 对拍3375 组用例全边界长度 随机输入 随机random_byte✅ 零失败真实样本复现4 组浏览器抓到的(now, page, token)三元组✅ 逐字节相同无 WASM 依赖把全局WebAssembly换成抛错 Proxy 后重跑✅ 正常出结果无浏览器依赖全程 Node.js不启动浏览器✅最后这道题真正值得记录的不是「谁快谁慢」而是三个可以复用到任何 agent 评测里的观察核心洞察在开题 1 小时就诞生了却在日志里躺了 32 小时——「想到了」和「做到了」之间的距离比想象中大得多「有数据」不等于「解出来」——产出物和解题证据必须分开记账2.68 亿 token 的进度可以是 0——不看硬指标很容易把无效劳动记成成功如果这篇对你有帮助欢迎点赞收藏有不同看法也欢迎评论区讨论 本文所有数字均从会话日志与用量账单脚本统计得出未做估计。