JS混淆逆向实战：从乱码定位到动态Cookie破解全流程

打开目标网页，按下 F12 的那一瞬间，看到一整屏 _0x3a2f、\x63\x6f\x6f\x6b\x69\x65 乱码字符串时，脑子里通常会冒出同一个问题：这代码到底写的什么鬼？如果你在猿人学这类反混淆平台上做过题，或者接手过某个加密参数分析任务，应该对这种状态不陌生。

很多人以为把代码扔进在线格式化工具，点一下“美化”，乱码就能变回可读源码，结果格式化之后变量名依旧神秘，逻辑还是绕成一团。问题出在哪里？因为你要处理的并不是“排版乱”，而是“语义乱”。这类 JS 混淆源码的核心不是让你看不见代码，而是让你看见代码也读不懂。这篇文章我打算从“源码乱码”这个切入口讲起，把我自己拆解这类混淆 JS 的完整思路、工具链和关键步骤理清楚，尤其适合正在入门 JS 逆向、分析动态 Cookie，或者想系统过一遍猿人学这一类平台题目的朋友。我会直接用实际案例分析，不只讲操作，也讲清楚每一步为什么这么做。

1. 先搞清楚“乱码”到底是哪几种乱，再决定用什么还原本事

1.1 压缩和混淆被混为一谈，才是很多人卡住的第一道坎

先说说最常见的误区：把“压缩代码”和“混淆代码”当成同一件事。

前端工程里 webpack 打包后的 JS 经常是单行几万个字符，开发环境用 prettier、beautify 之类的工具格式化一下马上就能看，因为 webpack 打包默认只做了压缩，变量名被缩短成 t、e、n，但代码的执行结构和真实语义没有变。这就像一篇文章被去掉了所有换行和空格，挤成一团，你重新排版一下就恢复了。

但混淆不一样。混淆是在排版压缩的基础上，把变量名、字符串、函数调用关系、执行逻辑都做了替换和重组。格式化工具只是把“乱成一行的代码”重新排版，它不会把 _0xabc123 还原成 cookie，也不会把一段被拆开拼接的字符串恢复成原来的样子。所以当你在猿人学看到那种满屏 _0x 变量的代码时，第一反应不应该是“找一个更强大的格式化工具”，而是先判断：这段代码到底用了哪种混淆手法？

判断错了方向，后面所有操作都是白费力气。

1.2 源码乱码的四副面孔：变量替换、字符串加密、控制流平坦化、运行时解密

我习惯把所有 JS 乱码问题拆成四种基础形态，实际项目里通常是四种叠加。

第一种是变量名和函数名替换。 这是最简单的一层，把所有有意义的标识符全部换成无意义的短变量或十六进制风格变量，目的就是让你失去阅读线索。原本一个 function calcCookieValue()，混淆后可能变成 function _0x4f9b()，你只看代码根本不知道它在算什么。

第二种是字符串编码与字符串表抽取。 这是“源码里全是乱码字符”的主要来源。常见做法有两种：一是直接把字符串写成 \x63\x6f\x6f\x6b\x69\x65 这种十六进制转义，看着是一长串乱码，其实在 JavaScript 里它运行时就等价于 "cookie"；二是把代码里所有字符串集中放进一个数组，运行时按下标去取，有时候还会对数组做一轮“洗牌”，先排序再取值。

这里要留意一个细节：很多朋友看到 \x63\x6f\x6f\x6b\x69\x65 就慌了，其实只需要知道一点基础——\x63 就是 ASCII 码十六进制 0x63，查表也就是字符 c。很多所谓乱码字符，本质就是普通字符串多穿了一件转义外衣。你用控制台 console.log() 打印一下，看到的就是明文。

第三种是控制流平坦化。 这种手段非常阴间。正常的 if/else、while、for 逻辑，会被改造成一个巨大无比的分发器，类似这样：

javascript复制var _0xstate = 0x1;
while (true) {
  switch (_0xstate) {
    case 0x1:
      ... // 原来的第一步
      _0xstate = 0x3;
      break;
    case 0x3:
      ... // 原来的第二步
      _0xstate = 0x7;
      break;
    // 中间可能上百个 case
  }
}

