从执行轨迹到算法重建：Web 逆向的三层方法

复杂 Web 参数的分析很少由某一个“神奇脚本”完成。更可靠的方法，是把问题拆成静态结构、运行轨迹和环境假设三层，并让每一层都能独立验证。

第一层：用 AST 恢复结构

混淆代码首先制造的是阅读成本。AST 变换的目标不是立即得到最终算法，而是稳定地消除重复包装、展开可以确定的表达式，并为关键节点建立可搜索的名字。

traverse(ast, {
  CallExpression(path) {
    if (isKnownWrapper(path.node.callee)) {
      path.replaceWith(unwrap(path.node));
    }
  }
});

每次变换都应保留输入样本和运行结果。代码变得“更好看”并不能证明语义没有变化。

第二层：用轨迹缩小搜索空间

面对虚拟机式执行流程，逐行阅读往往会失去控制。更实用的做法是记录操作码、栈变化、关键分支和外部读取，再从输出反向定位真正影响结果的片段。

轨迹需要可比较：同一输入多次执行应当稳定；改变一个变量时，差异应当能追到具体分支。这样才能区分算法逻辑、随机量和环境噪声。

第三层：把环境检测作为显式输入

浏览器指纹、时间、事件序列和对象形状都可能参与计算。与其不断补全一个“像浏览器”的环境，不如先列出被读取的属性，记录其用途，再用最小实验确认哪些值真的进入结果。

一条可重复的验证链

1. 固定请求、输入与时间窗口。
2. 保存原始脚本和每一步 AST 产物。
3. 对关键函数记录输入、输出与调用栈。
4. 只改变一个环境变量，比较轨迹差异。
5. 用新的独立样本验证重建结果。

这条路径的价值在于可复查。即使目标代码更新，也可以快速判断变化发生在结构、执行器还是环境层。

本文依据 tiwe0/tiwe0 中公开的 TikTok Web 逆向项目说明整理，未披露私有实现或目标系统数据。