混淆JS分析核心：先理清作用域骨架再逐层还原

拿到一份被混淆过的 JS 文件，第一件事你会做什么？我见过太多人习惯性地先搜 _0x 开头的字符串、找解密函数、或者扔到反混淆工具里一键“跑直”。这一期我想聊一个更底层、也更符合“庖丁解牛”的思路：先别急着还原字符串，先把代码的作用域（Scope）理清楚。

为什么作用域这么关键？因为变量名可以随便改，字符串可以打散到数组里，控制流可以被拍平成 switch 分发，但 JS 的词法作用域决定了“站在某个位置能看到哪些变量”，这是引擎在解析阶段就确定的规则，混淆器很难也不愿意去动它。再乱的混淆，终究是在同一套运行时规则里做伪装。也就是说，作用域是混淆之后依然存在的、最接近原始逻辑的那根“骨架”。顺着骨架下刀，比在碎肉里乱翻要高效得多。

我在这里聊的分析思路，对你自己维护的前端压缩产物、安全研究中拿到的样本代码、或者纯粹想搞懂 JS 作用域机制的读者都适用。对象是那些你有权限分析、且和你的工作/学习相关的脚本。下面的方法不会依赖某个特定工具，而是把一套可以反复使用的“拆解思路”讲透。

1. 为什么作用域是混淆代码里最骗不了人的那根骨架

先说一句容易被忽略的事实：市面上的 JS 混淆方案绝大多数都在做“表面文章”。它们不会真的改变语言语义，只是把代码弄得难以阅读。理解这一点，是你敢去拆解它的前提。

1.1 JS 混淆三板斧：重命名、字符串加密、控制流扁平化

常见的混淆手法基本绕不开这几类：

• 标识符重命名：把所有变量、函数名改成 a、b、_0x1f2e3d 这种无意义名字。这一步主要切断“语义关联”，你看到 getToken 变成 _0x4b 之后，很难靠名字猜用途。
• 字符串与属性名加密：把关键字符串从源码里抠出来，塞进一个数组，再通过下标和解码函数在运行时还原。这样你在代码里看不到明文 URL、Cookie 名、方法名。
• 控制流扁平化：把原本线性执行的逻辑改写成 while (true) { switch (dispatcher) { case 1: ... } }，由分发变量决定下一步执行哪个 case。这类代码读起来最累，因为顺序被打乱了。
• 辅助噪声：往代码里塞死代码、无意义分支、空函数调用，提高人类阅读的干扰。

这些手段分别攻击了“命名可读性”“字符串可读性”“执行顺序可读性”，但有一个层面它们很难攻击，那就是作用域结构。

1.2 词法作用域是引擎找变量的一套既定路线

JS 作用域是词法作用域，意思是代码在书写时就已经决定了变量的可见范围。引擎执行代码时，不会因为函数是从哪里被调用的，就改变它内部的变量查找路线。

举个例子：

javascript复制var x = 'global';

function outer() {
    var y = 'outer';
    function inner() {
        var z = 'inner';
        return x + y + z;
    }
    return inner;
}

无论你把 inner 拿到哪里去执行，它在自己内部找不到 x 和 y 时，只会沿着“定义它”的那条链往外找：先找 outer 的局部作用域，再找全局作用域。调用位置不会影响这条链。

这一点对分析混淆代码非常重要。混淆器可以把 outer 改名为 _0xa1，把 y 改成 _0x2c，但 函数 _0xa1 内部的那个变量相对于内层函数依然是“外层变量”，这个关系改不了。

1.3 庖丁解牛的“牛”，指的就是作用域骨架

我经常把混淆后的代码想象成一头被贴错标签的牛。肉块上的标签可以乱贴，但骨头和关节的位置不会变。你需要做的就是认清哪些是“关节”，顺着连接点下刀，把肉一块块卸下来。

在 JS 里，“关节”就是作用域的边界。一个函数体是一个关节，一个块级作用域是一个关节，一个模块顶层也是一个关节。搞清楚这些边界之后，原本挤成一团的代码就会自然分成若干块，你再逐块去分析每一块内部做了什么，难度会直线下降。

2. 第一刀：先理顺全局作用域，很多绕圈代码会立刻变直