它在执行效果上和原来的代码完全一致，但你直接读源码时，就感觉自己被困在一个永远跳不完的 switch 迷宫里。第四种是运行时动态解密，相当一部分高级混淆还会结合 Function 构造函数、eval，或者用 atob 之类的方式，把关键逻辑在运行时临时生成出来，甚至代码里放着密码本，函数每执行一次才解密一段。

把这几种形态放在一张表里看，会更清楚它们各自的表现和应对重心：

1.3 拿一个乱码片段练练手：先归类再看下一步

假设你遇到这样一段代码：

javascript复制var _0xabc = ["\x63\x6f\x6f\x6b\x69\x65", "\x6c\x6f\x63\x61\x74\x69\x6f\x6e"];
function _0xget(_0xidx) {
  return _0xabc[_0xidx];
}
var _0xval = _0xget(0x0);
document[_0xval] = "...";

这里 document["cookie"] = "..."，看起来乱，但归类很清楚：它只是做了“变量名替换 + 字符串转义 + 数组表”。你不用急着写一个解混淆脚本，先在浏览器控制台执行一下 console.log(_0xabc)，马上就能看到数组里的明文。归类完成之后，你就知道了这属于可以直接“运行时取明文”解决的类型，而不是非要去读 \x63\x6f 到底是个什么字符。

这种“先归类再动手”的习惯，能在乱码分析里帮你避开最大效率坑：你不需要理解代码里的每一处细节，你只需要知道目标逻辑藏在这一大坨乱码的哪个部分，以及判断那部分属于哪一种乱法。

2. 格式化不等于解题，把一坨乱码变成能查证的结构

2.1 格式化只是排版工具，不是还原工具

前面反复强调格式化不是混淆的对手，但在真正动手时，我还是会第一时间对源码做格式化。原因很简单：格式化虽然不能让 _0x 变量变回有意义的名字，但它能还原代码的嵌套结构，让函数边界、调用层级重新变得清楚。

举个例子，混淆代码压缩后可能是这样：

javascript复制!function(){function _0x1(a,b){return a+b}function _0x2(c){return _0x1(c,c)}console.log(_0x2(2))}();

格式化之后就变成：

javascript复制!function () {
  function _0x1(a, b) {
    return a + b;
  }
  function _0x2(c) {
    return _0x1(c, c);
  }
  console.log(_0x2(2));
}();

虽然函数名还是 _0x1、_0x2，但你已经能看出它的大致边界了。所以格式化在流程里不是用来“解题”的，而是用来看结构的，它解决的是代码的“可读性”，不是“语义可恢复性”。把它当成拆解乱码的第一步，而不是最终答案，心态就对了。

浏览器方面我建议直接用 Chrome DevTools，把混淆 JS 文件在 Sources 面板打开后，点左下角的 {} 按钮即可格式化。这个操作几乎零成本，而且做的不是转存，不会破坏原文件执行逻辑。

2.2 用特征搜索和调用栈快速定位可疑代码

格式化之后的下一步，是从头读代码吗？不是。我见过一些新手拿到格式化结果后，像读小说一样从第一行开始读，结果读半小时还在纠结一个数组里面是怎么存字符串的。效率最高的方式，永远是从目标反推代码位置。

比如你要分析的就是动态 Cookie，那么你的搜索线索不应该是“代码里有没有 cookie 这个字符串”，因为 cookie 这个词很可能是被编码在字符串数组里的。你要搜索的应该是更靠近行为边界的特征：

