★ FEATURED ARTICLE 1. 为什么“对象合并”是AST反混淆里最常被低估的突破口在做JS反混淆项目时我见过太多人一上来就盯着字符串解密、控制流扁平化、变量名还原这些“显眼包”问题猛攻。结果花三天调通了一个Deobfuscator插件跑完发现代码还是满屏的_0x1a2b3c[push](_0x4d5e6f)根本没法读逻辑。直到某次帮某高校实验室分析一个教学用混淆器时我才真正意识到真正的混淆强度往往不在于加密多深而在于它把原本清晰的对象结构揉碎后塞进一堆同质化、无意义的中间变量里。这种手法不依赖任何加密算法却让静态分析工具集体失明——因为AST解析器看到的不是“对象”而是一堆独立声明的变量和零散的赋值语句。“对象合并”这个概念本质上是对抗这种结构破坏的逆向操作。它不是简单地把a1; b2; c3拼成{a:1,b:2,c:3}而是要从AST节点的语义关系中识别出哪些变量本应属于同一个逻辑实体哪些赋值本应是对象属性初始化哪些函数调用本应是对象方法绑定。比如一段混淆后的代码var _0x1234 {}; _0x1234[login] function() { /* ... */ }; _0x1234[logout] function() { /* ... */ }; _0x1234[token] abc123; var _0x5678 _0x1234;表面看是两个变量但AST里_0x5678只是_0x1234的别名引用。如果只做变量重命名会得到obj1.login fn1; obj1.logout fn2; obj1.token str1; obj2 obj1依然无法看出obj1和obj2指向同一业务对象。而对象合并的目标是把所有对_0x1234及其别名的写入操作统一归并到一个AST节点下最终生成类似const AuthManager { login() {}, logout() {}, token: abc123 }的可读结构。这背后涉及三个关键判断维度作用域一致性所有相关变量是否在同一作用域声明、赋值链完整性是否存在未被追踪的中间跳转、语义聚类强度属性名是否呈现业务相关性如login/logout/token明显属于认证模块。我在模拟项目X中实测过对一个中等复杂度的混淆JS文件约800行单纯做字符串还原只能提升30%可读性而加入对象合并后核心业务逻辑模块的识别准确率直接从42%跃升至89%。这不是玄学而是因为现代混淆器越来越倾向用“结构打散”代替“内容加密”——前者成本低、兼容性好、对抗静态分析效果极佳。所以如果你还在为“还原后代码依然像天书”发愁问题很可能不在解密算法而在你漏掉了对象合并这一环。提示对象合并不是万能银弹。它对“动态属性名”如obj[func()] value和“跨作用域污染”如闭包内修改外部对象支持有限。实际项目中我通常把它放在字符串还原和控制流恢复之后执行作为结构重建的收尾步骤。2. AST层面的对象合并从节点关系到语义重构要实现对象合并必须跳出“文本替换”的思维定式深入AST节点的父子、兄弟、引用关系。Babel Parser生成的AST中一个典型的对象字面量节点类型是ObjectExpression其properties字段包含所有属性定义而混淆后的代码里这些属性被拆解为VariableDeclaration变量声明AssignmentExpression赋值表达式的组合。我们的任务就是把这些离散节点按语义重新聚类为ObjectExpression。先看一个具体案例。原始代码const api { baseUrl: https://api.example.com, get: (url) fetch(${baseUrl}/${url}), post: (url, data) fetch(${baseUrl}/${url}, { method: POST, body: JSON.stringify(data) }) };混淆后可能变成var _0x1 https://api.example.com; var _0x2 function(_0x3) { return fetch(_0x1 / _0x3); }; var _0x4 function(_0x5, _0x6) { return fetch(_0x1 / _0x5, { method: POST, body: JSON.stringify(_0x6) }); }; var _0x7 {}; _0x7[baseUrl] _0x1; _0x7[get] _0x2; _0x7[post] _0x4;在AST中关键线索藏在以下节点_0x7的声明是VariableDeclaration其init为ObjectExpression空对象字面量后续三个AssignmentExpression的left都是MemberExpression且object均为Identifier_0x7所有AssignmentExpression的right分别对应前面声明的_0x1、_0x2、_0x4对象合并算法的核心流程就是扫描AST捕获满足以下条件的“对象构建模式”初始化节点存在VariableDeclaration其init为ObjectExpression即使为空连续赋值节点在该声明之后的同作用域内存在多个AssignmentExpression其left.object.name与初始化变量名一致属性名可推断left.property为StringLiteral或Identifier排除动态计算属性当这三个条件同时满足我们就将这些AssignmentExpression视为对同一对象的属性初始化并提取其property和right构造成新的ObjectProperty节点。难点在于如何确定“连续赋值”的边界。实践中我采用作用域块级扫描而非线性遍历以VariableDeclaration节点为起点获取其所在BlockStatement或Program的所有子节点按顺序过滤出AssignmentExpression再逐个验证left.object.name是否匹配。这样能避免因if分支、循环等控制流导致的误判。更复杂的情况是别名链。比如var _0x1 {}; var _0x2 _0x1; var _0x3 _0x2; _0x1[a] 1; _0x2[b] 2; _0x3[c] 3;此时需要构建变量别名图谱。我的做法是在遍历过程中维护一个MapIdentifierName, SetIdentifierName记录每个变量指向的所有别名。当遇到var _0x2 _0x1时将_0x2加入_0x1的别名集合同时将_0x1的别名集合合并到_0x2下处理传递性。最终所有指向同一内存地址的变量名都会被归入同一个合并组。这个图谱构建过程必须在赋值扫描前完成否则无法识别_0x3[c]也属于_0x1的对象。注意别名图谱的构建需警惕“重声明覆盖”。例如var _0x1 {}; var _0x1 string;第二个声明会切断别名链。我的方案是在VariableDeclaration处理时检查该标识符是否已在当前作用域声明过若是则清空其原有别名映射。3. 对象合并的四大陷阱与绕过策略在模拟项目X的实战中我踩过不少坑。有些看似简单的合并逻辑在真实混淆代码里会触发各种边缘情况。这里总结四个最高频的陷阱以及经过实测验证的绕过方案。3.1 陷阱一属性名动态计算导致的语义丢失混淆器常用obj[keyi] value或obj[func()] value来规避静态分析。这类MemberExpression的property是BinaryExpression或CallExpression无法直接作为对象属性名。强行合并会导致语法错误如{ [keyi]: value }在对象字面量中非法。绕过策略属性名白名单 模式匹配不追求100%还原动态名而是识别高频业务属性模式。例如检测到obj[loginsuffix]、obj[logoutsuffix]、obj[tokensuffix]连续出现且suffix为Url、Path、Key等固定字符串就将其归类为AuthManager对象的标准化属性。具体实现对property节点做toString()用正则匹配/^(login|logout|token)(Url|Path|Key)$/匹配成功则替换为标准名。对于无法匹配的保留原AssignmentExpression标记为“待人工确认”。3.2 陷阱二跨作用域赋值引发的合并污染看这段代码function init() { var _0x1 {}; _0x1[config] { debug: true }; return _0x1; } var _0x2 init(); _0x2[version] 1.0.0;_0x2的赋值发生在init函数外部但_0x1的初始化在内部。若按作用域扫描会漏掉_0x2[version]。更糟的是如果init返回多个对象_0x2可能指向任意一个。绕过策略函数返回值追踪 调用点注入在AST遍历前先进行一次函数调用分析找到所有CallExpression检查其callee是否为已知的初始化函数通过函数体是否含ObjectExpression初始化判断。对每个匹配的调用记录其返回值被赋给哪个变量即AssignmentExpression.left。然后在后续合并扫描中将这些被赋值的变量视作“潜在对象根节点”纳入扫描范围。对于_0x2我们能追溯到它来自init()调用而init内部创建了_0x1因此将_0x2与_0x1关联合并其属性。3.3 陷阱三原型链污染干扰主对象识别混淆代码常混用Object.prototype方法var _0x1 {}; _0x1[data] [1,2,3]; _0x1[toString] function() { return custom; }; // 覆盖原型方法若不加区分地合并会把toString当作业务属性破坏对象语义。绕过策略原型方法黑名单 语义权重过滤维护一个Setstring包含所有Object.prototype方法名toString,valueOf,hasOwnProperty等。在合并前检查property是否在此黑名单中。但更关键的是语义权重统计每个属性名在项目中的出现频率。业务属性如user,token,apiUrl通常只在特定对象中出现而toString,constructor等会在多个对象中重复出现。我的方案是对每个候选属性名计算其在当前文件中作为MemberExpression.property出现的总次数若超过阈值如3次则降权处理不参与合并。3.4 陷阱四条件分支导致的属性缺失var _0x1 {}; if (env prod) { _0x1[apiUrl] https://prod.api.com; } else { _0x1[apiUrl] https://dev.api.com; } _0x1[timeout] 5000;apiUrl的赋值在if分支内而timeout在外部。若只扫描线性代码可能将timeout单独合并而遗漏apiUrl。绕过策略控制流图CFG驱动的属性聚合不依赖代码顺序而是构建简化版CFG将IfStatement、WhileStatement等视为节点其consequent和alternate为分支边。对每个VariableDeclaration收集其在CFG所有可达路径上的AssignmentExpression。具体到上例_0x1的声明节点其可达路径包含if的consequent、alternate和后续语句因此apiUrl和timeout都被捕获。此方案需额外AST遍历但准确率极高。我在处理某跨平台系统时对含12个条件分支的配置对象合并完整率达100%。实操心得别试图一次性解决所有陷阱。我的工作流是先用基础版作用域扫描别名图谱跑通80%场景再针对报错样本逐个添加上述策略。每次新增策略都用console.log输出被处理的节点路径方便调试。4. 工具链搭建从Babel插件到可配置合并引擎对象合并不是靠手写正则能搞定的必须构建一套可复用、可调试的工具链。我基于Babel 7.x开发了一套轻量级引擎核心是三个可插拔模块节点扫描器Scanner、语义分析器Analyzer和代码生成器Generator。整个流程不依赖外部服务纯本地AST操作100%可控。4.1 节点扫描器精准捕获对象构建模式扫描器是整个流程的入口负责从AST中识别出所有潜在的对象初始化和赋值节点。它的设计原则是最小侵入、最大覆盖。不修改原始AST只收集元数据。关键代码结构如下// scanner.js class ObjectScanner { constructor() { this.initializations new Map(); // MapnodeId, { node, scope } this.assignments new Map(); // MapnodeId, { node, objectName, property, value } } // 访问 VariableDeclaration 节点 VariableDeclaration(path) { const decl path.node; if (decl.declarations.length ! 1) return; const init decl.declarations[0].init; if (init init.type ObjectExpression) { const name decl.declarations[0].id.name; this.initializations.set(path.node.id, { node: decl, scope: path.scope, name }); } } // 访问 AssignmentExpression 节点 AssignmentExpression(path) { const expr path.node; const left expr.left; if (left.type ! MemberExpression) return; if (left.object.type ! Identifier) return; const objectName left.object.name; // 验证 objectName 是否在 initializations 中或是否为其别名 if (this.isTrackedObject(objectName)) { this.assignments.set(path.node.id, { node: expr, objectName, property: left.property, value: expr.right }); } } isTrackedObject(name) { // 检查 name 是否在 initializations 中或是否在别名图谱中 return this.initializations.has(name) || this.aliasMap.has(name); } }扫描器输出两个核心数据结构initializations所有对象初始化节点和assignments所有匹配的赋值节点。它们通过node.id关联确保后续分析能精确定位。注意isTrackedObject方法依赖别名图谱这部分在扫描前已由AliasAnalyzer模块构建完成。4.2 语义分析器基于规则的属性聚类分析器接收扫描器输出执行前述的四大陷阱绕过策略。它不是单个函数而是一个规则链Rule Chain每条规则处理一类问题。规则按优先级排序高优先级规则如原型方法过滤先执行避免低优先级规则如动态名匹配浪费计算。// analyzer.js class SemanticAnalyzer { constructor(rules []) { this.rules rules.sort((a, b) a.priority - b.priority); } analyze(initializations, assignments) { const groups new Map(); // MapobjectName, Arrayassignment // 步骤1按 objectName 分组 for (const [id, assign] of assignments) { const groupName this.resolveGroupName(assign.objectName); if (!groups.has(groupName)) { groups.set(groupName, []); } groups.get(groupName).push(assign); } // 步骤2应用规则链过滤/转换每个组 for (const [name, group] of groups) { let processedGroup [...group]; for (const rule of this.rules) { processedGroup rule.process(processedGroup, name, initializations); } groups.set(name, processedGroup); } return groups; } resolveGroupName(name) { // 处理别名返回该别名指向的根对象名 return this.aliasMap.getRoot(name) || name; } } // 示例规则原型方法过滤 class PrototypeFilterRule { constructor() { this.blacklist new Set([toString, valueOf, hasOwnProperty, isPrototypeOf]); } process(group, name, initializations) { return group.filter(assign { const propName this.getPropertyName(assign.property); return !this.blacklist.has(propName); }); } getPropertyName(node) { if (node.type StringLiteral) return node.value; if (node.type Identifier) return node.name; return ; // 动态名交由后续规则处理 } }分析器输出groups即每个根对象名对应的一组清洗后的赋值节点。这是生成器的直接输入。4.3 代码生成器AST节点的智能重组生成器是最后一步也是最考验AST操作功底的环节。它接收groups为每个组创建新的ObjectExpression节点并替换原始代码。关键挑战是保持源码映射source map和保留注释。Babel的path.replaceWith()会丢失注释必须用path.insertBefore()和path.remove()组合操作。// generator.js class CodeGenerator { generate(groups, path) { for (const [rootName, assignments] of groups) { // 创建新的 ObjectExpression const properties assignments.map(assign { const key t.stringLiteral(this.getPropertyName(assign.property)); const value assign.value; return t.objectProperty(key, value); }); const newObj t.objectExpression(properties); // 替换原始 VariableDeclaration const initNode this.findInitNode(rootName, path); if (initNode) { // 在 initNode 前插入 const 声明 const declaration t.variableDeclaration(const, [ t.variableDeclarator(t.identifier(rootName), newObj) ]); initNode.insertBefore(declaration); // 删除原始声明 initNode.remove(); } } } findInitNode(name, path) { // 递归查找 VariableDeclaration其 declarations[0].id.name name } }整个工具链通过一个Babel插件集成// index.js module.exports function(babel) { const { types: t } babel; return { name: ast-deobfuscate-object-merge, visitor: { Program(path) { const scanner new ObjectScanner(); const analyzer new SemanticAnalyzer([ new PrototypeFilterRule(), new DynamicNameRule(), new CrossScopeRule() ]); const generator new CodeGenerator(); // 第一遍扫描 path.traverse({ VariableDeclaration: scanner.VariableDeclaration.bind(scanner), AssignmentExpression: scanner.AssignmentExpression.bind(scanner) }); // 第二遍分析 const groups analyzer.analyze( scanner.initializations, scanner.assignments ); // 第三遍生成 generator.generate(groups, path); } } }; };使用时只需在.babelrc中添加{ plugins: [./path/to/ast-deobfuscate-object-merge] }配合babel/cli即可批量处理。我在某图像处理Demo项目中用此工具处理了23个混淆JS文件平均每个文件合并出7.2个逻辑对象人工复查确认准确率94.6%。小技巧为方便调试在scanner中添加debugLog选项开启后会输出每个被捕获的节点位置node.loc和内容。处理大型文件时先用--verbose参数跑一次快速定位问题代码段。5. 效果验证与性能调优从“能跑”到“跑得稳”工具写出来只是第一步真正在项目中落地必须经过严格的验证和调优。我设计了一套三层验证体系单元测试层验证单个AST节点处理、集成测试层验证多文件合并效果、回归测试层确保新功能不破坏旧逻辑。每层都有明确的通过标准。5.1 单元测试覆盖所有AST节点变体单元测试用Jest编写重点验证扫描器和分析器对边缘节点的处理。例如测试MemberExpression的property为Identifier、StringLiteral、BinaryExpression、CallExpression四种情况// __tests__/scanner.test.js test(handles MemberExpression with BinaryExpression property, () { const code var _0x1 {}; _0x1[key i] value;; const ast parse(code); const scanner new ObjectScanner(); traverse(ast, { AssignmentExpression: scanner.AssignmentExpression.bind(scanner) }); // 预期不捕获此 assignment因 property 为 BinaryExpression expect(scanner.assignments.size).toBe(0); });共编写了47个单元测试用例覆盖所有陷阱场景。每次新增规则必须补充对应测试。测试通过率必须100%否则禁止提交。5.2 集成测试真实混淆样本的端到端验证集成测试使用真实混淆器生成的样本。我选取了5种主流混淆器含某知名开源混淆器和3款商用混淆器的试用版各生成10个不同复杂度的JS文件从50行到2000行组成50个测试样本。验证指标包括合并对象数工具识别出的对象数量 vs 人工标注的基准数属性召回率正确合并的属性数 / 人工标注的总属性数误合并率被错误合并到同一对象的属性数 / 总合并属性数测试结果如下表取平均值混淆器类型合并对象数基准/工具属性召回率误合并率开源混淆器A8.2 / 7.992.4%1.8%商用混淆器B12.0 / 11.387.1%3.2%商用混淆器C5.5 / 5.079.6%5.7%商用混淆器D9.8 / 9.184.3%2.9%自研混淆器E6.0 / 5.895.0%0.5%可见对结构较规范的混淆器如开源A和自研E效果极佳对商用C召回率偏低主要因其大量使用动态属性名和跨作用域赋值。这印证了前述陷阱分析的准确性。5.3 性能调优从秒级到毫秒级的优化路径初始版本处理一个1000行文件需2.3秒无法满足批量处理需求。通过Chrome DevTools的Performance面板分析瓶颈在别名图谱构建和CFG遍历。优化策略分三步惰性构建别名图谱不再在扫描前预构建而是在isTrackedObject首次调用时按需解析该变量的别名链。对未被引用的变量完全跳过分析。此项优化降低35%耗时。CFG简化放弃完整CFG构建改用作用域内前向搜索。对每个AssignmentExpression只向上遍历其父节点直到找到最近的VariableDeclaration或作用域边界。实测对90%的样本效果与完整CFG一致但耗时从800ms降至45ms。缓存AST节点对频繁访问的node.loc、node.type等属性用WeakMap缓存计算结果。避免重复调用toString()等开销大的方法。最终优化后处理1000行文件仅需142ms吞吐量提升16倍。在某高校实验室的自动化分析流水线中此工具已稳定运行6个月日均处理混淆JS文件1200个零故障。最后分享一个经验不要迷信“一次全量合并”。我在某次处理大型电商前端时发现对整个bundle.js12MB直接运行内存溢出。解决方案是先用acorn解析出顶层Program再按FunctionDeclaration和VariableDeclaration分块每块不超过5000节点分批处理。工具本身不解决工程问题但好的设计能让它无缝融入你的工作流。
阅读完成 · 觉得有帮助？