拿到混淆文件后，我通常不从函数中间开始看，而是先找到“骨架最大的那一层”——顶层作用域。很多混淆代码之所以看起来绕，是因为你把大量细节和主干混在一起看。先把主干抽出来，再逐层往下切，会轻松不少。

2.1 先找到代码的启动入口在哪里

混淆代码不一定从文件第一行开始执行。常见的情况是：文件顶部定义了一堆函数，最后一行才真正启动逻辑；或者整个文件被一个大 IIFE（立即执行函数表达式）包住。

我在分析时第一步是定位启动入口。具体方法就是去文件末尾看有没有“非函数定义”的调用语句。如果文件最外层是个大括号加 function(...)，最后跟着 })(...)，那说明整体代码被包在了一个 IIFE 里。

另一个实用技巧是看这个 IIFE 传进来的实参是什么：

javascript复制(function(_0x3f2a, _0x8c21, _0x9d4e) {
    // 大量混淆代码
})(window, document, navigator);

看到这种结构，你应该立刻在笔记里把 _0x3f2a 标记为 window、_0x8c21 标记为 document。别小看这一步，它能直接解开后面一大半的困惑。因为在这个 IIFE 内部，代码访问浏览器 API 时会写 _0x3f2a['location']['href']，如果你不把 _0x3f2a 还原成 window，就会觉得它是在访问某个神秘对象的属性，读起来非常费劲。

2.2 模块作用域和真实全局作用域要分开理解

现代 Web 代码打包后经常被包成一层模块作用域。这个模块作用域虽然最外层也是 (function(){...})()，但它并不等于全局作用域。判断方法很简单：看代码里有没有通过参数接收 window 或 globalThis。

如果最外层函数把 window、document 作为参数传入，那这个最外层函数是“模块作用域”，真正的全局对象是它的参数。如果代码里直接使用 var xxx = ... 或者没有函数包裹，那它就在全局作用域中直接定义变量。

把这两层区分开，能避免一个常见的误导：你看到一个被混淆的变量，以为它是全局变量，其实它不过是最外层函数体的一个局部变量，只是被很多内层函数引用而已。

2.3 把顶层的“变量账本”先登记出来

厘清作用域层级后，我会把顶层作用域里的赋值动作全部过一遍。这一步相当于给这头牛的大骨架拍 X 光片。

通常比较恶心的情况是：

javascript复制var _0x4d2f = ['\x68\x65\x6c\x6c\x6f', '\x77\x6f\x72\x6c\x64'];

function _0x2a1b(_0x3c4e) {
    var _0x9f7a = _0x3c4e[0x0] + ' ' + _0x3c4e[0x1];
    return _0x9f7a;
}

console['log'](_0x2a1b(_0x4d2f));

这里顶层的 _0x4d2f 其实是一个字符串表，_0x2a1b 是解码函数。它们在逻辑上是“初始化数据”和“基础工具函数”，不属于核心业务。先把它们识别出来，后续分析核心逻辑时就不会被干扰。

顶层变量里最容易藏“核心配置”的，是那种赋值内容为对象、且对象属性也在后续被读取的变量。遇到这种，哪怕暂时不知道它的原始含义，也应该在笔记里标注为 configObject? 之类的暂定名，方便后文引用。

3. 第二刀：每个函数单独解剖，Scope 的边界就是逻辑的边界

全局作用域理顺后，下一步就是把它下面的函数逐个拆开。一个函数就是一个独立的小任务单元。混淆常常把一个大函数拆成很多互相调用的小函数，但不管怎么拆，函数之间通过参数、返回值和作用域链交换数据。只要你把每个函数的“输入、输出、依赖了哪些外层变量”搞清楚，整个逻辑链就能串起来。

3.1 函数声明、函数表达式与箭头函数带来不同的 Scope 特征

同样是定义一个函数，写法不同会影响它在作用域里的初始化时机。这个区别在分析混淆代码时很有用。

javascript复制console.log(typeof _0xfn1); // "function"
console.log(typeof _0xfn2); // "undefined"

function _0xfn1() {}

var _0xfn2 = function() {};

函数声明会被提升到作用域顶部，所以哪怕代码里在声明之前就调用它，也不会报错；函数表达式则只有执行到那一行时才会被赋值。如果一个混淆文件中，后面才定义的函数被前面代码提前引用，那这个函数原本大概率是“函数声明”。如果调用时报 undefined is not a function，那它可能是函数表达式。

