做游戏安全、爬虫逆向或者Web防护研究的朋友一定遇到过这种“绝望时刻”F12打开某个游戏平台的登录或支付接口发现核心校验逻辑根本不在正常的JS函数里而是被塞进了一个巨大的switch-case分发器中。变量名全是_0x4a2c没有正常的函数调用栈甚至连字符串都是运行时动态解码的。恭喜你你撞上了JSVMJavaScript Virtual Machine虚拟机保护。这不是普通的代码混淆而是一种指令级翻译。攻击者或保护方案提供商把原始的JS逻辑编译成了一套自定义的字节码指令集再用一个JS写的“虚拟CPU”来解释执行。传统的de4js、JSNice在这种保护面前基本失效——因为它们还原的只是“虚拟机解释器”本身而不是你真正关心的业务逻辑。今天这篇不讲虚的直接以某游戏平台签名校验为例拆解如何从字节码层面还原JSVM保护把加密逻辑从“黑盒”变成可读的原生代码。一、先认清敌人JSVM和普通混淆的本质区别在动手之前必须建立一个关键认知JSVM不是混淆是编译。对比维度普通混淆 (Obfuscation)JSVM虚拟机保护本质语法等价变换AST结构不变指令级翻译生成自定义字节码执行方式浏览器原生JS引擎直接执行自研解释器循环分发字节码还原目标恢复原始源码结构反编译字节码→重建原生逻辑工具链de4js / JSNice / Prettier自定义反编译器 动态调试难度等级⭐⭐⭐⭐⭐⭐⭐⭐核心判断标准如果你在源码中看到一个大数组存放着数字序列配合一个while(true) switch(dispatcher)的结构且所有业务运算都通过数组索引和位操作完成——这就是JSVM的典型特征。那个大数组就是字节码段switch里的case就是虚拟指令实现。二、逆向四步法从字节码提取到逻辑重建下面以某游戏平台请求签名生成为例演示完整的JSVM逆向流程。第一步定位虚拟机三要素任何JSVM都由三个核心组件构成找到它们就找到了突破口字节码数组Code Array通常是一个Uint8Array或普通数组存放编译后的指令序列分发器Dispatcherwhile(true) { switch(opcode) { ... } }结构负责读取并执行指令虚拟寄存器/栈Virtual Stack用于存储中间计算结果通常是另一个数组实战技巧在Chrome DevTools的Sources面板用正则搜索case\s\d:密度最高的函数大概率就是分发器入口。字节码数组通常在分发器函数的闭包变量或模块顶层定义。【JSVM架构示意图】 ┌─────────────────────────────────────┐ │ 原始JS业务逻辑 │ │ sign md5(url ts secret) │ └──────────────┬──────────────────────┘ │ JSVM编译器 ▼ ┌─────────────────────────────────────┐ │ 字节码: [0x01, 0x03, 0x0A, ...] │ ← Code Array ├─────────────────────────────────────┤ │ while(true) { │ │ op code[pc]; │ ← Dispatcher │ switch(op) { │ │ case 0x01: stack.push(...) │ ← Virtual Stack │ case 0x03: astack.pop();... │ │ case 0x0A: call_native(...) │ │ } │ │ } │ └─────────────────────────────────────┘第二步导出字节码 构建指令映射表这是最关键的一步。你需要知道每个opcode对应什么操作。方法A静态分析分发器逐个阅读switch-case手动记录opcode → 语义的映射。比如0x01: PUSH_IMMEDIATE压入立即数0x03: ADD栈顶两元素相加0x0A: CALL_NATIVE调用外部原生函数0x1F: XOR异或运算方法B动态Trace推荐在分发器的switch入口处插桩hook住op变量和虚拟栈状态触发一次签名请求导出完整的执行trace。然后对trace做频次统计和模式匹配自动推断指令语义。实战经验很多JSVM会把字符串、常量单独存放在一个“常量池”数组中字节码里的索引指向的是常量池而非直接值。务必同时导出常量池否则反编译出来的代码全是数字无法理解。第三步编写反编译器字节码→伪代码有了指令映射表和字节码序列就可以写反编译器了。不需要做得很完美目标是生成可读的伪代码而非可执行的JS。核心思路模拟虚拟栈的行为将字节码序列转换为等价的表达式树或三地址码。# 伪代码示例简单的栈式反编译器核心逻辑defdecompile(bytecode,const_pool):pc0output[]whilepclen(bytecode):opbytecode[pc]ifop0x01:# PUSHvalconst_pool[bytecode[pc1]]output.append(fpush({val}))pc2elifop0x03:# ADDoutput.append(add(pop(), pop()))pc1elifop0x0A:# CALL_NATIVEfunc_idxbytecode[pc1]output.append(fcall(native_funcs[{func_idx}]))pc2# ... 其他指令returnoutput这一步的输出可能长这样push(const[12]) // https://api.game.com/sign push(reg[3]) // timestamp add() // url ts push(const[45]) // secret_key xor() // (urlts) ^ secret call(md5) // md5(...) store(reg[7]) // sign result虽然粗糙但加密逻辑已经清晰可见。第四步验证与重构反编译出的伪代码需要验证正确性。验证方法在原始JSVM环境中对相同输入执行签名对比输出是否与你的伪代码推导一致。如果不一致说明指令映射表有误或遗漏了某些隐式操作如隐式类型转换、溢出处理。验证通过后就可以将伪代码重写为干净的原生JS替换掉原有的JSVM调用完成最终的还原。三、踩坑预警JSVM逆向的三个深水区指令编码动态化高级JSVM每次加载时opcode含义会变通过一个shuffle数组重映射。解决方案必须先还原shuffle算法或在运行时动态捕获映射关系。嵌套虚拟机解释器本身也被另一层VM保护。这种情况需要先脱外层VM再分析内层。通常需要结合AST去平坦化和动态dump。环境绑定检测字节码执行过程中会检查window.navigator、canvas指纹等环境特征不满足则返回错误签名。必须在Node.js或Puppeteer中补全环境或在浏览器中绕过检测后再trace。【JSVM逆向决策流程图】 发现疑似JSVM保护 ↓ 能否定位三要素(字节码/分发器/栈)? ──否──→ AST去平坦化 / 动态Dump ↓ 是 opcode是否动态编码? ──是──→ 还原Shuffle算法 / 运行时Hook ↓ 否 构建指令映射表(静态/动态Trace) ↓ 编写反编译器 → 生成伪代码 ↓ 输入输出验证 ──失败──→ 修正映射表 / 检查环境检测 ↓ 成功 ✅ 重建原生加密逻辑四、写在最后逆向JSVM的真正价值很多人觉得JSVM逆向耗时耗力不如直接Hook拿结果。这话没错但只适用于“一次性任务”。如果你需要长期稳定地对接某个平台、需要理解其风控策略的变化、或者在做安全审计需要评估保护强度——那么指令级还原是唯一可靠的路径。Hook只能拿到“是什么”反编译才能告诉你“为什么”和“怎么变的”。给准备入手JSVM逆向的朋友三个建议先从开源JSVM练手如JSMerger、Bytenode、obfuscator-io的VM选项理解原理后再碰商业保护。建立自己的指令识别模板库不同厂商的JSVM指令集有共性积累多了可以半自动化识别。永远保留动态调试作为兜底静态反编译不可能100%覆盖遇到复杂分支时回到DevTools里单步跟踪虚拟栈是最可靠的验证手段。JSVM保护看似铜墙铁壁但它终究是在JS引擎上跑的“软件模拟”。只要是软件就有迹可循。耐心拆解你会发现那些神秘的字节码背后不过是开发者精心包装过的、你早已熟悉的加密逻辑而已。本文所述技术仅供安全研究、漏洞分析及合法授权测试使用。未经授权对第三方系统进行逆向工程可能违反相关法律法规及服务条款请严格遵守法律底线尊重知识产权。
别硬啃混淆了：JSVM虚拟机保护逆向，从字节码到原生逻辑的还原实战
做游戏安全、爬虫逆向或者Web防护研究的朋友一定遇到过这种“绝望时刻”F12打开某个游戏平台的登录或支付接口发现核心校验逻辑根本不在正常的JS函数里而是被塞进了一个巨大的switch-case分发器中。变量名全是_0x4a2c没有正常的函数调用栈甚至连字符串都是运行时动态解码的。恭喜你你撞上了JSVMJavaScript Virtual Machine虚拟机保护。这不是普通的代码混淆而是一种指令级翻译。攻击者或保护方案提供商把原始的JS逻辑编译成了一套自定义的字节码指令集再用一个JS写的“虚拟CPU”来解释执行。传统的de4js、JSNice在这种保护面前基本失效——因为它们还原的只是“虚拟机解释器”本身而不是你真正关心的业务逻辑。今天这篇不讲虚的直接以某游戏平台签名校验为例拆解如何从字节码层面还原JSVM保护把加密逻辑从“黑盒”变成可读的原生代码。一、先认清敌人JSVM和普通混淆的本质区别在动手之前必须建立一个关键认知JSVM不是混淆是编译。对比维度普通混淆 (Obfuscation)JSVM虚拟机保护本质语法等价变换AST结构不变指令级翻译生成自定义字节码执行方式浏览器原生JS引擎直接执行自研解释器循环分发字节码还原目标恢复原始源码结构反编译字节码→重建原生逻辑工具链de4js / JSNice / Prettier自定义反编译器 动态调试难度等级⭐⭐⭐⭐⭐⭐⭐⭐核心判断标准如果你在源码中看到一个大数组存放着数字序列配合一个while(true) switch(dispatcher)的结构且所有业务运算都通过数组索引和位操作完成——这就是JSVM的典型特征。那个大数组就是字节码段switch里的case就是虚拟指令实现。二、逆向四步法从字节码提取到逻辑重建下面以某游戏平台请求签名生成为例演示完整的JSVM逆向流程。第一步定位虚拟机三要素任何JSVM都由三个核心组件构成找到它们就找到了突破口字节码数组Code Array通常是一个Uint8Array或普通数组存放编译后的指令序列分发器Dispatcherwhile(true) { switch(opcode) { ... } }结构负责读取并执行指令虚拟寄存器/栈Virtual Stack用于存储中间计算结果通常是另一个数组实战技巧在Chrome DevTools的Sources面板用正则搜索case\s\d:密度最高的函数大概率就是分发器入口。字节码数组通常在分发器函数的闭包变量或模块顶层定义。【JSVM架构示意图】 ┌─────────────────────────────────────┐ │ 原始JS业务逻辑 │ │ sign md5(url ts secret) │ └──────────────┬──────────────────────┘ │ JSVM编译器 ▼ ┌─────────────────────────────────────┐ │ 字节码: [0x01, 0x03, 0x0A, ...] │ ← Code Array ├─────────────────────────────────────┤ │ while(true) { │ │ op code[pc]; │ ← Dispatcher │ switch(op) { │ │ case 0x01: stack.push(...) │ ← Virtual Stack │ case 0x03: astack.pop();... │ │ case 0x0A: call_native(...) │ │ } │ │ } │ └─────────────────────────────────────┘第二步导出字节码 构建指令映射表这是最关键的一步。你需要知道每个opcode对应什么操作。方法A静态分析分发器逐个阅读switch-case手动记录opcode → 语义的映射。比如0x01: PUSH_IMMEDIATE压入立即数0x03: ADD栈顶两元素相加0x0A: CALL_NATIVE调用外部原生函数0x1F: XOR异或运算方法B动态Trace推荐在分发器的switch入口处插桩hook住op变量和虚拟栈状态触发一次签名请求导出完整的执行trace。然后对trace做频次统计和模式匹配自动推断指令语义。实战经验很多JSVM会把字符串、常量单独存放在一个“常量池”数组中字节码里的索引指向的是常量池而非直接值。务必同时导出常量池否则反编译出来的代码全是数字无法理解。第三步编写反编译器字节码→伪代码有了指令映射表和字节码序列就可以写反编译器了。不需要做得很完美目标是生成可读的伪代码而非可执行的JS。核心思路模拟虚拟栈的行为将字节码序列转换为等价的表达式树或三地址码。# 伪代码示例简单的栈式反编译器核心逻辑defdecompile(bytecode,const_pool):pc0output[]whilepclen(bytecode):opbytecode[pc]ifop0x01:# PUSHvalconst_pool[bytecode[pc1]]output.append(fpush({val}))pc2elifop0x03:# ADDoutput.append(add(pop(), pop()))pc1elifop0x0A:# CALL_NATIVEfunc_idxbytecode[pc1]output.append(fcall(native_funcs[{func_idx}]))pc2# ... 其他指令returnoutput这一步的输出可能长这样push(const[12]) // https://api.game.com/sign push(reg[3]) // timestamp add() // url ts push(const[45]) // secret_key xor() // (urlts) ^ secret call(md5) // md5(...) store(reg[7]) // sign result虽然粗糙但加密逻辑已经清晰可见。第四步验证与重构反编译出的伪代码需要验证正确性。验证方法在原始JSVM环境中对相同输入执行签名对比输出是否与你的伪代码推导一致。如果不一致说明指令映射表有误或遗漏了某些隐式操作如隐式类型转换、溢出处理。验证通过后就可以将伪代码重写为干净的原生JS替换掉原有的JSVM调用完成最终的还原。三、踩坑预警JSVM逆向的三个深水区指令编码动态化高级JSVM每次加载时opcode含义会变通过一个shuffle数组重映射。解决方案必须先还原shuffle算法或在运行时动态捕获映射关系。嵌套虚拟机解释器本身也被另一层VM保护。这种情况需要先脱外层VM再分析内层。通常需要结合AST去平坦化和动态dump。环境绑定检测字节码执行过程中会检查window.navigator、canvas指纹等环境特征不满足则返回错误签名。必须在Node.js或Puppeteer中补全环境或在浏览器中绕过检测后再trace。【JSVM逆向决策流程图】 发现疑似JSVM保护 ↓ 能否定位三要素(字节码/分发器/栈)? ──否──→ AST去平坦化 / 动态Dump ↓ 是 opcode是否动态编码? ──是──→ 还原Shuffle算法 / 运行时Hook ↓ 否 构建指令映射表(静态/动态Trace) ↓ 编写反编译器 → 生成伪代码 ↓ 输入输出验证 ──失败──→ 修正映射表 / 检查环境检测 ↓ 成功 ✅ 重建原生加密逻辑四、写在最后逆向JSVM的真正价值很多人觉得JSVM逆向耗时耗力不如直接Hook拿结果。这话没错但只适用于“一次性任务”。如果你需要长期稳定地对接某个平台、需要理解其风控策略的变化、或者在做安全审计需要评估保护强度——那么指令级还原是唯一可靠的路径。Hook只能拿到“是什么”反编译才能告诉你“为什么”和“怎么变的”。给准备入手JSVM逆向的朋友三个建议先从开源JSVM练手如JSMerger、Bytenode、obfuscator-io的VM选项理解原理后再碰商业保护。建立自己的指令识别模板库不同厂商的JSVM指令集有共性积累多了可以半自动化识别。永远保留动态调试作为兜底静态反编译不可能100%覆盖遇到复杂分支时回到DevTools里单步跟踪虚拟栈是最可靠的验证手段。JSVM保护看似铜墙铁壁但它终究是在JS引擎上跑的“软件模拟”。只要是软件就有迹可循。耐心拆解你会发现那些神秘的字节码背后不过是开发者精心包装过的、你早已熟悉的加密逻辑而已。本文所述技术仅供安全研究、漏洞分析及合法授权测试使用。未经授权对第三方系统进行逆向工程可能违反相关法律法规及服务条款请严格遵守法律底线尊重知识产权。