• 写 Cookie 的入口：document.cookie
• 发请求的入口：XMLHttpRequest、fetch、.open(
• 设置请求头的入口：setRequestHeader
• 读取浏览器环境的位置：navigator.userAgent、screen.width、canvas
• 编码调用常见位置：charCodeAt、fromCharCode、substring、toString(16)

这里我有一个特别好用的习惯：如果是在浏览器环境里，先不要急着翻源码搜索字符串。看清目标 Cookie 是从哪里写入的，然后在 DevTools 的 Sources 面板里，给它下“调用栈断点”。

以 Cookie 为例：你可以在 Console 里先执行下面的代码，把 document.cookie 的 setter 挂钩子，碰到写入时自动触发断点：

javascript复制var cookieSetter = Object.getOwnPropertyDescriptor(Document.prototype, 'cookie').set;
Object.defineProperty(document, 'cookie', {
  get: function () {
    return cookieSetter.get ? cookieSetter.get.call(document) : document.cookie;
  },
  set: function (value) {
    debugger;
    return cookieSetter.call(document, value);
  }
});

执行之后刷新页面，只要脚本里有任何地方写 Cookie，代码执行就会停在 debugger 这一行。此时打开右侧的 Call Stack，你就能看到是哪一段 JS 在设置，进而定位到核心函数位置。

注意一点，document.cookie 的定义是在 Document.prototype 上面，直接搜 "cookie" in document 不一定找得到 setter。我们通常要拿 prototype 上的 property descriptor。上面这段代码已经做了处理，可以直接用。

2.3 AST 视角：为什么正则处理不了嵌套里的乱码

当你已经定位到某一坨乱码代码，并且希望以静态方式对它做还原（比如把字符串表里的值替换进去、把无意义的包装函数展开），就不能再用简单粗暴的“查找替换”了。因为混淆代码的嵌套太深，正则表达式在处理括号配对的场景中非常容易失控。你很难写一个正则，准确判断某个字符串下标是不是在函数参数里，还是在一个嵌套三层的数组字面量里。

这时候应该把代码抽象成 AST（Abstract Syntax Tree，抽象语法树）。你可以把 AST 理解成“把代码拆开之后的结构图纸”：变量、字符串、函数调用、表达式都会被映射成树上的节点。对节点做操作，比直接剪字符串要安全得多。

JS 生态里最常用的是 Babel，下面的流程是我日常用得比较多的一个最小框架：

javascript复制const parser = require('@babel/parser');
const traverse = require('@babel/traverse').default;
const generate = require('@babel/generator').default;

const code = fs.readFileSync('obfuscated.js', 'utf-8');
const ast = parser.parse(code);

traverse(ast, {
  // 在这里识别你关心的节点类型
  // 比如某些字符串数组的解密函数调用、某些无意义的包装函数
});

const output = generate(ast).code;
fs.writeFileSync('restored.js', output);

你拿到一个乱码 JS 文件，可以先做两步很基础的 AST 操作，出效果很快：

第一步，把所有在运行前能确定的 \x 转义字符串还原成明文。这一步不需要 AST 也能做，但用 AST 做的好处是你能精确定位到字符串节点的位置，不会误替换注释里或普通文本中的内容。

第二步，找出那些从固定数组里按下标取值的表达式，只要下标是常量，值就可以直接算出来，写成常量节点替换回 AST。比如 _0xabc[0x0] 如果已经能算出是 "cookie"，就可以直接把这一整个节点换成 StringLiteral 节点。

这种静态还原方法有一个前提条件：你要保证混淆器没有做“自我完整性检查”。如果它会在运行时校验代码是否被改动，那你把密文替换成明文之后程序可能会直接报错或跳进 antidebug 分支。所以操作 AST 后，一定要回到 Node 环境或浏览器环境跑一遍，确认结果一致。如果发现替换后行为异常，就说明代码加了完整性校验，这时候你需要的不是无脑替换，而是先找到校验逻辑并处理。

2.4 浏览器下断点永远比纯读源码高效

很多初入门的同学有一个执念：觉得只有把混淆代码完全还原成能读懂的源码，才算“解出来”。但在目标是一个参数或一个 Cookie 的场景里，这个执念会极大地拖慢进度。

浏览器调试有一个很现实的优势：就算混淆再狠，代码最终还是要运行在真实浏览器环境里，它运行那一刻，所有变量里存的都是真实值。你不需要在静态代码里推导 _0x3f2a 到底等于多少，只要你找准执行时机下断点，鼠标悬停上去，或者把它加入 Watch 面板，它是什么值一目了然。

我常用的做法是三步走：先通过 Cookie setter / XHR 断点把目标执行位置断住；再在 Call Stack 里向上层找调用来源，关注每一层作用域里的关键变量；最后在 Console 里手动执行关键函数，构造各种输入，观察输出规律。这套动态追踪的思路，比单纯坐在编辑器里苦读一千行混淆代码，要快一个数量级。

3. 破解一例“动态 Cookie”类乱码：完整拆解链路

3.1 动态 Cookie 不等于动态混淆，两者经常被绑定出现

有一类 Web 接口反爬常见套路，前端每次加载都会动态生成一个 Cookie，这个值每隔一段时间或每次请求都不一样，服务端会校验这个 Cookie 的时效与合法性，超时或伪造直接拒绝。你在浏览器里访问一切正常，但用代码请求接口时，少了这个 Cookie 或使用了过期 Cookie，就会被识别出来。

这种机制非常多见，动态 Cookie 往往还会叠加一层 JS 混淆。为什么？因为动态 Cookie 的生成逻辑如果写得清清楚楚，那么别人立刻就能看懂“哦，原来是时间戳 + MD5”之类的东西，防护也就失去意义。所以平台做成题目时，通常先把核心生成逻辑隐藏在一堆源码乱码里，让你自己找出“它到底怎么算出来的”。

我之前在猿人学平台上处理过一类“动态 Cookie 生成”机制的题目。整体套路是：页面每次加载都会在本地重新生成一个新的 Cookie，而服务端在收到请求时会同时校验这个值和时间窗。直接抓包复制这个 Cookie 去请求，短时间内可以生效；多刷新几次就会发现后一次请求会覆盖前一次的 Cookie，或者一段时间后就失效，因此必须复现生成算法，才能保证请求稳定通过。

要强调一下，做这类分析前请先确认目标环境是你有权限研究的。猿人学这类平台本身就是用来做 JS 逆向练习的靶场，用它练手没问题；如果是别人的线上业务，请先获得授权。

3.2 从刷新对比到 Cookie 生成点：一条完整的还原观察链路

我习惯把整个过程拆成几个可验证的小阶段，每阶段做完都能得到一个阶段性成果，而不是闷头追代码追几个小时最后才知道对不对。

第一步，清空 Cookie 后连续刷新 5 次以上，观察目标 Cookie 的变化规律。 这一步基本不写代码，只做观察。把每次抓到的 Cookie 按字段拆开，记录长度、字符集、前缀、是否有明显的时间戳字段。很多时候你会看到 Cookie 值包含一串 10 位数字，那就是 Unix 时间戳；如果字符集包含大小写字母和数字，且长度 32，那大概率是 MD5 类摘要结果；如果还带着一些固定字符前缀，说明是拼接后再摘要。

第二步，在 Network 面板中找到携带该 Cookie 的请求，查看它的 Initiator。 如果 Cookie 是某段脚本在请求前通过 document.cookie 写入的，Initiator 会指向具体的 JS 文件和行号。即便该文件已经被混淆成 _0x 满屏，这个位置也能给你一个锚点。

第三步，用 Cookie setter 断点抓住写入时机。 这是很关键的一步。因为混淆代码里直接搜 cookie 通常搜不到目标，反而是一执行 hook，代码自动停在写入点，比任何静态搜索都省事。

第四步，从写入点向上追踪，找到最终拼接函数。 断点停住后，看右侧的实际运行值，Cookie setter 接收到的完整字符串就在眼前。此时往 Call Stack 上层一层层找，通常能找到一个函数，它接收了几个不同的参数，最终拼出这个字符串。在这个函数的调用点设断点，刷新一次，看它的入参分别是什么。你要还原的核心逻辑，就是这些入参如何被计算出来。

3.3 静态还原优先还是动态调用优先？先看你的目标是什么

定位到核心生成函数之后，你会面临一个选择：是把它从混淆代码里完整抽取出来，在本地 Node 环境跑一遍得到值；还是顺着源码把所有逻辑捋直，让每一段都能用人话解释清楚？

这俩并不互斥，但在时间和精力有限的情况下，优先级可以这样判断。

如果你的目的只是让自己的脚本能通过目标服务器的校验，那“动态调用”是最高效的路径。你根本不需要手工解开所有混淆层，只需要把包含核心生成函数的自执行作用域和它所依赖的字符串数组一起抠出来，放到 Node 里，再补齐缺失的浏览器环境变量，直接调用它，拿到值后拼到请求里，任务就结束了。

如果你的目的是写一篇解题分析，或者学习某一种混淆手法的实现细节，那当然要继续做静态还原，把控制流平坦化一层层拆开、把字符串表逐项恢复。

很多有经验的人会说动态调用是“抄近路”，静态还原才是“真功夫”。但我不这么看。这两者就好比你要过一条河，动态调用是找到了一座现成的桥，直接走过去；静态还原是你把桥的结构彻底研究明白，甚至自己能再造一座。日常生活中，大多数人只是想从桥这头走到那头，那走现成的桥，没有必要每次都亲手拆桥重建。但如果你以后想专门做逆向研究，理解“桥为什么能承重”“每一根钢索受力如何”，就必须选静态还原，不能一味省力。

3.4 将核心函数抽取到本地 Node 环境，做可复现校验

下面说说“动态调用”在实操里怎么落地。我把这类工作流归纳为：导出最小可运行单元，然后喂给 Node 跑。

还是拿动态 Cookie 举例。你在浏览器里已经定位到生成函数所在的整个 IIFE（立即执行函数表达式），它的外层大概长这样：

javascript复制!function () {
  var _0xstrs = ["..."];
  // 此处有大量数组位移或自执行逻辑
  function _0xencode(a, b) {
    // 核心编码逻辑
  }
  window._0xgen = function () {
    var ts = Date.now();
    var value = _0xencode(ts);
    return value;
  };
}();

这种代码通常会把一个关键函数挂载到 window 或某个全局变量上，方便调用。但并不是所有代码都这么“友好”，有的没有挂载，那就需要找到调用点后，手动在 Console 里执行目标函数，再观察返回值。

如果要在本地 Node 里复现，我建议这样做：

javascript复制const fs = require('fs');
const vm = require('vm');

const code = fs.readFileSync('./target_code.js', 'utf-8');
const sandbox = {
  window: {},
  document: {
    cookie: ''
  },
  navigator: {
    userAgent: 'Mozilla/5.0 ...',
    platform: 'Win32'
  },
  location: {
    href: 'https://example.com/path',
    host: 'example.com'
  },
  console: console
};

sandbox.window = sandbox;
vm.createContext(sandbox);
vm.runInContext(code, sandbox);
// 如果目标函数挂在 sandbox.window 上，就可以直接调用
const result = sandbox.window._0xgen();
console.log(result);

跑通了之后，一定要做“对照组”验证：在浏览器里连续生成 10 组 Cookie，在本地代码里也连续生成 10 组，再逐项比对这些字段是否一致。如果字符集、长度、前缀都一致，但内部某段值不同，不要急，先看是不是因为时间戳或随机数造成，再看是不是因为本地环境缺少 canvas、WebGL 这类指纹数据被填了空值导致。

我在实际做题时会把浏览器抓到的值和本地运行的值整理成一张对比表，核验每一个分段：

只看一次结果一致并不代表复现成功。动态 Cookie 里很容易藏随机因子或时间窗口，你至少要多组样本来回滚测试，才能得出“本地结果可用”的结论。

3.5 Cookie 能解密取出来，不等于算法已经懂

我遇到过不少朋友在“动态调用跑通了”那一刻特别高兴，然后以为整道题就做完了。其实这一步只证明了你可以“用代码产生正确的结果”，不等于你已经把里面的算法学明白了。如果接下来要应对的是并发场景、请求频率高或者服务端临时改版，你还是会和以前一样被动。

这里给大家一个区分标准。你可以问自己：不看执行日志，关掉浏览器，不调用原来的混淆函数，能不能用纯手工数学公式把同样的 Cookie 算出来？如果能，说明你理解了算法；如果不能，那你只是复制了黑盒。

猿人学平台上有一类题目的设计目的，就是要逼你从黑盒走到白盒。比如通过 Hook 看到两个输入参数，一个是时间戳，另一个看起来是路径或 token，输出是一个固定长度字符串。但你不断改变输入时，输出规律不是简单的哈希。此时你可能要怀疑上面套了 Base64、里面套了 RC4 或其他对称算法。这时候把混淆代码里加密相关的字符串表逐项恢复，可能比直接猜算法效率更高。

4. 乱码分析里最容易让人心态爆炸的五个细节

4.1 你搜到的字符串匹配不是入口，而可能是死胡同

在严重混淆的代码里，直接搜索关键词经常得不到有效结果。因为字符串已经被切割、编码成多段，运行时才会拼接起来。即便你搜到一个 cookie 出现在代码中，它也有可能是某个解密函数内部用到的明文常量，而不是真正写 Cookie 的位置。

比较稳妥的做法：不要一上来就靠全局搜索找入口；先靠动态断点或行为钩子把入口位置锚定。你会发现，很多“看起来像入口”的代码其实是混淆器放出来的干扰项。有的混淆器还会故意把多个长的相似的函数放在一起，让你混淆视线。真正有用的特征是“运行轨迹”，不是“静态字符串”。

4.2 Hook 与反调试检测互相较劲时，先解决掉调试器保护

混淆插件经常内置反调试逻辑，常见的有三种表现方式。第一种是代码里不断插入 debugger 语句，当你打开 DevTools 执行时，它会一直停在 debugger 位置，严重拖慢流程；很多实现还会统计 debugger 执行耗时，一旦发现异常就进入另一个分支。第二种是检测当前窗口的尺寸差异或 console.log 是否被代理，借此判断是不是有调试者在操作。第三种是周期性自校验，一旦发现部分函数被修改或 hook，就会把流程转向错误结果。

应对这些花招，没有什么银弹。我的经验是先把源码格式化，把里面显式的 debugger 关键字批量删掉或注释；如果检测函数里也有 debugger，就定位到那个函数，把调用点替换成空函数。Hook 上遇到的问题也一样，先找出它检测了什么特征，再针对特征去规避，例如不要直接替换原生方法，而是在外部再包一层。

4.3 AST 批量替换之后，脚本反而不跑了

使用 AST 做字符串还原时非常容易踩到“完整性自校验”的坑。我把一堆混淆数组里的下标取值替换成常量之后，本地一执行，代码报错，或者行为完全不对。排查了很久才发现，原来是混淆器在运行时先执行了一遍“自我比对”，它内部保存了某段代码的 hash 或长度记录，一旦发现代码被修改，就主动跳入错误分支。

这类自校验通常藏在某个不起眼的自执行函数里，外部表现很诡异。要处理它，需要先定位校验逻辑：观察报错时调用栈最深的几层，找到那个主动抛出异常或改变数据流的函数，把校验分支绕过去。这个过程比较费时间，所以如果只是赶着要一个业务结果，可以退回到“模糊动态调用”方式：不修改原来的代码逻辑，只抽取原函数并在补好的环境里运行。毕竟原函数自身校验的是“自己没有被改动”，你把原封不动的代码搬进 Node 沙箱，它就没有理由报错了。

4.4 黑盒测试省力省到一定程度，还是要回头补白盒

有些场景里，只做黑盒调用能一直跑通，你也就不想再碰那一大坨乱码了。但还有另一些场景，黑盒会卡死。比如函数的入参包含了一个浏览器环境指纹，同一段代码在本地跑出来的指纹值和服务器侧记录的浏览器环境不一致，服务端就会拒绝。此时你必须搞清楚指纹是怎么算的，才能构造出和目标环境一致的值。

这个分界线其实很清晰：只要本地结果和浏览器结果存在稳定性差异，或者结果与具体运行时环境强相关，就必须回到静态源码层面，把这部分逻辑读明白。不要觉得前面花了大量时间做动态追踪是“绕路”，没有动态追踪你根本不知道差异出在哪里。

4.5 混淆“乱码加强”之后，不要迷信某一个工具

猿人学平台里经常会看到题目描述里写着“乱码加强”之类的前缀。所谓加强，通常不是引入了一种新的混淆算法，而是把多种手段叠加，比如先做字符串数组、再做控制流平坦化、最后再来一轮运行时自解密。这种时候不要指望有一个现成工具一键还原。市面上能找到的通用 JS 反混淆工具基本只能处理一两种固定模式，对叠加混淆和多层包装的代码都会失灵。

我平时遇到加强型乱码的思路是“分层破解”：先处理外层运行时解密，拿到中间层代码；再对中间层格式化，处理字符串数组；最后再处理控制流。每一层处理完，都把代码保存下来，跑一遍，确认行为没变，再进入下一层。像剥洋葱一样，一层层往下拆，绝不能幻想一步到位。

5. 把乱码拆解流程沉淀成可复用的操作清单

5.1 我自己固定的最小分析流程

经过多次踩坑之后，我把自己的分析节奏固定成了一组步骤，分享出来供你参考。

第一步是观察原始数据。不急着看代码，先搞清楚目标值或 Cookie 有什么变化规律，是固定不变、定期变化、还是每次都变。这一步会省下大量时间，因为如果值是固定的，你连逆向都不一定需要做；如果每次都变，那么一定存在时间因子或随机因子。

第二步是在浏览器里定位入口。用行为 hook（Cookie setter、XHR breakpoint、DOM breakpoint）而不是静态关键词搜索，把代码执行位置定住。

第三步是录上下文。在断点位置记录当前函数的入参、Call Stack 上每层作用域里的关键变量、以及全局对象上可供调用的函数。这些信息在后面的本地复现里随时要用，最好直接截图或存成 JSON。

第四步是抽取最小可执行单元。把包含核心逻辑的代码段、它依赖的字符串表、回调函数等按原样抠出来，放到本地独立文件里，尽量不修改内部实现。

第五步是补环境并跑通。在 Node 里用 vm 或直接放到无头浏览器里运行，补上缺失的 window、document、navigator 等对象，跑出结果，和浏览器样本对比。

第六步是回放验证。多抓几组浏览器样本，用本地脚本批量验证。如果对比结果不一致，回到第三步看上下文，找出缺失的环境信息或隐含状态。

这套流程很基础，但真的能解决大部分入口定位类的乱码问题，无论对方是猿人学的题目，还是日常业务里的加密参数。

5.2 不同混淆方向复用时的调整策略

这套流程并不只适用于动态 Cookie。变量名替换型代码，重点在第二步和第四步，因为入口找到之后，你要做的是给变量重新命名，手工或借助 AST 把无意义变量按语义取名。我之前常用 UglifyJS 和 Babel 工具的最小化规则去识别哪些变量只在一个作用域内短期存在，哪些变量被跨函数引用。

控制流平坦化型代码，基础流程也适用，但要在第五步之前加一个“状态流梳理”动作。你先要根据 switch 分发器的代码，把每个 case 处理的原始逻辑拼接起来，恢复出真实的 if/else 或循环。这一步很难自动化，需要按执行顺序逐段跟踪。

像 WAF 参数这类场景，往往不仅涉及 JS 混淆，还涉及浏览器指纹、时间戳、请求体签名等多因素叠加，分析时就要把“环境数据在哪个节点被读取”也当成重点。你可以给 navigator / screen / canvas 这些对象统一打上 getter hook，记录哪些函数读取了哪些环境数据。哪些字段被读取的顺序本身，有时候就是算法的一部分，不能随便打乱。

5.3 一道乱码题目拆到什么程度，才算真正收工

这个问题在练习平台里尤其容易让人迷茫。我见过两种极端：一种是页面能正常请求了就宣布完成，从不关心核心算法；另一种是明明已经复现出正确的 Cookie，还非要花三天时间把每一层混淆都还原成可读源码，否则就认为自己没做出来。

我的判断标准有两个。如果你是在纯学习平台刷题，那么标准应该是“你能不看原混淆代码，用自己写出来的逻辑清楚解释目标值的生成过程”，甚至能做到本地代码已经去掉了一大部分混淆，只保留和业务语义对应的代码。如果你是在实际业务里做接口联调或合规研究，标准应该是“本地脚本能稳定生成和浏览器一致的结果，连续 20 次以上没有误差”。满足了这个闭环，你就可以先停止深挖，把时间放到更重要的事情上。

5.4 最后再分享一个很实用的观察习惯

我刚拿到一个 “源码乱码 + 动态 Cookie” 类任务时，往往不会直接打开 JS 文件逐行阅读，而是先花几分钟手动刷新目标页面十几次，把每次产生的 Cookie 保存下来，按字段拆开看规律。别急着进入代码，先记录这些原始样本。

原因很简单：很多乱码其实只是虚张声势。它的生成链路也许非常复杂，但最终输出的一定遵循某几种模式：一部分是 Base64 编码的 JSON，里面包含固定的 uid 字段；一部分是时间戳的十六进制；一部分是某种哈希。只要你在样本数据里发现了这些结构性规律，你再回到乱码源码里去定位算法，目标就明确多了。

等你在实际题目里试过这个方法，你会回来感谢自己当初多花了几分钟做观察。因为很多所谓“解不开的乱码”，问题根本不在混淆方式多高级，而在你还没定位到它就一头扎进了代码的汪洋大海。先看变化规律，再锚定入口，然后选择动态调用还是静态还原，最后用多组样本验证闭环——这套思路能让你在任何一个乱码 JS 面前都保持清醒。