箭头函数也需要留意。箭头函数不绑定自己的 this 和 arguments，它内部的 this 来自外层作用域。混淆代码中如果出现箭头函数，说明作者可能有意保留外层 this 语义，或者这份代码是从未混淆的现代源码直接压缩过来的。你可以通过箭头函数在哪一层作用域被定义来判断它捕获了什么。

3.2 形参被压成 _0x... 时，从调用点反推语义

函数形参是最容易被改名成 _0x1、_0x2 之类的东西。只盯着函数内部看，你很难猜出某个参数是干嘛的。正确的做法是去所有调用点看实参是什么。

比如有一段代码：

javascript复制function _0x1a(_0x11, _0x22) {
    var _0x33 = _0x11.substr(0, 10);
    return _0x22 + _0x33;
}

// 调用点1
var a = _0x1a(token, 'timestamp=');
// 调用点2
var b = _0x1a(nonce, 'nonce=');

结合调用点，你可以推断 _0x11 实际是“待处理的字符串”，_0x22 是“前缀”。即使你没办法给它们恢复出特别精确的原始名，用 inputStr、prefix 这种伪名也比 _0x11、_0x22 好读百倍。

我的习惯是每分析一个函数，就先把它的调用点全部列出来，弄清楚它可能被哪些模块调用、传入的数据是什么类型。这个过程能帮你快速判断函数在整条逻辑链里的位置。

3.3 跟着赋值与引用关系，而不是跟着名字解读局部变量

混淆代码里的局部变量名没有参考价值，真正有价值的是变量之间的“数据流”。

你可以这么想：一个变量如果一开始被赋值为某个计算结果，之后又被当作参数传给解密函数，最后拼进 return 值，那它的角色就是“中间结果”。如果一个变量在函数开头被赋值为 {}，后面不断给它挂属性，那它就是“临时对象/配置对象”。

如果你对着混淆后的名字去猜，很容易掉进泥潭。我建议把注意力放在“谁在什么时候写入了它、谁在什么时候读取了它”上。先把读写关系标出来，名字自然浮现。

4. 第三刀：闭包与回调链，动态分析才是主角

前面聊的主要是静态阅读。但混淆代码里有一类结构，单靠静态读源码很容易绕晕，那就是闭包和回调链。闭包会跨越多个函数层次保存状态，回调则会把代码的执行顺序打乱。好在浏览器开发者工具给了我们一套动态分析的利器：作用域面板和调用栈。

4.1 混淆器为什么偏爱用闭包来藏“状态”

不少涉及动态签名、动态 Cookie 的脚本，核心逻辑是生成一个“不断变化的值”。实现这种效果最简单的办法就是用一个闭包来保存内部状态。

看这个典型的例子：

javascript复制var getDynamicValue = (function() {
    var seed = 0x1f2e3d;

    return function() {
        seed = (seed * 0x41c64e6d + 0x3039) & 0x7fffffff;
        return seed.toString(16);
    };
})();

在混淆后的代码里，seed 可能被改成 _0xseed，getDynamicValue 可能被改成 _0xabc。但有一个信息很关键：外层匿名函数返回了一个内层函数，内层函数每次执行都会修改外层变量 seed。

从作用域角度看，代码被分成了三个层级：

• 最外层：定义了 getDynamicValue 变量；
• 中层匿名函数：定义了 seed；
• 内层返回函数：读取并修改 seed。

如果你没有意识到 seed 属于中层闭包作用域，而是把它当成全局变量，那你就会想不通为什么每次调用后它的值都会变化，又为什么从外部无法直接重置它。

遇到这类函数时，我一般直接在返回函数内部下断点，然后观察 Scope 面板。DevTools 会非常清楚地列出 Local、Closure 和 Global 三部分，你不用猜，一眼就能看到 seed 属于哪个闭包。

4.2 动态 Cookie 与签名算法断点调试走一遍

假设你正在分析一段“JS 混淆动态 Cookie”逻辑。这类代码通常不是一行生成完，而是分成好几段：先取时间戳，再拼接固定字符串，然后做多次编码，最后写入 Cookie。

关键操作是：不要从文件开头往后读，而是先在最终的赋值点或返回点下断点，然后让它执行。触发之后往上翻调用栈，看每一帧里传了什么参数、中间变量是什么值。

