JS混淆逆向实战：从js_fuck到可调试代码的七步还原法

1. 项目概述这不是“破解”而是对前端加密逻辑的逆向工程实践“猿人学题库十四题——js_fuck核心代码加密”这个标题乍看像一道CTF题目或爬虫对抗场景里的典型挑战但它的实际价值远不止于“做题”。它指向一个在当前Web生态中高频出现、却极少被系统拆解的技术切口JavaScript层面对抗性混淆与动态执行逻辑的落地实现路径。我接触过大量类似需求——某高校实验室在做网页行为分析教学案例时需要还原加密流程某电商风控团队想理解竞品登录态生成机制甚至有独立开发者为调试自家SPA应用的防调试逻辑都曾反复翻阅这类题目的解法。它们共同的核心并非“绕过”或“突破”而是在不依赖黑盒工具的前提下用可验证、可复现、可教学的方式把一段被高强度混淆、多层动态拼接、运行时自毁的JS代码还原成人类可读、可调试、可修改的逻辑链路。关键词里没有出现“反混淆”“AST解析”“AST还原”这些术语但它们恰恰是本题的底层支柱。所谓“js_fuck”不是情绪化表达而是社区对一类特定混淆风格的戏称变量名全为单字符a/b/c、字符串全部Base64或异或加密、控制流扁平化Control Flow Flattening、关键函数体被拆成数组eval动态执行、甚至插入无意义的死代码干扰静态分析。这种混淆已不是为了防小白而是为提高自动化逆向的成本阈值。而“题库十四题”的定位很关键——它意味着这不是孤立样本而是经过筛选的、具备教学代表性的典型模式它大概率包含字符串解密函数的定位与提取、控制流扁平化的结构识别、eval执行体的上下文捕获、以及最终逻辑的语义等价还原。适合三类人深度参考一是刚接触前端逆向的新手需要从“看得见”到“理得清”二是爬虫工程师需稳定获取加密参数而不依赖不断更新的黑盒脚本三是安全研究人员想验证某混淆器的实际防护强度。它解决的不是“能不能拿到数据”而是“能不能在变化中持续、可控、低维护地拿到数据”。2. 内容整体设计与思路拆解为什么必须放弃“直接扣代码”的懒办法很多人看到这类题的第一反应是打开浏览器开发者工具断点停在加密函数调用处然后手动复制堆栈里解密后的明文。这方法快但错得离谱——它完全违背了题目的训练目标也毫无工程价值。我试过用这种方式帮某公司临时抓取数据结果两周后对方升级混淆器所有“扣下来”的代码全部失效还得从头再来。真正的解法必须建立在可推演、可验证、可迁移的基础上。整个思路拆解下来核心就三点定位、还原、验证缺一不可。首先是定位。你不能靠肉眼在5000行混淆代码里找“加密函数”那效率太低且易错。必须借助静态特征比如搜索atob(、btoa(、String.fromCharCode(、eval(、Function(等动态执行入口再结合字符串常量特征如/^[A-Za-z0-9/]*{0,2}$/匹配Base64编码串或者用AST解析器扫描所有CallExpression节点筛选出参数含Array字面量且callee为eval或Function的调用。我常用一个Python小脚本预处理先用esprima解析源码生成AST再遍历所有Literal节点提取长度30且含、^、等运算符的字符串这些大概率是加密后的密钥或密文。定位不是目的而是为后续还原提供锚点。其次是还原。这是最耗精力也最体现功力的部分。常见误区是试图“美化”整段代码——给变量重命名、格式化缩进。这没用因为混淆器生成的代码本身逻辑就是破碎的。真正有效的还原是逻辑等价映射把_0x1234[push](_0x5678 ^ 0x9abc)这样的表达式识别为“对密钥数组进行异或解密”并提取出0x5678和0x9abc这两个真实值把while(true){switch(_0xdef0){case 0:...break;case 1:...break;}}这样的控制流扁平化结构用图算法识别出真实的执行顺序重构为if-else或switch-case原生结构。这里的关键在于还原的目标不是“好看”而是“能单步调试”。比如我把所有eval调用替换成console.log输出其参数字符串再手动复制到新标签页执行就能确认解密结果是否正确——这一步验证比任何自动化工具都可靠。最后是验证。很多教程到这里就结束了但实际项目中验证才是生死线。我给自己定的硬标准是还原后的JS代码必须能在Node.js环境里独立运行输入原始密文输出与浏览器中完全一致的明文且执行时间误差在±5ms内。为什么强调Node.js因为浏览器环境有window、document等全局对象干扰而Node.js是纯净沙箱能排除环境差异带来的误判。验证过程要覆盖边界空字符串、超长字符串、特殊Unicode字符如\u202E这些往往是混淆器测试用例里故意埋的坑。有一次我还原完以为大功告成结果用\u202E测试时发现解密函数内部用了split()而该字符在JS中会被视为两个码元导致解密错位——这个坑只有通过系统化验证才能暴露。这套“定位-还原-验证”闭环不是凭空设计的。它源于我过去三年处理的37个同类项目的经验沉淀。其中21个来自电商登录态分析8个来自金融产品风险评分接口剩下8个是教育平台的题库防爬逻辑。所有成功案例无一例外都严格遵循这个流程。跳过任何一环后续都会付出数倍代价。3. 核心细节解析与实操要点从混淆特征到可执行代码的七步转化把“js_fuck”这种高强度混淆还原成可用代码不是玄学而是一套可拆解、可重复的机械操作。我把它浓缩为七个关键步骤每一步都有明确的输入、输出和避坑点。这些步骤不是线性流程而是螺旋上升前一步的输出可能成为后一步的输入依据需要反复迭代。下面以猿人学题库十四题的典型代码片段为例为合规此处使用虚构但符合特征的示例var _0x1234 [\x68\x74\x74\x70\x73\x3a\x2f\x2f, \x61\x70\x69\x2e\x65\x78\x61\x6d\x70\x6c\x65\x2e\x63\x6f\x6d, \x2f\x6c\x6f\x67\x69\x6e, \x47\x45\x54, \x63\x6f\x6e\x74\x65\x6e\x74\x2d\x74\x79\x70\x65, \x61\x70\x70\x6c\x69\x63\x61\x74\x69\x6f\x6e\x2f\x6a\x73\x6f\x6e]; var _0x5678 function(_0x9abc, _0xdef0) { var _0x123456 _0x1234[_0x9abc]; return _0x123456; }; var _0x7890 _0x5678(0, a) _0x5678(1, b) _0x5678(2, c); var _0xabc1 _0x5678(3, d); var _0xdef2 {}; _def2[_0x5678(4, e)] _0x5678(5, f);3.1 步骤一字符串解密与常量池提取混淆代码里所有有意义的字符串URL、HTTP方法、Header名几乎都被编码。常见编码方式有三种Hex\x68\x74...、Unicode\u0068\u0074...、Base64YXBpLmV4YW1wbGUuY29t。第一步必须彻底清洗这些。不要用在线解码工具——它们无法批量处理且无法嵌入自动化流程。我写了一个Python函数能自动识别并解码import re import base64 def decode_string_literal(s): # 解码 Hex: \x68\x74\x74\x70 - http s re.sub(r\\x([0-9a-fA-F]{2}), lambda m: chr(int(m.group(1), 16)), s) # 解码 Unicode: \u0068\u0074 - ht s re.sub(r\\u([0-9a-fA-F]{4}), lambda m: chr(int(m.group(1), 16)), s) # 解码 Base64: YXBp - api try: if re.match(r^[A-Za-z0-9/]*{0,2}$, s) and len(s) % 4 0: decoded base64.b64decode(s).decode(utf-8) if len(decoded) 2: # 过滤掉单字符解码结果 return decoded except: pass return s # 应用到整个源码 cleaned_code re.sub(r([^]*), lambda m: f{decode_string_literal(m.group(1))}, original_code)提示此步骤必须在AST解析前完成。因为AST解析器会把\x68当作一个字符处理而非转义序列导致后续分析错误。我吃过这个亏——有次忘了先解码AST里_0x1234数组的元素全是乱码浪费了三小时才定位到问题。3.2 步骤二变量映射表构建与作用域分析混淆器喜欢用_0x1234、_0x5678这类名字但它们不是随机的。通常_0x后的十六进制数对应原始字符串的哈希值如https://的MD5前4位是1234。但这只是辅助真正关键的是构建变量到值的映射关系。观察上面的示例_0x5678是一个函数它从_0x1234数组里按索引取值。这意味着_0x1234是常量池_0x5678是访问器。我的做法是用AST遍历所有VariableDeclarator节点识别出数组字面量赋值_0x1234 [..., ...]然后记录其变量名和内容再找到所有调用该变量的CallExpression提取参数中的索引值如_0x5678(0, ...)中的0建立_0x5678(0)→https://的映射。这一步完成后代码里所有_0x5678(0)都可以安全替换成https://。注意必须分析作用域有些混淆器会用let或const声明同名变量在不同块级作用域里值完全不同。我用esprima的scope分析功能为每个变量绑定其声明所在的作用域ID避免跨作用域误替换。3.3 步骤三控制流扁平化识别与结构重建这是最烧脑的环节。控制流扁平化会让代码变成一个巨大的while(true){switch(state){case 0: ... state1; break; case 1: ... state2; break;}}结构。人工看根本理不清。我的解法是把switch的case值当作图的节点把statexxx当作有向边构建控制流图CFG。然后用Tarjan算法找强连通分量SCC识别出循环体再用拓扑排序确定线性执行顺序。具体到代码层面我写了一个AST转换器// 伪代码逻辑 function deobfuscateControlFlow(ast) { // 1. 找到最外层的 while(true) { switch(...) } const whileNode findWhileTrueSwitch(ast); const switchNode whileNode.body.body[0].consequent; // 2. 提取所有 case 分支构建 map: caseValue - [statements] const caseMap buildCaseMap(switchNode); // 3. 遍历每个 case 的 statements找 statexxx 赋值 const edges []; for (const [caseVal, stmts] of Object.entries(caseMap)) { const nextState findNextStateAssignment(stmts); if (nextState ! null) { edges.push({ from: caseVal, to: nextState }); } } // 4. 构建图排序生成 if-else 链 const sortedCases topologicalSort(edges); return generateIfElseChain(sortedCases, caseMap); }实测下来这套方法对猿人学题库十四题的控制流还原准确率在92%以上。剩下的8%通常是混淆器插入的虚假case分支死代码需要结合动态执行日志来过滤——在浏览器里加断点记录真实执行过的case值只保留这些。3.4 步骤四eval/Function动态执行体捕获与固化混淆代码里真正的加密逻辑往往藏在eval(...)或Function(return ...)()里。直接执行eval风险高可能触发恶意代码且无法调试。我的策略是拦截并记录。在Chrome DevTools里我在Sources面板的右侧“Snippets”里新建一个脚本// 拦截 eval const originalEval window.eval; window.eval function(code) { console.log([EVAL INTERCEPTED], code.substring(0, 200) ...); // 这里可以加断点或把code保存到全局变量 window.lastEvalCode code; return originalEval.call(this, code); }; // 拦截 Function constructor const originalFunction window.Function; window.Function function(...args) { const code args.slice(-1)[0]; console.log([FUNCTION INTERCEPTED], code.substring(0, 200) ...); window.lastFunctionCode code; return originalFunction.apply(this, args); };执行加密函数后window.lastEvalCode里就是真实的、未混淆的JS逻辑。把它复制出来就是还原工作的核心素材。注意lastEvalCode里的变量名还是混淆的但此时它已经脱离了控制流扁平化和字符串编码的包裹只剩下最基础的变量重命名问题解决难度直线下降。3.5 步骤五异或/位运算密钥提取与数学验证很多加密函数用a ^ b、a 2、a 3等位运算做轻量级混淆。关键是要找出b、2、3这些魔法数字的真实含义。我的方法是构造最小化测试用例用数学反推。比如如果解密函数是function decrypt(cipher) { return cipher ^ 0x12345678; }那么我准备两个已知明文-密文对plain1a,cipher10x98765432plain2b,cipher20x98765433。计算cipher1 ^ plain1.charCodeAt(0)和cipher2 ^ plain2.charCodeAt(0)如果结果一致都是0x12345678就验证了密钥。这比看代码猜数字靠谱十倍。我有个Excel模板输入几组明密文对自动计算异或密钥、加法偏移、位移位数5分钟内就能锁定。3.6 步骤六函数内联与冗余代码清理混淆器会插入大量无用代码如var _0x1234 1; _0x1234 _0x1234 0;或if (true) { ... }。这些不干扰逻辑但影响可读性。我用babel/core和babel/preset-env做AST转换编写插件自动清理移除恒真/恒假条件判断合并连续的变量声明和赋值将a b; c a;简化为c b;替换_0x1234[push]为_0x1234.push属性访问转点号。实操心得不要追求100%自动化清理。有些“冗余”代码其实是混淆器的反调试陷阱比如if (window.location.href.indexOf(debug) -1) throw new Error();。我的原则是只清理被AST分析确认为“无副作用”的代码不确定的留着用注释标出// SUSPICIOUS - DO NOT REMOVE。3.7 步骤七语义等价性验证与Node.js沙箱测试所有还原工作完成后必须在Node.js里跑通。我创建一个test.js// test.js const fs require(fs); const vm require(vm); // 加载还原后的代码 const deobfuscatedCode fs.readFileSync(./deobfuscated.js, utf-8); // 创建沙箱模拟浏览器全局对象 const sandbox { console: console, Buffer: Buffer, // 不注入 window/document强制代码不依赖浏览器API }; // 执行还原代码暴露加密函数 vm.createContext(sandbox); vm.runInContext(deobfuscatedCode, sandbox); // 测试用例 const testCases [ { input: aGVsbG8, expected: hello }, { input: d29ybGQ, expected: world } ]; testCases.forEach(({ input, expected }, i) { try { const result sandbox.decrypt(input); // 假设还原后函数叫decrypt if (result expected) { console.log(✅ Test ${i1} passed); } else { console.log(❌ Test ${i1} failed: got ${result}, expected ${expected}); } } catch (e) { console.log( Test ${i1} error: ${e.message}); } });这个测试框架救了我无数次。有次我过度优化把一个setTimeout回调里的逻辑提前执行导致时序错乱测试直接报错——这比上线后出问题早发现三天。4. 实操过程与核心环节实现从题库代码到可复用模块的完整流水线现在我们把前面所有步骤串起来走一遍猿人学题库十四题的真实还原流水线。整个过程我用一台干净的Ubuntu 22.04虚拟机完成确保环境纯净无缓存干扰。所有工具均为开源无需任何商业授权。4.1 环境准备与工具链安装首先初始化一个Node.js项目安装必需的AST处理库mkdir yrenxue-14 cd yrenxue-14 npm init -y npm install esprima babel/core babel/preset-env babel/plugin-transform-runtime babel-plugin-transform-remove-console npm install -D babel/cli同时安装Python3及依赖用于预处理sudo apt update sudo apt install python3-pip pip3 install esprima-python requests beautifulsoup4注意不要用npm install esprima那个是旧版不支持ES2022语法。必须用esprima-python做Python端解析因为它的AST结构更清晰便于写分析脚本。我对比过acorn、meriyahesprima-python在处理混淆代码的容错性上最好——它能把语法错误的代码也解析出部分AST这对逆向至关重要。4.2 源码获取与初步清洗题库页面的JS代码通常在HTML里内联或通过script src...加载。我用curl和BeautifulSoup提取# fetch_source.py import requests from bs4 import BeautifulSoup import re url https://example-yrenxue.com/question/14 # 替换为真实URL response requests.get(url) soup BeautifulSoup(response.text, html.parser) # 提取内联script inline_scripts soup.find_all(script) for script in inline_scripts: if script.string and js_fuck in script.string[:1000]: # 关键词定位 with open(raw.js, w, encodingutf-8) as f: f.write(script.string) break # 提取外部JS external_scripts soup.find_all(script, srcTrue) for script in external_scripts: if fuck in script[src]: js_url script[src] if script[src].startswith(http) else url.rsplit(/, 1)[0] / script[src] js_content requests.get(js_url).text with open(raw.js, w, encodingutf-8) as f: f.write(js_content) break运行后得到raw.js大小约127KB。用wc -l raw.js查看行数3821行。接下来用前面提到的decode_string_literal函数清洗python3 decode_strings.py raw.js cleaned.jscleaned.js行数变为3210行减少了611行说明有大量字符串被成功解码。用grep -n https:// cleaned.js确认已出现明文URL。4.3 AST解析与常量池提取用esprima-python解析cleaned.js提取所有数组字面量# extract_constants.py import esprima import json with open(cleaned.js, r, encodingutf-8) as f: code f.read() tree esprima.parseScript(code) def find_array_declarations(node): if hasattr(node, type) and node.type VariableDeclarator: if hasattr(node.init, type) and node.init.type ArrayExpression: # 获取变量名 name node.id.name # 获取数组元素字符串字面量 elements [] for elem in node.init.elements: if hasattr(elem, type) and elem.type Literal and isinstance(elem.value, str): elements.append(elem.value) if elements: print(fFound constant array: {name} {elements[:3]}...) # 只打印前3个 return {name: elements} return None # 遍历AST constants {} for node in tree.body: result find_array_declarations(node) if result: constants.update(result) with open(constants.json, w, encodingutf-8) as f: json.dump(constants, f, indent2, ensure_asciiFalse)运行后生成constants.json内容类似{ _0x1234: [https://, api.example.com, /login, GET, content-type, application/json], _0x5678: [a, b, c, d, e, f] }这就是我们的“密钥本”。下一步用babel/core做AST转换把所有_0x1234[0]替换成https://。4.4 Babel插件编写与自动化替换创建babel.config.js// babel.config.js module.exports { presets: [babel/preset-env], plugins: [ ./plugins/replace-constants ] };编写插件plugins/replace-constants.js// plugins/replace-constants.js const fs require(fs); const constants JSON.parse(fs.readFileSync(./constants.json, utf-8)); module.exports function({ types: t }) { return { visitor: { MemberExpression(path) { const { object, property } path.node; // 匹配 _0x1234[0] 这种模式 if (t.isIdentifier(object) t.isNumericLiteral(property)) { const arrayName object.name; const index property.value; if (constants[arrayName] constants[arrayName][index] ! undefined) { // 替换为字符串字面量 path.replaceWith(t.stringLiteral(constants[arrayName][index])); } } } } }; };运行Babel转换npx babel cleaned.js --out-file step1-replaced.jsstep1-replaced.js里所有_0x1234[0]都变成了https://代码可读性大幅提升。4.5 控制流扁平化还原与eval拦截此时代码里仍有大量while(true){switch(...){...}}。我用前面提到的deobfuscateControlFlow函数已封装为CLI工具处理npx control-flow-deobfuscator step1-replaced.js step2-cfg.jsstep2-cfg.js里控制流已重构为清晰的if-else链。接着启动Chrome打开题库页面在Console里粘贴eval拦截脚本点击触发加密按钮。在Console里找到[EVAL INTERCEPTED]日志复制出最长的那个code字符串保存为eval-body.js。4.6 动态逻辑整合与函数封装eval-body.js内容类似function encrypt(data) { var key my_secret_key; var result ; for (var i 0; i data.length; i) { result String.fromCharCode(data.charCodeAt(i) ^ key.charCodeAt(i % key.length)); } return btoa(result); }把它和前面还原的step2-cfg.js合并封装成一个标准模块// final-module.js // 导出加密/解密函数 function encrypt(data) { // ... 上面的逻辑 } function decrypt(cipher) { const decoded atob(cipher); const key my_secret_key; let result ; for (let i 0; i decoded.length; i) { result String.fromCharCode(decoded.charCodeAt(i) ^ key.charCodeAt(i % key.length)); } return result; } // 兼容CommonJS和ESM if (typeof module ! undefined module.exports) { module.exports { encrypt, decrypt }; } else if (typeof define function define.amd) { define(() ({ encrypt, decrypt })); }4.7 Node.js沙箱测试与CI集成最后运行测试node test.js输出✅ Test 1 passed ✅ Test 2 passed ✅ Test 3 passed至此整个还原流程完成。为保障长期可用我把所有步骤写成Makefile支持一键重跑# Makefile .PHONY: all clean test all: cleaned.js step1-replaced.js step2-cfg.js final-module.js test cleaned.js: raw.js python3 decode_strings.py raw.js $ step1-replaced.js: cleaned.js constants.json npx babel $ --out-file $ step2-cfg.js: step1-replaced.js npx control-flow-deobfuscator $ $ final-module.js: step2-cfg.js eval-body.js cat $^ $ test: final-module.js node test.js clean: rm -f *.js *.json每次题库更新只需make clean make5分钟内获得新版本模块。这个流水线我已在三个不同客户的项目中复用平均节省87%的逆向时间。5. 常见问题与排查技巧实录那些文档里不会写的血泪教训在还原猿人学题库十四题的过程中我踩过不少坑。有些是技术难点有些是思维盲区更多是环境和工具的坑。我把它们整理成速查表附上真实发生的时间、现象、根因和解决方案。这些经验比任何理论都珍贵。问题现象发生时间根因分析解决方案实操心得还原后代码在Node.js里报ReferenceError: window is not defined第1次测试代码里有window.atob调用而Node.js无window对象在test.js沙箱里注入global.window global;或全局替换window.atob为atob别急着改代码先用grep -n window\. final-module.js定位所有window.调用统一处理。我后来写了个Babel插件自动把window.xxx转成global.xxx或直接xxx。eval拦截脚本没生效Console里看不到[EVAL INTERCEPTED]第3次尝试目标代码用了Function(return ...)()而非eval()而我的拦截只覆盖了eval补充拦截Function构造函数代码见3.4节。另外有些混淆器会用self.eval或this.eval绕过需一并拦截拦截脚本要放在所有目标JS之前执行。用script标签插入时加defer属性用DevTools Snippets时确保在页面加载完成后再运行。控制流还原后if-else链里出现if (false) { ... }但逻辑不对第7次迭代混淆器插入了“死代码分支”用于干扰CFG分析而我的图算法没过滤掉在topologicalSort前增加动态执行验证用Puppeteer启动无头Chrome执行原始代码记录真实state值变化只保留这些state对应的分支这是最可靠的过滤方式。我写了个小脚本自动启动Puppeteer注入console.log(STATE:, state)到switch里抓取日志。比纯静态分析准得多。btoa解码报错InvalidCharacterError第12次测试输入字符串含Unicode字符如中文btoa只支持Latin-1需先转成UTF-8字节数组用TextEncoder编码const utf8Bytes new TextEncoder().encode(str); const base64 btoa(String.fromCharCode(...utf8Bytes));这个坑太经典。所有涉及btoa/atob的还原必须检查输入是否为纯ASCII。我现在的标准流程是在decrypt函数开头加console.log(INPUT BYTES:, new TextEncoder().encode(input));一眼看出字节长度。还原后的encrypt函数输出与浏览器不一致差几个字符第19次交付前混淆代码里用了Date.now()生成随机盐值而Node.js里执行时间不同找到盐值生成位置用固定值替换如Math.random()→0.123456Date.now()→1678886400000时间相关函数是最大陷阱。我的做法是在Chrome里断点记下Date.now()的真实返回值然后在Node.js测试里用jest.useFakeTimers().setSystemTime(1678886400000)模拟。make all时报错SyntaxError: Unexpected token exportCI部署时babel/preset-env默认不处理ESM语法而某些混淆器生成的代码用了export在babel.config.js里添加targets: { node: current }并确保.babelrc里有modules: commonjsCI环境Node.js版本可能较老。用nvm use 18切换到LTS版本再运行。别信“最新版最好”LTS版最稳。除了这些具体问题还有几个贯穿始终的通用技巧是我从37个项目里总结出来的永远保留原始文件副本我有一个/archive目录每次处理前用cp raw.js archive/raw-$(date %Y%m%d-%H%M%S).js备份。有次误操作把cleaned.js覆盖了靠备份5分钟就恢复。用Git做版本控制但粒度要细不是一天一commit而是一步一commit。git commit -m step1: string decode、git commit -m step2: constant replace。这样回滚精准不怕搞砸。测试用例要覆盖“边界中的边界”除了常规字符串一定要加空字符串、单字符a、超长字符串10MB、含\0的字符串、emoji‍。有次客户数据里有emoji还原代码崩溃就是因为没测这个。文档比代码重要每完成一个步骤在README.md里写清楚输入是什么、输出是什么、用了什么命令、耗时多久、遇到什么问题。这个文档半年后你自己看都感激。最后分享一个独家技巧用VS Code的“Compare Files”功能对比还原前后代码。把raw.js和final-module.js并排打开用CtrlShiftP→