思考与感悟：当算法成为“黑箱”，我们需要换一种战场

一、从“拆锁芯”到“还原门”

这次抖音 a_bogus 的逆向过程，给我上了一堂生动的课：技术问题的解决，往往不取决于你有多聪明，而取决于你选对了哪个层次的战场。

最初，我让 Sonnet 去还原 a_bogus 的生成逻辑。它选择了一条看似最“正统”的道路——纯 JS 算法还原。它找到了关键文件，定位了入口点，甚至追踪到了 VM 的执行框架。三个小时的等待后，它依然没能跑出一个可用的签名。

而 Codex 用了二十分钟，走的是另一条路：补环境。它没有试图去理解 VM 里的字节码在算什么，而是把整个 BDMS 代码扔进一个模拟的浏览器环境里，让算法自己跑出来。

后来我反思，Claude 其实离答案很近了。它找到了门，甚至摸到了锁芯的结构，但它一直在试图用纯逻辑去“拆锁芯”——反编译 VM、追踪 opcode、推导签名算法。而 Codex 的做法是：我不管锁芯长什么样，我直接把整扇门装进一个我能控制的房间，让它自己打开。

这让我想起一个经典的哲学比喻：你不需要知道钟表里每一个齿轮的齿数，只需要知道怎么拧发条。 有些时候，“复现环境”比“理解原理”更高效、更务实。

二、完整的环境，比局部的正确更重要

第二个让我深有感触的点，是 Cookie 的完整性。

Opus 在对比中一针见血地指出：Codex 之所以直接跑通，不是因为它算法更厉害，而是因为它从我的test.py里读取了完整的 Cookie，包括那些 HttpOnly 的字段。而 Claude 的初始版本自己构造 Cookie，漏掉了 bit_env、bd_ticket_guard_client_data 这些“看不见”的字段，导致接口返回空响应。

这件事让我意识到：在逆向工程中，“完整性”往往比“正确性”更难，也更重要。

你可以把签名算法还原得 99% 正确，但只要漏了一个输入因子——一个 Cookie、一个 Header、一个 fingerprint——整个结果就是废的。而补环境方案之所以鲁棒，正是因为它“贪心”地保留了所有环境信息，宁可多给，绝不缺漏。

这让我联想到软件开发中的一条原则：宁可让程序因为冗余而变慢，也不要因为缺失而崩溃。 在不确定哪些字段是必需的时候，“全部保留”往往是最安全的策略。

三、工具的选择，本质是思维模式的选择

这次对比中，我看到了不同模型之间的“性格差异”：

• Claude Sonnet 4.6：像一个执着的学者。它想要彻底理解机制，想要反编译 VM、还原算法。它在“理解深度”上走得最远，但也因此卡在了“纯算法还原”的思路上。
• Codex：像一个务实的工程师。它不关心算法长什么样，只关心“怎么最快拿到可用的结果”。它的优势是工具链熟练（argparse、ast.parse、子进程调用），方案直接、工程化。
• Claude Opus 4.7：像一个有经验的架构师。它既理解了 VM 的边界，又没有陷入反编译的泥潭；它补了环境，但同时也清晰地画出了调用栈、梳理了输入因子、给出了端到端的验证。

Opus 的产出让我印象深刻：它不只是给了代码，还给了完整的分析文档、依赖关系图、维护提示。它知道“能用”和“可维护”之间的差距。

这让我思考：当我们说“让 AI 做逆向”时，我们其实是在选择一种“思维外包”。 不同模型的“性格”决定了它们会走不同的路径。没有绝对的好坏，只有是否匹配当前的目标——是要深度理解，还是快速产出？

四、提示词的边界与责任

还有一个值得反思的点：我意识到，Claude 一开始没做出来，可能不完全是它的问题。

我当时给它的提示词，天然地偏向“算法还原”方向——我让“通过 js 还原 a_b 的逻辑，然后 py 获取值去进一步分析”。这个表述本身就隐含了对“可解释性”的追求，而不是对“可用结果”的追求。

而当我换了一种表述——让 Opus 去“补环境”——它十几分钟就给出了可工作的方案。

提示词的本质，是在定义问题的“求解空间”。 如果你描述的是一个“数学题”，AI 会试图推导公式；如果你描述的是一个“工程题”，AI 会试图搭建系统。同样一个 a_bogus，可以是一个“加密算法”问题，也可以是一个“环境模拟”问题。不同的描述，通向天差地别的路径。

这提醒我：在和 AI 协作时，我们的责任不仅仅是“给出指令”，更是“定义正确的抽象层级”。 抽象层级对了，AI 就能在正确的空间里寻找最优解；抽象层级错了，再强大的模型也只能在错误的赛道上奔跑。

五、反思与启示

这次经历，给了我几个可以带走的思考：

1. 算法不是唯一的路。 当一段代码被 VM 保护、被字节码加密、被多层混淆，硬啃算法可能是效率最低的方式。补环境、Hook、模拟执行，这些“运行时”的手段，有时比“静态分析”更省力。
2. 完整的环境胜过精确的局部理解。 逆向工程中，“全量保留”往往比“精确裁剪”更安全。你不知道哪些字段参与签名，那就都留着；你不知道哪个环境变量被检测，那就都 mock 上。
3. 工具的性格决定路径。 不同模型有不同的“本能倾向”。了解它们的性格，才能把正确的问题交给正确的工具。想要深度理解，可以选 Sonnet；想要快速产出，可以选 Codex；想要兼顾深度和可用性，Opus 是更好的选择。
4. 提示词是定义求解空间的艺术。 同一个问题，不同的描述方式会引导 AI 走向完全不同的解决方案。学会给 AI“换一个视角看问题”，是我们作为人类协作者的核心能力。
5. 失败不是终点，而是必要的数据点。 Claude 三个小时的失败尝试，并不是浪费。它证明了“纯算法还原这条路在这个版本下行不通”，这个信息本身就是有价值的。没有它的失败，我可能不会想到去尝试补环境。

写在最后

这次逆向 a_bogus 的经历，技术上只是一个小小的案例，但它让我看到的东西远不止于此。

它让我意识到：当问题变得足够复杂，你不需要成为那个能解开所有谜题的人，你只需要成为那个知道“该找谁来解”的人。

在 AI 时代，我们的角色正在发生变化：从“执行者”变成“决策者”，从“手艺人”变成“指挥家”。我们不需要自己会拆每一个锁芯，但我们需要知道：什么时候该请锁匠，什么时候该直接换门，什么时候该绕道走。

而最重要的能力，可能就是在“理解原理”和“拿到结果”之间，做出那个不完美但正确的权衡。

这次经历也让我更加确定：以后遇到类似的“黑箱”问题，我会先问自己一句——我是想拆开它，还是只想让它工作？

答案不同，战场就不同。

‍