上个月对接某地级市政务服务平台的公开数据共享接口对方为了保障参数传输安全前端对所有业务请求做了AES加密处理加密逻辑打包在经过重度混淆的JS文件中。由于对方技术侧排期紧张暂时提供不了详细的加密规则只能我们自己逆向还原做联调。拿到混淆文件的第一眼就知道是块硬骨头核心加密函数被完整做了控制流平坦化加固原本几十行的逻辑被拆成上百个分散的代码块包裹在巨大的while-switch状态机里所有字符串字面量全部加密存储函数名、变量名全是无意义的十六进制命名。整个核心函数足足1400多行肉眼根本理不清执行路径。一开始试着用Chrome单步调试走了几轮半小时过去了还在状态机里绕照这个速度没个一两天啃不下来。索性沉下心基于Babel写AST自动化插件从字符串解密、常量折叠到控制流还原分层批量处理。从拿到混淆代码到完整还原AES逻辑、跑通官方测试用例前后刚好3小时比纯手动还原效率提升了5倍以上。本文完整复盘整个反混淆过程从混淆特征识别、AST插件编写到最终算法还原分享定制化控制流平坦化的破解思路与实战踩坑细节。一、混淆样本初判政务场景的定制化加固动手之前先做特征分析判断混淆类型与强度选性价比最高的突破路线。政务场景的混淆和普通电商、社交平台不一样普遍是在通用混淆器基础上做了定制化加固针对性更强。1.1 典型混淆特征识别打开目标JS文件快速确认三重防护叠加字符串全加密顶部有加密字符串数组配套自执行移位函数所有字面量通过索引函数动态解密代码里看不到任何可读常量控制流平坦化核心加密函数外层是while(true)包裹的巨型switch语句靠一个状态变量驱动执行流跳转原始的顺序、分支、循环结构完全被打散定制化反调试内置检测逻辑检测到开发者工具、Node环境、格式化操作时会主动改变解密密钥输出错误结果粗略统计核心的加密函数原始逻辑大概80行左右经过平坦化死代码注入后膨胀到1400多行代码膨胀比超过17:1可读性基本为零。1.2 整体对抗思路面对定制化的控制流平坦化不能直接套通用解混淆工具大概率会失效。我们采用「分层突破、验证驱动」的思路每处理一层就验证一次正确性逐步逼近原始逻辑。原始混淆JS文件第一层环境Mock 字符串解密还原第二层常量折叠 死代码初步清理第三层识别平坦化分发器结构构建状态转移图区分顺序/分支/回环第四层代码块重组恢复原始控制流第五层变量语义化 冗余逻辑清理核心AES算法提取与联调验证很多新手容易陷入一个误区追求100%完美还原原始代码。实际上对于接口联调场景我们只需要保证核心计算路径清晰、输入输出映射正确即可没必要浪费时间在边缘分支和死代码的完美还原上。二、工具链与前置准备工欲善其事必先利其器。AST反混淆的核心工具链是Babel全家桶配合自定义插件完成针对性处理。2.1 工具选型说明babel/parser将JS代码解析为抽象语法树AST支持最新ES语法对混淆代码兼容性好babel/traverse遍历AST节点实现节点的查找、修改与替换是反混淆的核心执行引擎babel/typesAST节点类型判断与构造工具用来生成新的代码节点替换混淆结构babel/generator将处理后的AST重新生成可读的JS代码Node.js 18.x脚本运行环境配合vm模块执行解密逻辑之所以不直接用网上现成的通用解混淆工具核心原因是政务场景的混淆做了定制化修改解密函数加了环境检测状态转移逻辑也做了变种通用工具要么跑不起来要么还原后逻辑错误。自己写插件虽然前期花点时间但可控性强遇到变种可以快速调整。2.2 前置注意事项做AST反混淆不需要精通编译原理但必须掌握三个核心能力能识别常见的AST节点类型知道WhileStatement、SwitchStatement、AssignmentExpression对应的代码结构会用traverse遍历指定类型的节点能在回调中拿到节点信息与父节点引用会用types构造新的节点替换掉旧的混淆节点实际开发中大部分时间都在对照AST Explorer调节点属性真正的核心逻辑代码量并不大。三、分步实战AST还原控制流平坦化整个还原过程分六步推进每一步都验证输出确保没有引入逻辑错误。3.1 第一步字符串解密——绕过环境检测字符串解密是所有反混淆的第一步也是最基础的一步。但这次的解密函数做了定制化改造不能直接抠出来用。踩坑点对方的解密函数内部做了环境检测会检查window、navigator等浏览器对象是否存在。如果直接抠到Node.js里运行会静默返回错误的解密结果不会报错但后续所有字符串都是错的非常隐蔽。解决方案是先做最小化浏览器环境Mock给解密函数提供符合预期的上下文constvmrequire(vm);// Mock最小浏览器环境constsandbox{window:{},navigator:{userAgent:Mozilla/5.0},document:{createElement:()({style:{}})}};vm.createContext(sandbox);// 注入抠出来的字符串数组、移位函数、解密主函数vm.runInContext(extractedDecryptCode,sandbox);constdecryptFuncsandbox._0xdecrypt;环境问题解决后再遍历AST将所有解密函数调用节点替换为实际的字符串字面量最后移除不再被引用的解密函数与数组定义。这一步完成后代码里的方法名、属性名、常量字符串全部恢复可读后续分析效率提升一个量级。耗时约40分钟。3.2 第二步常量折叠预处理控制流还原之前必须先做一轮常量折叠。原因很简单很多状态变量的赋值不是直接写死常量而是包了一层表达式运算比如_state 0x2a ^ 0x0f。如果不先计算后续构建状态转移图时就识别不出目标状态还原出来的逻辑全是错的。我们写了一个简单的常量折叠插件遍历所有二元运算表达式如果左右两边都是字面量就直接计算出结果替换掉原表达式。这一步处理完状态变量的赋值基本都变成了直观的常量值为下一步构建转移图扫清了障碍。3.3 第三步识别平坦化分发器结构接下来要从AST中精准定位控制流平坦化的核心结构。标准的平坦化结构包含三个要素外层while循环、内层switch分发器、独立的状态变量。识别逻辑并不复杂遍历所有WhileStatement节点判断循环体是否只包含一个SwitchStatement检查switch的判别表达式是否为同一个状态变量确认每个case块中都存在对状态变量的赋值用于驱动下一次跳转找到目标节点后我们提取出三个关键信息状态变量名、所有case分支对应的状态值、每个case块内的语句集合。这次遇到的变种是while循环的判断条件不是简单的true而是一个布尔变量本质上还是死循环只是多了一层伪装稍微调整识别逻辑就能匹配上。3.4 第四步构建状态转移图这是整个还原过程最核心的一步。我们需要分析每个case块执行完之后状态变量会被赋值为什么值从而构建出完整的状态转移关系。具体处理逻辑遍历每个case块的最后几条语句查找对状态变量的赋值如果是常量赋值说明是无条件跳转直接记录前驱后继关系如果是条件判断内的赋值说明是分支跳转分别记录两个分支的目标状态如果遇到break/return说明是流程终止标记为结束状态如果出现状态回环标记为循环结构这里又遇到一个定制化变种部分case块里没有直接赋值状态变量而是调用了一个内部子函数来修改状态。静态分析看不到子函数内部逻辑导致转移图断链。解决方案是结合动态调试在每个case入口打印状态值跑一遍真实加密流程把实际的状态转移序列记录下来补全静态分析缺失的分支。3.5 第五步代码块重组与平坦化消除有了完整的状态转移图接下来就是按执行顺序把分散的代码块重新拼接起来恢复成正常的顺序执行与分支结构。处理规则顺序执行A状态无条件跳转到B状态直接将两个代码块按顺序拼接条件分支一个状态分出两个后继状态构造if-else语句包裹对应代码块循环结构状态转移出现回环识别为循环构造对应的while语句终止状态遇到return或break直接保留原始语句这一步完成后原来1400多行的while-switch结构被还原成了120多行的正常代码代码量直接缩减90%以上。虽然变量名还比较简陋但核心逻辑已经完全可读。耗时约1.5小时。3.6 第六步死代码清理与变量重命名控制流还原之后代码里还残留很多无用的变量赋值、永远走不到的死分支、冗余的中间变量。这一步做收尾清理移除对状态变量的所有赋值与引用消除只赋值不使用的冗余变量合并连续的变量声明简化表达式根据代码语义做半语义化重命名比如把_0xa1b2改成sbox、roundKey这类直观名称全部处理完成后用babel/generator生成最终代码再用Prettier做格式化就得到了可读性良好的还原代码。四、核心AES加密逻辑定位与还原反混淆只是手段最终目标是还原加密算法完成接口联调。4.1 快速定位加密函数还原后的代码结构非常清晰通过三个典型特征很快就锁定了AES加密逻辑存在固定的16轮循环结构轮次与AES-128完全对应代码中定义了一张256字节的S盒查表数组数值和标准AES S盒一致有明显的字节替换、行移位、列混合、轮密钥加四段式运算结构顺着调用链往上追溯很快找到了对外暴露的加密入口函数确认整个加密采用AES-128-CBC模式。4.2 加密算法完整拆解经过梳理整个参数加密的完整流程如下业务请求参数集合按键名字典序排序按 keyvalue 格式拼接成明文字符串拼接机构编码与时间戳盐值派生16字节AES密钥生成随机16字节IV向量AES-128-CBC 加密 PKCS7填充IV拼接到密文头部自定义Base64编码输出最终加密参数字符串几个政务场景特有的细节密钥不是固定值由对接方的机构编码官方分配的固定盐值通过一次SHA256截断派生而来IV是随机生成的每次加密都不同最终拼接到密文前16字节一起传输这也是相同参数每次密文都不一样的原因最终编码不是标准Base64字符表做了少量替换去掉了URL特殊字符适合作为GET参数传输参数排序时会自动过滤空值和签名字段顺序必须严格按ASCII码升序4.3 联调一致性验证算法还原的金标准永远是官方测试用例。我们从对方接口文档里取了3组官方测试样本包含不同参数组合、中文参数等场景用还原后的算法逐一加密。初期遇到两个小偏差一是中文参数的编码处理对方默认用UTF-8编码我们一开始误按GBK处理了二是Base64字符表有两个字符顺序不对。调整之后3组样本的输出密文和官方样本完全一致逐字节无偏差接口联调一次通过。五、踩坑实录与效率对比整个过程看似顺畅实际踩了不少定制化混淆的坑很多问题都是通用混淆样本里遇不到的。5.1 印象最深的几个坑坑一解密函数的环境检测陷阱最开始抠出解密函数直接在Node里跑没报错但解密出来的字符串全是乱的以为是抠错了函数反复核对了好几遍。后来单步调试才发现函数内部检测了window对象不存在就会静默切换到错误密钥返回的是假解密结果非常有迷惑性。最后Mock了最小浏览器环境才解决。坑二状态变量间接赋值导致转移图断裂一开始构建的状态转移图总有几个分支连不上还原后的代码逻辑缺块。排查后发现有几个case没有直接赋值状态变量而是调用了一个内部函数间接修改。静态分析看不到函数内部逻辑自然就断了链。最后靠动态调试打日志记录实际状态流转序列才补全了完整的转移图。坑三switch穿透逻辑漏处理有两个case分支是没有break的穿透逻辑初始版本的识别逻辑漏掉了这种情况导致代码块拼接错误还原后的加密结果始终不对。后来对照动态执行的中间值逐轮比对才发现少执行了一段代码。这种定制化的混淆手段不常见但遇到了就很容易卡壳。坑四IV拼在密文头部默认按固定IV解密失败刚还原完算法的时候以为IV是固定值结果解密官方样本全是乱码。折腾了很久才反应过来对方把随机IV放在了密文的前16字节后面才是真正的密文。这个设计本身是标准做法但如果惯性思维以为IV是固定的就很容易栽跟头。5.2 效率对比与耗时拆解我们事后做了一次横向对比统计了纯手动还原和AST自动化还原的耗时差异环节纯手动还原预估AST自动化还原效率提升字符串解密2小时40分钟3倍控制流梳理还原10小时1.5小时6.7倍算法定位与验证3小时1小时3倍总计约15小时约3小时5倍可以看到效率提升最明显的就是控制流还原环节这也是AST自动化最能发挥价值的地方。纯手动梳理状态机非常消耗精力还容易出错而机器处理这种结构化的重复工作天生擅长。六、方法论总结回头看整个过程控制流平坦化的破解并没有什么黑科技本质就是逆向混淆的构造过程对方把线性代码拆成状态机我们就把状态机拼回线性代码。6.1 通用破解流程总结下来面对任何控制流平坦化保护都可以遵循这个通用流程前置清理先做字符串解密、常量折叠、简单死代码移除降低后续分析难度结构识别定位while-switch分发器与状态变量确认平坦化结构构建转移图分析每个代码块的后继关系区分顺序、分支、回环代码重组按转移关系拼接代码块恢复原始控制结构收尾优化清理冗余变量格式化输出语义化重命名逻辑验证用已知样本验证还原后的代码逻辑正确性6.2 几点实战心得第一不要上来就硬啃。先做结构化分析选对工具和路线比闷头逐行读代码效率高得多。第二自动化为主人工为辅。能批量处理的就写插件处理把精力花在工具搞不定的复杂分支和逻辑验证上。全手动还原效率太低全自动化又容易出错两者结合性价比最高。第三边还原边验证。每处理完一层就做一次基础验证不要一口气处理完再排查问题。字符串解密完先验一下常量对不对控制流还原完先跑一下简单用例有问题早发现早调整。第四不要追求完美还原。核心计算路径还原清楚就够了异常分支、边缘逻辑没必要浪费时间。目标是解决实际问题不是做代码考古。合规声明本文所述技术仅用于合法的政务数据对接、接口联调、安全研究与自有系统建设场景。任何技术都有其适用边界读者在实际应用中请严格遵守《网络安全法》《数据安全法》《政务数据共享开放条例》等相关法律法规在授权范围内开展技术工作不得用于非法破解、越权访问、盗取政务数据等违规场景。技术本身是中性的合理使用、守住边界是每个技术从业者的基本职业操守。前端混淆与反混淆的对抗始终在螺旋升级通用混淆器的破解方案越来越成熟定制化加固会越来越多。但底层的思路是相通的理解混淆的原理找到结构化的规律用工程化的手段批量解决问题。相比于死磕某一个具体样本更重要的是建立起一套可复用的反混淆工作流遇到新的混淆变种能快速调整适配这才是AST反混淆真正的价值所在。