我在实际分析里经常这么做：

1. 格式化混淆文件，找到可疑的赋值语句（比如 document['cookie'] = ...）。
2. 在那一行下断点。
3. 让页面逻辑自然触发。
4. 断点命中后看右侧 Scope 面板，此时当前函数内所有局部变量、闭包变量的实时值都在那里。
5. 如果某个值是字符串，可以直接右键复制，当作解密的线索。

这里有个经验：不要在最大的入口函数处断点，因为那里变量太多。最好找到那个真正做拼接或编码的小函数入口，它内部作用域干净，变量直接对应算法步骤。

4.3 Promise 链与事件监听里的作用域，别把内层和外层混在一起

现代代码大量使用 Promise 和事件监听。混淆器也很喜欢把逻辑藏在 .then(function(){ ... }) 或者 addEventListener 的回调里。

比如：

javascript复制fetch(url).then(function(res) {
    return res.text();
}).then(function(text) {
    var data = JSON.parse(text);
    return data['sign'];
}).then(function(sign) {
    generate(sign);
});

每个 .then 都有一个独立回调函数，也都会捕获外层变量。问题在于，多个 .then 嵌套时，代码的可读性会直线下降。分析时一定要借助 Scope 面板去区分“当前函数自己定义的变量”和“外层传进来的闭包变量”。

尤其是回调闭包引用了一个循环变量时，还可能有经典的“循环里用 var 和用 let”的区别。用 var 声明时，所有回调共享同一个变量；用 let 声明时，每一轮循环会形成独立绑定。混淆代码里如果看到回调内引用了一个看似循环变量的东西，注意它是 var 还是 let，这直接决定了它的作用域表现。

5. 还原变量名不是靠猜，用一张证据表把 Scope“钉”在纸上

分析超过一定规模之后，只靠记忆是不行的。人脑记不住一百多个 _0x 开头的变量分别对应什么。这时我建议做一张“作用域证据表”，把你对每个变量/函数/对象的所有判断和证据记录下来。这一张表是整场分析的地图。

5.1 证据表要记录哪些字段

我在还原一个较大的混淆脚本时，通常会用下面这种结构：

表格的核心作用不是一定要给出“最终答案”，而是让所有判断有据可查。比如你一开始把 _0x1a 的功能猜错了，没关系，证据表能帮你回溯到最初判断的依据，及时修正，而不是越分析越乱。

5.2 用 AST 对同一作用域内的混淆名批量语义化

当你已经通过静态加动态分析确定了一部分变量的语义，代码还原工作可以通过 AST 工具批量完成。这里常用的是 Babel 工具链，它能解析 JS 代码，并且保留作用域信息。

下面是一段很简单的示例逻辑，帮你理解思路：

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

const ast = parser.parse(code);

traverse(ast, {
    FunctionDeclaration(path) {
        if (path.node.id && path.node.id.name === '_0x2a1b') {
            path.scope.rename('_0x2a1b', 'decodeString');
        }
    },
    VariableDeclarator(path) {
        if (path.node.id.name === '_0x4d2f') {
            path.scope.rename('_0x4d2f', 'stringTable');
        }
    }
});

const output = generate(ast).code;

这段代码的作用不是把整个文件“一键还原”，而是在你已经判断出 _0x2a1b 是解码函数、_0x4d2f 是字符串表之后，把代码里所有指向它们的引用统一改名。path.scope.rename 会自动处理同作用域内的引用，比手动全局替换安全得多，不会误伤其他同名变量。

关键提醒是：一定要先做作用域分析，再做批量改名。如果你没分清两个不同作用域里的同名变量，全局替换就会把代码改坏。用 AST 工具处理时也最好按函数逐个处理，改一个验证一个。

5.3 警惕“可读输出”带来的错觉

很多反混淆工具能把加密字符串还原成明文，甚至能把一部分控制流拉直。这类输出看起来“能读了”，但距离理解逻辑还有很大距离。工具通常不会帮你正确还原作用域结构，也不会自动告诉你某个 _0x11 是 token 还是 nonce。

我见过不少人把工具输出后的代码从头到尾读了一遍，依然不知道它在干什么。原因就是缺少对作用域层级的主动整理。工具只是“把肉从骨头上刮下来”，最后怎么把每块肉放回正确位置，还得靠你自己。

