前段时间对接某主流电商平台的公开数据接口对方的核心签名JS做了重度混淆除了常规的字符串加密、变量名混淆之外还启用了控制流平坦化保护。拿到混淆代码的第一观感就是满屏的switch-case和状态变量核心计算逻辑被切割得支离破碎常规阅读根本无法梳理出完整的算法流程。没有急于逐行硬啃我选择了基于AST的自动化反混淆路线用Babel全家桶写了一套针对性的还原插件先做字符串解密再拆解控制流平坦化最后清理死代码与冗余逻辑。从拿到混淆代码到完整还原出AES签名算法前后耗时约3小时还原后的代码可读性大幅提升核心计算路径与原始逻辑100%对齐。本文完整复盘整个反混淆过程从混淆特征识别、工具链选型、AST插件编写到最终算法还原分享一线逆向工程中控制流平坦化的标准化破解思路与实操细节。一、混淆样本初判识别控制流平坦化拿到混淆文件的第一步不是立刻开干而是先做特征分析判断混淆类型与强度选性价比最高的突破路线。1.1 典型特征识别打开目标JS文件扫一眼就能确认是典型的Obfuscator混淆且开启了最高级别的控制流平坦化文件顶部存在大型加密字符串数组配套自执行移位函数与解密方法核心函数内部存在一个外层while(true)循环包裹着巨大的switch语句一个专门的状态变量驱动整个执行流程每个case对应一块原始代码大量无意义的状态跳转与死分支真正有效的逻辑被稀释在大量垃圾代码中变量名、函数名全部为无意义的十六进制命名无任何可读语义简单统计了一下核心签名函数原始逻辑大概只有百余行经过平坦化处理后膨胀到了1200多行代码可读性基本为零。1.2 整体对抗思路控制流平坦化的本质是把线性的、有结构的代码改造成一个状态驱动的分发器。逆向的核心思路就是逆向这个过程识别分发器、提取状态转移关系、重组代码块、恢复原始控制流。原始混淆JS文件第一层字符串解密还原第二层控制流平坦化识别构建状态转移图重组代码块恢复顺序与分支第三层死代码与冗余逻辑清理第四层变量语义化重命名核心算法逻辑提取与验证很多人容易陷入一个误区追求100%完美还原原始代码。实际上对于算法逆向场景我们只需要保证核心计算路径清晰可读、输入输出映射正确即可没必要浪费时间在边缘分支的完美还原上。二、工具链与前置准备工欲善其事必先利其器。AST反混淆的工具链非常成熟核心就是Babel全家桶配合自定义插件完成针对性处理。2.1 核心工具选型babel/parser将JS代码解析为抽象语法树ASTbabel/traverse遍历AST节点实现节点的查找、修改与替换babel/typesAST节点类型判断与构造工具babel/generator将处理后的AST重新生成JS代码Node.js 18.x脚本运行环境配合fs模块做文件读写之所以选择Babel而不是其他AST工具核心原因是生态完善、文档齐全对各种JS语法兼容性最好遇到边缘语法踩坑概率最低。2.2 前置知识储备做AST反混淆不需要精通编译原理但必须掌握三个核心能力能看懂常见AST节点的结构知道WhileStatement、SwitchStatement、AssignmentExpression长什么样会用traverse遍历指定类型的节点能在回调里拿到节点信息与父节点引用会用types构造新的节点替换掉旧的混淆节点实际开发中大部分时间都在查文档、调节点属性真正的核心逻辑代码量并不大。三、分步实战AST还原控制流平坦化整个还原过程分四步走按顺序执行每一步都验证输出确保没有引入逻辑错误。3.1 第一步前置处理——字符串解密控制流还原之前必须先把字符串解密做了。原因很简单状态变量的很多赋值、判断条件都依赖加密字符串的解密结果如果不解密连状态值都读不出来根本没法构建转移图。字符串解密是OB混淆里最成熟的环节标准化的处理流程从混淆代码中提取出字符串数组、移位函数、解密主函数在Node.js沙箱中运行这部分代码得到内存中的解密函数遍历AST将所有解密函数调用节点替换为实际的字符串字面量移除不再被引用的数组与解密函数定义这一步完成后代码里的方法名、属性名、常量字符串全部恢复可读后续分析效率提升一个量级。3.2 第二步识别平坦化结构接下来要从AST中精准定位控制流平坦化的结构。一个标准的平坦化结构包含三个要素外层while循环、内层switch分发器、状态变量。识别逻辑并不复杂遍历所有WhileStatement节点判断循环体是否只包含一个SwitchStatement检查switch的判别表达式是否为同一个状态变量确认每个case块中都存在对状态变量的赋值用于驱动下一次跳转找到目标节点后我们提取出三个关键信息状态变量名、所有case分支对应的状态值、每个case块内的语句集合。3.3 第三步构建状态转移图这是整个还原过程最核心的一步。我们需要分析每个case块执行完之后状态变量会被赋值为什么值从而构建出完整的状态转移关系。初始状态Case 1Case 2Case 3Case 4分支Case 5汇合Case 6结束状态具体处理逻辑遍历每个case块的最后几条语句查找对状态变量的赋值如果是常量赋值说明是无条件跳转直接记录前驱后继关系如果是条件判断内的赋值说明是分支跳转分别记录两个分支的目标状态如果遇到break/return说明是流程终止标记为结束状态这里有个很容易踩的坑状态变量的赋值不一定直接写在case末尾可能藏在几层if嵌套里面甚至可能通过函数调用间接修改。实战中我遇到了3处间接赋值的情况都是靠手动标记补充进去的。3.4 第四步代码块重组与平坦化消除有了完整的状态转移图接下来就是按执行顺序把分散的代码块重新拼接起来恢复成正常的顺序执行与分支结构。处理规则顺序执行A状态无条件跳转到B状态直接将两个代码块按顺序拼接条件分支一个状态分出两个后继状态构造if-else语句包裹对应代码块循环结构状态转移出现回环识别为循环构造对应的while或for语句终止状态遇到return或break直接保留原始语句核心替换逻辑的简化实现如下functionflattenReducer(whileNode){const{stateVar,cases,entryState}extractFlatStructure(whileNode);constgraphbuildStateGraph(cases,stateVar);// 从入口状态开始递归生成还原后的语句列表conststatementsgenerateStatements(entryState,graph,cases);// 用生成的语句替换原来的整个while节点path.replaceWithMultiple(statements);}这一步完成后原来几百行的while-switch结构就被还原成了正常的顺序分支代码代码量直接缩减70%以上。3.5 第五步死代码清理与变量重命名控制流还原之后代码里还残留很多无用的变量赋值、永远走不到的死分支、冗余的中间变量。这一步做收尾清理移除对状态变量的所有赋值与引用消除只赋值不使用的冗余变量合并连续的变量声明简化表达式可选根据代码语义对变量做半语义化重命名提升可读性全部处理完成后用babel/generator生成最终代码再用Prettier做格式化就得到了可读性良好的还原代码。四、核心算法定位与AES逻辑还原反混淆不是目的只是手段。代码还原之后我们的目标是快速定位并验证核心签名算法。4.1 快速定位加密逻辑还原后的代码虽然变量名还比较简陋但结构已经非常清晰。通过几个特征就能快速锁定AES算法出现固定的16轮循环结构代码中存在256个元素的S盒查表数组有明显的列混合、行移位特征运算密钥扩展部分有固定的轮常数Rcon顺着调用链往上追溯很快找到了签名入口函数确认整个签名的核心就是AES-CBC模式加密。4.2 签名算法完整拆解经过梳理整个签名生成的完整流程如下请求参数集合按键名字典序排序按 keyvalue 格式拼接成明文追加固定后缀盐值AES-128-CBC 加密PKCS7 填充处理自定义 Base64 编码输出最终 sign 参数几个关键细节密钥与IV均为固定16字节字符串硬编码在代码中没有动态派生采用AES-128-CBC模式PKCS7填充属于标准AES实现最终编码不是标准Base64字符表做了少量替换直接用标准库解码会出错参数拼接时会自动过滤空值与sign字段本身顺序必须严格按ASCII码升序4.3 一致性验证算法还原的金标准永远是输入输出对齐。我从抓包样本中选取了20组不同场景的真实请求包含商品搜索、详情查询、列表翻页等多种接口用还原后的算法逐一计算签名。初期遇到两个小偏差一是参数排序时中文编码处理不一致二是Base64字符表对应错误。调整之后所有样本输出与原始签名完全一致逐字节无偏差算法还原宣告完成。五、踩坑实录与经验总结整个过程看似顺畅实际踩了不少坑很多细节都是实战中才能遇到的问题。5.1 印象最深的几个坑坑一状态变量不是简单常量赋值一开始默认状态变量都是直接赋值常量结果有几处状态值是通过表达式计算出来的导致转移图构建错误还原后的逻辑完全不对。后来加了常量折叠的前置处理把能计算的表达式先算成常量才解决这个问题。坑二switch中存在fall-through穿透有两个case分支是没有break的穿透逻辑初始版本的识别逻辑漏掉了这种情况导致代码块拼接错误。这种混淆手段不常见但遇到了就很容易卡壳最后是靠对比运行时的中间变量才定位到问题。坑三还原后引入了作用域问题直接拼接代码块的时候不同case里声明了同名变量合并后出现变量覆盖导致逻辑错误。后来在合并前做了变量重命名给每个块的局部变量加唯一后缀才彻底解决。坑四AES填充细节踩坑一开始默认是PKCS5填充结果明文长度刚好是16字节倍数的时候签名总是对不上。查了很久才发现是PKCS7填充即使数据长度对齐也要补一整块填充。加密算法的细节差一点结果就完全不对。5.2 效率提升的几点心得第一不要追求完美还原。核心计算路径还原清楚就够了异常分支、边缘逻辑没必要浪费时间。算法逆向的目标是拿到正确的输入输出映射不是做代码复原。第二自动化为主人工为辅。能批量处理的就写插件处理把精力花在工具搞不定的复杂分支和逻辑验证上。全手动还原效率太低全自动化又容易出错两者结合性价比最高。第三边还原边验证。每处理完一层就做一次基础验证不要一口气处理完再排查问题。字符串解密完先验一下常量对不对控制流还原完先跑一下简单用例有问题早发现早调整。5.3 控制流平坦化的通用破解思路总结下来面对任何控制流平坦化保护都可以遵循这个通用流程先做前置清理字符串解密、常量折叠、简单死代码移除识别平坦化结构定位while-switch分发器与状态变量构建状态转移图分析每个块的后继关系区分顺序、分支、回环代码重组按转移关系拼接代码块恢复原始控制结构收尾优化清理冗余变量格式化输出语义化重命名逻辑验证用已知样本验证还原后的代码逻辑正确性合规声明本文所述技术仅用于合法的安全研究、合规性测试与自有系统接口对接场景。任何技术都有其适用边界读者在实际应用中请严格遵守《网络安全法》《数据安全法》《个人信息保护法》等相关法律法规尊重平台方的服务协议与知识产权不得用于非法破解、恶意攻击、盗取数据等违规场景。技术本身是中性的合理使用、守住边界是每个从业者的基本职业素养。前端混淆与反混淆的对抗始终在螺旋升级今天的自动化还原方案明天可能就会被新的混淆手段绕过。但底层的思路是相通的理解混淆的原理找到结构化的规律用工程化的手段批量解决问题。相比于死磕某一个具体样本更重要的是建立起一套可复用的反混淆工作流遇到新的混淆变种能快速调整适配这才是AST反混淆真正的价值所在。
