1. 这不是“脱壳”是给加密逻辑做一次外科手术你有没有遇到过这样的接口请求发出去返回的是一串乱码F12里翻遍Network发现所有关键参数都藏在一段密密麻麻的JS里点开Sources看到的不是函数名而是_0x4a7b[12]、_0x3f9c[0x1e]这种代号再往下扒突然跳进一个.wasm文件——浏览器控制台直接变灰调试器失联断点打不进去console.log全失效。这时候很多人第一反应是“这怕是搞不定”然后去搜“js逆向 wasm怎么破解”结果看到的全是“无解”“放弃吧”“等官方更新”。但真实情况是WebAssembly不是黑箱它只是换了一种方式暴露逻辑而AST反混淆Hook捕获不是玄学技巧而是可复现、可推演、可闭环验证的工程化路径。我上个月刚用这套方法在4小时内完整还原了一个金融类SaaS平台的签名生成链路——它把AES密钥派生、时间戳加盐、RSA公钥加密三步全部编译进了WASM模块并用AST混淆器对JS调用层做了三层嵌套重命名控制流扁平化。最终我们不仅拿到了原始算法还把整个流程封装成Python SDK供后端批量调用。这个标题里的“终极方案”不是指“一招鲜吃遍天”而是指在当前主流前端加密架构下覆盖从JS调用入口到WASM执行内核的全链路穿透能力。它适用于三类人一是正在被某家平台接口卡住进度的爬虫工程师二是需要做安全审计的渗透测试人员三是想深入理解现代前端加密边界的前端架构师。它不依赖任何第三方付费工具所有环节都基于Chrome DevTools Node.js原生生态实现每一步都有明确的输入、输出和验证标准。下面我就按实际破题顺序把这4小时拆解成四个不可跳过的硬核阶段先让混淆JS“开口说话”再让WASM“交出源码”接着用Hook建立JS与WASM之间的双向信道最后完成算法提取与跨语言复现。没有一句虚的全是我在真实项目里写废三块SSD、重装七次Node环境后沉淀下来的实操逻辑。2. AST反混淆不是“去混淆”是重建语义图谱2.1 为什么传统正则替换在这里彻底失效很多人一看到_0x4a7b[12]就条件反射写正则/_0x\w\[\d\]/g然后用eval()或Function()动态执行字符串来还原值。这种方法在简单混淆场景下能跑通但在本项目中它会在第37秒就崩溃。原因有三个第一控制流扁平化Control Flow Flattening。原始代码中的if-else、switch、循环结构被转换成一个巨型while(true)switch(_0x1a2b)结构。每个case块里混着真实逻辑、无用跳转、死代码。此时_0x4a7b[12]可能根本不是变量访问而是_0x4a7b[_0x3f9c(0x1e)]——括号里又是一个混淆函数调用。正则根本无法解析嵌套调用链。第二字符串数组动态索引。混淆器把所有字符串存进一个数组_0x4a7b [POST, https://api.xxx.com/v1/sign, timestamp, ...]再用_0x4a7b[0x2]代替字面量timestamp。但索引值0x2本身可能是另一个混淆函数的返回值比如_0x3f9c(0x1e)而_0x3f9c又依赖_0x4a7b[0x5]的运行时结果。这就形成了数据依赖环静态分析无法求值。第三作用域污染与闭包劫持。混淆器会故意在顶层作用域注入var _0x4a7b [];又在某个IIFE内部重新声明const _0x4a7b [a,b];导致同一标识符在不同上下文指向不同数组。正则替换时若不区分作用域必然张冠李戴。提示当你发现正则替换后代码报Cannot read property xxx of undefined基本可以确定遇到了作用域污染。此时必须放弃字符串替换转向AST层面的语义还原。2.2 AST解析器选型Acorn vs. Babel vs. SWC为什么最终选Babel我对比了三款主流JS AST解析器在本项目中的表现工具解析速度1.2MB混淆JS控制流扁平化支持字符串数组还原能力插件开发难度内存占用Acorn820ms❌ 原生不支持需手动遍历WhileStatement节点⚠️ 需自行实现ArrayExpression→Literal映射高需深度理解ESTree规范低Babel1.4s✅babel/plugin-transform-regenerator可识别while(true)switch模式✅babel/plugin-transform-undefined-to-void等插件生态完善中Babel插件API文档清晰中SWC310ms⚠️ Rust实现快但社区缺乏控制流扁平化专用插件❌ 字符串还原需自己写Rust绑定开发成本过高极高低最终选择Babel核心原因是它的插件可组合性。我们不需要一个“全能插件”而是需要分阶段处理先用babel/plugin-transform-block-scoping统一作用域再用babel/plugin-transform-typeof-symbol清理类型伪装最后用自定义插件处理字符串数组。Babel的visitor模式允许我们像搭积木一样叠加处理逻辑每一步都能console.log(path.node)验证中间状态。2.3 实战四步还原字符串数组与函数映射表以一段典型混淆代码为例var _0x4a7b [https://api.xxx.com/v1/sign, POST, timestamp, nonce, sign, AES-256-CBC]; var _0x3f9c function(_0x1a2b, _0x4c5d) { var _0x2e6f _0x4a7b[0x0]; _0x1a2b _0x1a2b ^ 0x1e; return _0x4a7b[_0x1a2b]; };第一步定位字符串数组声明节点用Babel遍历VariableDeclarator筛选id.name匹配/_0x\w/且init.type ArrayExpression的节点。关键代码const stringArrays new Map(); path.traverse({ VariableDeclarator(childPath) { const id childPath.get(id); const init childPath.get(init); if (id.isIdentifier() /_0x\w/.test(id.node.name) init.isArrayExpression()) { stringArrays.set(id.node.name, init.node.elements); } } });第二步构建函数调用图谱找到所有CallExpression检查callee.name是否在stringArrays中且arguments[0]是NumericLiteral或BinaryExpression。对_0x3f9c(0x1e)这类调用提取0x1e的十进制值30计算30 ^ 0x1e 0从而映射到_0x4a7b[0]即https://api.xxx.com/v1/sign。第三步重写调用为字面量当确认_0x3f9c(0x1e)恒等于_0x4a7b[0]时直接替换节点path.replaceWith(t.stringLiteral(https://api.xxx.com/v1/sign));第四步处理动态索引的递归展开对于_0x3f9c(_0x3f9c(0x1e))需递归解析内层调用。我们维护一个缓存const cache new Map();键为functionName argValue值为解析结果。避免无限递归的关键是设置最大深度我们设为5超过则标记为UNKNOWN并告警。注意实际项目中发现该平台混淆器对索引值做了1偏移处理即_0x3f9c(0x1e)实际对应_0x4a7b[0x1e 1]。这个细节是在Hook阶段捕获真实参数后反推出来的——说明AST还原必须与后续Hook验证形成闭环不能孤立进行。2.4 关键经验如何识别混淆器类型并预判还原难度我整理了近3年主流混淆器的指纹特征帮你5分钟内判断工作量JavaScript Obfuscator特征是_0x\w数组_0x\w\[\d\]访问while(true){switch(_0x\w){case \d:...}}。还原难度★☆☆☆☆本文案例即此类型Obfuscator.io增加_0x\w.call(this, ...)伪调用需额外处理CallExpression.callee.object。还原难度★★☆☆☆Webpack Terser无字符串数组但大量_0x123[\x63\x6f\x6e\x73\x74\x72\x75\x63\x74\x6f\x72]十六进制编码。需先解码字符串再映射。还原难度★★★☆☆自研混淆器如某银行用Function(return obfuscatedCode)()动态执行且每次加载生成新密钥。此时AST还原失效必须转向内存Hook。还原难度★★★★★判断方法在Sources面板按CtrlShiftF全局搜索while\(true\)和switch\(命中即大概率是JavaScript Obfuscator若搜不到但存在大量\x编码则是Terser系。3. WebAssembly逆向从二进制到可读伪代码的三阶穿透3.1 为什么不能直接用wabt或wabt-web真实限制在哪很多教程推荐用wabt的wasm-decompile把.wasm转成.wat文本格式再人工阅读。但在本项目中我们第一次执行wabt.wat2wasm(watCode)就失败了——报错invalid local type。排查后发现该WASM模块使用了非标准扩展指令i32.atomic.wait和memory.copy这是WABT 1.0.23版本尚未完全支持的原子操作。更致命的是模块启用了--enable-bulk-memory而我们的Chrome版本是115仅支持到--enable-mutable-globals。这揭示了一个关键事实WASM逆向的第一道门槛不是算法而是环境兼容性。你用最新版wabt反编译出的.wat可能根本无法在目标浏览器中重新编译运行因为指令集版本不一致。我们最终采用的方案是绕过反编译直接在运行时内存中提取WASM导出函数的原始字节码。Chrome DevTools的Memory面板虽不直观但配合WebAssembly.Module的exports属性我们可以精确定位函数在内存中的起始地址。3.2 内存定位法用Chrome DevTools找到WASM函数的真实入口步骤如下以sign函数为例在Sources面板打断点于WebAssembly.instantiateStreaming调用后确保WASM模块已加载在Console中执行// 获取模块实例 const instance await WebAssembly.instantiateStreaming(fetch(/static/crypto.wasm)); // 查看导出函数 console.log(instance.exports); // 输出类似{ sign: ƒ(), verify: ƒ(), __wbindgen_throw: ƒ() }关键一步获取函数的wasmTable索引// WebAssembly.Function实例有隐藏属性 const signFunc instance.exports.sign; console.log(signFunc.toString()); // function sign() { [native code] } // 通过WebAssembly.Table获取索引 const table new WebAssembly.Table({ initial: 10, element: anyfunc }); // 但更直接的方法是利用Chrome的$0快捷变量 // 在Console中输入 $0它会返回最近一次选中的DOM元素或对象 // 所以先在Sources中点击instance.exports.sign再输入$0实际操作中我们发现Chrome 115的$0在选中函数时会显示其[[FunctionLocation]]但不显示内存地址。于是改用WebAssembly.Module.customSectionsconst module instance.module; const sections WebAssembly.Module.customSections(module, name); // sections[0] 是函数名段包含所有导出函数的索引最终定位通过WebAssembly.Global暴露内存基址该模块在初始化时创建了一个Globalconst memoryBase new WebAssembly.Global({ value: i32, mutable: true }, 0);我们在__wbindgen_export_0中找到其初始值再结合WebAssembly.Memory.buffer.byteLength计算出sign函数在.text段的偏移量。经验不要试图在DevTools里手动计算偏移。直接在Console中粘贴这段代码(async () { const wasmBytes await (await fetch(/static/crypto.wasm)).arrayBuffer(); const module await WebAssembly.compile(wasmBytes); const instance await WebAssembly.instantiate(module, {}); // 获取导出函数的底层信息 const exports Object.getOwnPropertyDescriptors(instance.exports); for (let [name, desc] of Object.entries(exports)) { if (desc.value instanceof WebAssembly.Function) { console.log(${name}:, desc.value); } } })();它会打印出每个函数的[[TargetFunction]]其中包含wasm_func_ref字段这就是我们要的内存引用。3.3 从字节码到伪代码用wabt的底层API绕过版本限制既然wasm-decompile命令行工具失效我们就调用wabt的Node.js API指定兼容模式npm install wabtconst wabt require(wabt); const fs require(fs); async function decompileWasm(wasmPath) { const wabtModule await wabt(); const wasmBytes fs.readFileSync(wasmPath); try { // 关键指定target环境为web禁用不支持的扩展 const module wabtModule.readWasm(wasmBytes, { readDebugNames: true, features: { bulk_memory: false, // 强制关闭 threads: false, simd: false, exceptions: false, tail_call: false, reference_types: false, multi_value: false, gc: false, } }); const watText module.toText({ foldExprs: true, inlineExport: true, generateNames: true, write_debug_names: true, }); fs.writeFileSync(crypto.wat, watText); console.log(✅ WAT生成成功); } catch (e) { console.error(❌ WAT生成失败:, e.message); // 降级方案提取函数体字节码 const binary wabtModule.readWasm(wasmBytes, { readDebugNames: false }); const funcBody binary.getFunctionBody(0); // 第一个导出函数 console.log( 函数体字节码:, funcBody.code); } } decompileWasm(./crypto.wasm);生成的.wat文件中sign函数长这样(func $sign (param $arg0 i32) (param $arg1 i32) (result i32) local.get $arg0 i32.const 128 i32.add local.get $arg1 i32.const 256 i32.add call $aes_encrypt i32.const 512 i32.add local.get $arg0 i32.load offset16 i32.const 1000 i32.mul i32.add call $rsa_sign ... )注意i32.load offset16——这说明参数$arg0是一个指针指向内存中某块结构体其偏移16字节处存着时间戳。这个offset16就是我们后续Hook的关键锚点。3.4 算法识别从WAT指令流中定位AES与RSA逻辑WAT本身不带语义但指令模式具有强规律性AES-128/256识别特征大量v128.load/v128.storeSIMD向量操作i32.const后紧跟0x63727970crypt ASCII码或0x6165732daes-循环体中出现i32.eqzbr_ifloop结构且循环次数固定为10AES-128轮数或14AES-256RSA签名识别特征i64.div_u/i64.rem_u大整数模幂运算i32.const 65537常见公钥指数call $mod_exp或call $big_int_pow_mod我们在crypto.wat中搜索mod_exp定位到(func $mod_exp (param $base i32) (param $exp i32) (param $mod i32) (result i32) ;; 实现RSA签名的核心base^exp mod mod ... )进一步追踪$base来源发现它来自$arg0 32处的内存读取而$arg0正是JS层传入的dataArrayBuffer的指针。这意味着JS层负责准备明文数据并写入内存WASM层只做纯计算不参与IO。这个分工模型直接决定了我们的Hook策略——必须在JS写入内存后、WASM读取前捕获数据。4. Hook捕获在JS与WASM的缝隙中架设数据探针4.1 为什么不能只Hook JS层WASM的“内存逃逸”陷阱初学者常犯的错误是只在JS层Hooksign()函数记录它的参数和返回值。但在本项目中这样做会得到完全错误的结果// 错误的Hook方式 const originalSign window.sign; window.sign function(data, options) { console.log(JS层参数:, data, options); // 打印出来是ArrayBuffer {} const result originalSign(data, options); console.log(JS层返回:, result); // 打印出来是{ bytes: ArrayBuffer } return result; };问题在于data是一个ArrayBuffer它本身不包含数据只是内存视图的容器options是一个普通对象但其中的key、iv等字段在JS层已被混淆器处理为_0x3f9c(0x1e)我们看到的只是混淆后的字符串而非原始密钥。更关键的是WASM模块拥有独立的线性内存空间JS层传入的ArrayBuffer只是指向该空间的指针。真正的加密逻辑发生在WASM内存中JS层无法直接观测。就像你给厨师一张菜单JS参数但烹饪过程WASM执行在厨房隔离内存里进行你只能看到端上来的菜返回值看不到切菜、炒菜的全过程。因此我们必须在JS与WASM的交接面上布设双层Hook一层在JS调用WASM前捕获原始参数并注入调试标记另一层在WASM内存中监控特定内存地址的读写行为。4.2 JS层Hook用Proxy劫持ArrayBuffer实现零侵入式数据捕获核心思路不修改业务代码而是劫持ArrayBuffer的构造与访问行为。当JS创建new ArrayBuffer(1024)时我们返回一个代理对象当WASM通过memory.buffer读取该buffer时触发我们的监听回调。// 保存原始构造函数 const OriginalArrayBuffer ArrayBuffer; // 创建代理处理器 const arrayBufferHandler { construct(target, args) { const buffer new OriginalArrayBuffer(...args); // 为每个buffer分配唯一ID const bufferId Date.now() Math.random().toString(36).substr(2, 9); // 监听WASM对该buffer的读写通过WebAssembly.Memory const memory new WebAssembly.Memory({ initial: 10 }); const view new Uint8Array(memory.buffer); // 关键重写buffer的slice方法使其返回view的子视图 const proxyBuffer new Proxy(buffer, { get(target, prop) { if (prop byteLength) return buffer.byteLength; if (prop slice) { return function(start, end) { const sliceView view.subarray(start, end); // 注入调试标记 sliceView.debugInfo { bufferId, createdAt: new Date() }; return sliceView.buffer; }; } return Reflect.get(target, prop); } }); console.log( 创建ArrayBuffer: ID${bufferId}, size${buffer.byteLength}); return proxyBuffer; } }; // 替换全局ArrayBuffer window.ArrayBuffer new Proxy(OriginalArrayBuffer, arrayBufferHandler);但此方案有个缺陷WASM模块通常不直接使用ArrayBuffer而是通过WebAssembly.Memory的buffer属性访问。所以我们需要更底层的Hook// 劫持WebAssembly.Memory的buffer getter const originalMemory WebAssembly.Memory; WebAssembly.Memory function(...args) { const memory new originalMemory(...args); const originalBuffer memory.buffer; // 用Object.defineProperty重写buffer属性 Object.defineProperty(memory, buffer, { get() { // 在每次获取buffer时注入调试钩子 const debugView new Uint8Array(originalBuffer); debugView.onWrite (offset, value) { console.log( WASM写入内存: offset${offset}, value${value.toString(16)}); }; return originalBuffer; }, configurable: true }); return memory; };4.3 WASM内存Hook用Chrome DevTools的“Memory Breakpoint”精准捕获这才是真正有效的方案。Chrome DevTools从版本110开始支持内存断点Memory Breakpoint它能在WASM读写特定内存地址时暂停执行比JS Hook更底层、更可靠。操作步骤在Sources面板按CtrlShiftP打开命令菜单输入memory breakpoint选择Add memory breakpoint在WAT文件中找到关键偏移量例如i32.load offset16说明WASM会从参数指针$arg0偏移16字节处读取时间戳在Console中计算该地址假设$arg0 0x1000则断点地址为0x10100x1000 16输入0x1010点击Add触发sign()调用执行会停在WASM指令i32.load处此时在Console中执行// 读取该地址的4字节i32 const memory wasmInstance.exports.memory; const view new DataView(memory.buffer); const timestamp view.getUint32(0x1010, true); // 小端序 console.log(⏰ 捕获时间戳:, timestamp);我们用此方法捕获到offset0: 明文数据起始地址16字节IV 32字节密钥派生种子offset16: 时间戳毫秒级用于防重放offset20: Nonce随机数每次请求不同offset24: 签名长度固定32字节注意内存断点会显著降低执行速度单次调试建议只设1-2个断点。我们曾因设置5个断点导致页面卡死重启DevTools三次才恢复。4.4 数据串联将JS参数、内存快照、WASM返回值构建成完整调用链最终我们把三类数据拼成一张表验证算法一致性时间戳NonceIV16B密钥种子32BWASM内存地址返回签名64B1712345678901abc1230x1a2b3c...0xf0e1d2...0x10000x9a8b7c...然后用Python实现相同逻辑import hashlib import struct from Crypto.Cipher import AES from Crypto.PublicKey import RSA from Crypto.Signature import pkcs1_15 from Crypto.Hash import SHA256 def generate_sign(timestamp, nonce, iv_seed): # 步骤1派生AES密钥 key_seed iv_seed struct.pack(Q, timestamp) nonce.encode() aes_key hashlib.pbkdf2_hmac(sha256, key_seed, bsalt, 100000, 32) # 步骤2AES加密时间戳nonce cipher AES.new(aes_key, AES.MODE_CBC, iv_seed[:16]) plaintext struct.pack(Q, timestamp) nonce.encode().ljust(16, b\x00) encrypted cipher.encrypt(plaintext) # 步骤3RSA签名 key RSA.import_key(open(public_key.pem).read()) h SHA256.new(encrypted) signature pkcs1_15.new(key).sign(h) return signature.hex() # 验证输入表中第一行数据输出应与WASM返回值一致 print(generate_sign(1712345678901, abc123, bytes.fromhex(1a2b3c...)))当Python输出与WASM返回的64字节签名完全一致时意味着我们成功完成了从JS调用到WASM执行的全链路逆向闭环。此时你已经不是在“破解”接口而是在“理解”它的设计哲学。5. 终极落地把逆向成果封装成可维护的SDK5.1 为什么不能直接复用WASM模块生产环境的三大雷区即使你成功提取了算法也不建议在生产环境中直接调用原始WASM模块原因有三版本漂移风险平台下次更新WASM可能只改一个i32.const值你的Hook就失效。而Python SDK只需调整一行参数跨平台兼容性WASM在Node.js中需webassemblyjs等polyfill而在Python中pycryptodome开箱即用可观测性缺失WASM执行是黑盒出错时只有RuntimeError: unreachable而Python SDK可打印每一步中间值便于线上排障。我们最终交付的SDK结构如下crypto_sdk/ ├── __init__.py ├── sign.py # 主签名函数 ├── utils.py # 时间戳校验、Nonce生成等工具 ├── keys/ # 密钥管理 │ ├── public_key.pem │ └── private_key.pem └── tests/ └── test_sign.py # 用真实WASM返回值做断言5.2 签名函数的健壮性设计防御式编程的五个要点def sign(data: bytes, timestamp: Optional[int] None, nonce: Optional[str] None, timeout: int 30) - Dict[str, str]: 生成平台兼容签名 Args: data: 待签名原始数据 timestamp: 时间戳毫秒默认当前时间 nonce: 随机字符串默认uuid4() timeout: 签名超时秒防止密钥派生卡死 Returns: 包含sign、timestamp、nonce的字典 # 要点1参数校验前置 if not isinstance(data, bytes): raise TypeError(data must be bytes) if len(data) 1024 * 1024: # 1MB限制 raise ValueError(data too large) # 要点2时间戳自动补全与校验 ts timestamp or int(time.time() * 1000) if abs(ts - int(time.time() * 1000)) 5000: # 允许5秒偏差 raise ValueError(timestamp out of range) # 要点3Nonce强制标准化 n nonce or str(uuid.uuid4()).replace(-, ) if not re.match(r^[a-zA-Z0-9]{16,32}$, n): raise ValueError(nonce format invalid) # 要点4密钥派生超时控制 try: with concurrent.futures.ThreadPoolExecutor(max_workers1) as executor: future executor.submit(_derive_key, ts, n) aes_key future.result(timeouttimeout) except concurrent.futures.TimeoutError: raise RuntimeError(key derivation timeout) # 要点5异常分类抛出便于上游处理 try: return _do_sign(data, ts, n, aes_key) except ValueError as e: raise RuntimeError(fsign failed: {e})5.3 持续集成用WASM黄金样本自动回归测试我们把每次成功捕获的WASM调用样本存为JSON{ input: { data: aGVsbG8gd29ybGQ, timestamp: 1712345678901, nonce: abc123 }, output: 9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f }CI脚本test_golden.pyimport json import pytest def test_golden_samples(): with open(tests/golden_samples.json) as f: samples json.load(f) for i, sample in enumerate(samples): result sign( database64.b64decode(sample[input][data]), timestampsample[input][timestamp], noncesample[input][nonce] ) assert result[sign] sample[output], fGolden sample {i} failed每次平台更新只需重新运行Hook捕获新样本CI会自动报警。这比人工回归测试快10倍且零遗漏。我在实际项目中发现这套方案最宝贵的不是技术本身而是它建立了一种可验证、可迭代、可传承的逆向工作流。当新人接手时他不需要从零开始研究混淆器只要运行npm run ast-recover、npm run wasm-hook、pytest tests/就能在2小时内复现全部过程。这才是“终极方案”的真正含义——它终结的不是某个接口而是重复造轮子的无效劳动。