6. 这些场景极易误导 Scope 判断：eval、with、块级 catch 与同名遮蔽

作用域分析并不总是一帆风顺。有些 JS 语法特性会在作用域里制造“特殊通道”，一旦忽视它们，你的分析结果就会跑偏。

6.1 eval / new Function 造成的动态作用域缺口

经典的 eval 调用可以在当前作用域里动态插入变量。静态分析代码时，编译器无法预知 eval 里的字符串会定义什么变量。更让人头疼的是，eval 里的代码访问变量时会顺着当前作用域链走，这意味着它的行为是动态的。

好在现代前端工程基本不会主动用 eval，因为 CSP 策略会禁掉它。但你在分析老代码或者某些刻意规避检测的脚本时，可能会遇到。如果碰见，建议把这块单独拎出来，尝试在调用前打印或断点查看 eval 接收到的字符串内容，否则后面所有作用域分析都可能是错的。

new Function(...) 则相反：它创建的函数不捕获当前局部作用域，而是在全局作用域中运行。所以从效果看，它比 eval 好分析一点，但也容易让你产生“这个函数应该能访问当前变量”的错觉。

6.2 with 语句足以让词法作用域分析暂时失效

with 语句在严格模式下已经被禁用，但在旧的混淆样本里偶尔能看到。它会临时把某个对象放入作用域链头部，导致块内部的所有变量查找先查这个对象的属性。

javascript复制with (obj) {
    a = 1;
}

这段代码里的 a 到底赋值给了 obj.a，还是赋值给了外层作用域的变量 a，取决于 obj 是否有一个叫 a 的属性。这意味着静态分析时你无法确定答案，必须先弄清楚 obj 的内容。

在分析过程中遇到 with，我通常直接标记为“特殊节点”，并去运行时环境里确认对象结构，而不会花大力气做静态推断。

6.3 catch 参数、块级作用域与同名遮蔽

catch 块也会引入一个块级作用域绑定。catch 后面的括号里那个变量，只在该块内可见，外面访问不到。这个特性经常被混淆器拿来制造干扰。

javascript复制var value = 'outer';

try {
    throw 'inner';
} catch (value) {
    console.log(value); // "inner"
}

console.log(value); // "outer"

如果你忽略 catch 块自己形成了一个新作用域，就会以为后面输出的还是 'inner'，从而得出一堆错误结论。

还有一类常见的坑是同一层级里变量名覆盖。当内层作用域里有个变量和外层同名时，内层代码访问该名字会直接命中内层变量，外层变量被遮蔽。在混淆代码里，变量名已经被改成无意义的短名，同名概率更高，很容易让人误判当前访问的到底是哪一层变量。

DevTools 的 Scope 面板在这里价值很大。断点命中后，它会按“当前函数局部变量、闭包变量、全局变量”分层展示，每个同名变量都能对上正确的作用域，不用靠肉眼硬分。

6.4 如果静态作用域实在恢复不了，换成执行流驱动

有些代码被人为套了很多层包装，一个函数套一个函数，每层只做一点点事。强行静态恢复作用域可能耗时很久。这时我的策略是彻底切换思路：不再追求把整个文件还原成“源码形态”，而是让代码跑起来，通过断点和日志记录执行顺序，观察哪些函数先被调用、哪些变量在关键节点被修改。

这种方法不需要理解每一层包装，只需要理解“数据最终是怎么变出来的”。当一行行输出记录摆到面前时，很多被作用域噪音掩盖的逻辑会被直接展示出来。这本质上是“用执行结果反推代码语义”，和现代动态分析工具的做法一致。

分析混淆 JS 这件事，我自己踩过最大的坑就是太早陷入变量名还原。早期我拿到一段混淆代码，总想立刻把 _0x4b 改成 token、把 _0x9f 改成 url，结果发现到处都是猜测，后面验证出一处错误，整个命名体系就崩了。后来我把重心先放在作用域拆分上——先分清哪个函数属于哪个层级、哪些变量是哪个闭包私有的，再去想它们应该叫什么名字，进度反而加快了。这也是为什么这一期我坚持用“庖丁解牛”来做比喻：混淆是肉，作用域是骨，先把骨头拆明白，肉自然就掉下来了。