1. 项目概述当加密逻辑藏在WASM里最近在分析一个数据接口时遇到了一个硬骨头。请求参数里有一个长长的、看起来毫无规律的加密字符串每次请求都会变化。常规的JavaScript调试工具追踪进去发现关键的计算逻辑并不是我们熟悉的JS代码而是一个.wasm文件。没错就是这个“WebAssembly”WASM模块。对于前端逆向来说WASM的出现就像给原本透明的JavaScript世界加上了一层厚厚的毛玻璃。你不能直接看到源码也不能像调试JS那样随意下断点、查看变量。它编译成了接近机器码的二进制格式高效、安全但也给分析带来了巨大的挑战。这个项目就是记录我如何从实战角度出发一步步剥开这层外壳逆向分析出WASM模块内部加密参数的生成逻辑。无论你是做安全研究、爬虫开发还是单纯对底层技术好奇这个过程都能让你对现代Web应用的保护机制有更深刻的理解。2. 核心思路与工具选型不走寻常路的逆向路径面对一个WASM模块直接硬啃二进制指令是不现实的效率极低。我们的核心思路是“降维打击”将高度优化的低级代码还原成更易于人类理解的高级表示形式。这个过程通常分为几个阶段提取、反编译、分析和重现。2.1 第一阶段模块的提取与初步探查首先你需要定位到这个WASM模块。在现代浏览器如Chrome的开发者工具中打开“Network”网络面板筛选“Wasm”类型在页面触发相关操作比如点击按钮发起那个带加密参数的请求时你就能看到.wasm文件的请求。可以直接在这里下载该文件。拿到.wasm文件后第一步不是急着反编译而是先用一些基础工具看看它的“身份证”。wasm-objdumpWebAssembly Binary Toolkit的一部分是个好选择。通过命令wasm-objdump -x your_module.wasm你可以看到模块的段Section信息比如导出了哪些函数Export、导入了哪些函数Import、以及它的类型签名。这一步能快速告诉你这个模块对外提供了哪些可调用的函数很可能加密函数就在其中以及它依赖了哪些外部环境比如内存、JavaScript的Math函数。2.2 第二阶段反编译工具链的选择这是最关键的一步。我们的目标是将WASM二进制码转换为可读性更强的代码。主要有两个方向反编译为C/C/Rust伪代码这是最理想的情况。工具如wasm2c官方工具或wasm-decompile来自WABT可以生成近似C语言的代码。wasm2c的输出更接近编译器中间表示结构严谨但略显晦涩wasm-decompile生成的代码可读性更高变量名和逻辑更清晰是我首推的初步分析工具。命令很简单wasm-decompile your_module.wasm -o output.dcmp。反汇编为WASM文本格式.watWASM文本格式WebAssembly Text Format是二进制格式的文本表示。使用wasm2wat工具可以完成这个转换wasm2wat your_module.wasm -o output.wat。.wat文件包含了所有的指令如i32.add,local.get、函数定义、内存操作等。虽然可读性比高级语言差但它是最完整、最准确的表示适合进行深入的指令级分析和动态调试。注意没有一种工具能完美还原出原始的、带变量名的源码。反编译工具通过算法恢复出控制流结构和类似高级语言的语法但变量名通常是var1、var2函数名也可能是func0、func1。这需要你结合上下文去理解和重命名。2.3 第三阶段动态调试与行为分析静态分析看反编译代码往往不够尤其是逻辑复杂或涉及大量数据交互时。我们需要动态调试来观察输入/输出、内存状态。浏览器调试Chrome DevTools 对 WASM 的支持已经非常强大。在“Sources”面板中你可以找到加载的WASM模块并直接在其文本格式.wat视图上下断点、单步执行、查看调用栈和内存。这是最直观的动态分析方式。专用调试器wasmtime、wasmer这类WASM运行时也提供了调试接口可以结合GDB等工具进行更底层的调试适合复杂场景。我的策略通常是先用wasm-decompile快速生成伪代码通读一遍了解整体框架和疑似加密的函数。然后用wasm2wat生成文本格式文件在浏览器中加载原网页并在关键函数处下断点进行动态跟踪观察参数传递、内存读写。两者结合效率最高。3. 逆向实战拆解一个模拟的加密函数为了便于说明我们假设分析一个简单的WASM模块它导出了一个名为generate_sign的函数该函数接受一个字符串指针和长度作为输入返回一个计算后的哈希值假设是MD5的简化变种。以下是我逆向的详细步骤。3.1 步骤一定位目标函数使用wasm-objdump -x查看导出表发现Export[2]: - func[0] generate_sign - sig[1] // 函数索引0名为generate_sign - memory[0] memory - memory[0] // 导出了内存这确认了我们的目标。接着用wasm-decompile反编译。在输出的output.dcmp文件中搜索generate_sign可能会找到类似下面的代码片段经过简化和重命名以便理解export function generate_sign(param0:int, param1:int):int { var a:int; var b:int; var c:int; var d:int 0x67452301; // MD5的初始常量A var e:int 0xefcdab89; // 初始常量B var f:int 0x98badcfe; // 初始常量C var g:int 0x10325476; // 初始常量D var h:int param0; // 输入字符串指针 var i:int param1; // 字符串长度 // ... 后续是复杂的循环和位运算 }虽然变量名是抽象的但像0x67452301这样的魔数Magic Number是强烈的提示。在密码学中这些是MD5算法的标准初始化向量。这立刻让我们将焦点锁定在MD5或类似MD5的算法上。3.2 步骤二深入算法逻辑静态看反编译代码的循环和运算比较吃力。这时切换到动态调试。在浏览器中打开页面在Sources找到对应的WASM文件通常是十六进制显示点击底部“{}”格式化按钮可转为.wat视图。在.wat文件中搜索generate_sign对应的函数体。在函数开始处func $generate_sign (param $p0 i32) (param $p1 i32) (result i32)...点击行号设置断点。然后在网页上触发加密请求。程序会在断点处暂停。现在关键是要理解WASM如何与内存交互。字符串参数通常是以指针内存地址的形式传入。在调试器的“Memory”面板查看传入的指针值比如$p01024就能看到内存中从1024地址开始存放的原始字符串字节。同时观察局部变量和全局变量在每一步运算后的值。3.3 步骤三还原算法与关键常量通过单步执行F10并观察每一步对那四个初始变量d, e, f, g的修改同时注意代码中出现的所有常量。例如你可能会在循环中反复看到一些加法常量如0xd76aa478,0xe8c7b756等。将这些常量与标准MD5算法的64个常数表进行对比如果匹配那么几乎可以确定这是MD5算法。实操心得WASM中常用i32.add,i32.rotl循环左移,i32.xor,i32.and,i32.or等指令来实现位运算。识别出常见的位运算模式如(x y) | (~x z)是MD5中的F函数是快速定位算法类型的关键。将反编译代码中的运算块与已知哈希算法如MD5、SHA-1、SHA-256的轮函数进行比对能极大加速分析进程。3.4 步骤四处理内存与字符串WASM模块有自己的线性内存。加密函数往往需要将输入字符串填充、分块。你需要观察代码中是否存在对输入长度param1的判断以及后续是否调用了类似memory.copy或进行了一系列的存储指令i32.store这很可能是在构造填充后的消息块。在调试时在内存面板监视相关内存区域的变化可以看到原始的输入字符串是如何被填充上0x80字节和长度信息的从而验证你的判断。3.5 步骤五输出结果的获取函数最终返回的往往是一个整数可能是哈希结果的内存地址指针。在函数返回前查看哪个内存地址被写入了新的、看起来像哈希值的数据通常是16字节或32字节的连续数据。这个地址就是结果所在。在JS调用侧它会从这个内存地址读取数据并可能转换为十六进制字符串。4. 算法还原与代码重构分析清楚后目标是用我们熟悉的语言如Python/JavaScript重新实现这个加密逻辑。4.1 基于反编译代码的重写将wasm-decompile输出的伪代码作为蓝图。虽然变量名不友好但逻辑结构是清晰的。你需要重命名变量根据其作用如hash_a,hash_b,msg_block重命名。翻译运算将WASM的位运算指令直接对应到高级语言的运算符。例如i32.add-i32.rotl(x, n)-((x n) | (x (32-n)))(在JS中注意使用无符号右移)i32.xor-^i32.and-提取常量将代码中所有硬编码的十六进制常量提取出来作为算法常量数组。重建流程按照反编译代码的控制流循环、分支用高级语言重写整个函数。4.2 验证重构的正确性这是至关重要的一步。你不能只保证算法逻辑一致还必须保证所有细节一致。字节序WASM使用小端序Little-Endian。当你从内存中读取多字节数据如一个32位整数时或者在处理输入输出时必须确保你的重构代码使用了正确的字节序。一个常见的错误是算法逻辑完全正确但因为字节序问题导致结果不一致。整数溢出与截断WASM的i32运算是模2^32的。在JavaScript中需要使用 0或(x 0xffffffff)来模拟无符号32位整数溢出。Python中则可以用 0xffffffff。内存布局模拟如果算法涉及复杂的内存操作你可能需要在重构代码中用一个ArrayBuffer或bytearray来模拟WASM的内存布局确保数据填充和访问的偏移量与原始模块完全一致。验证方法构造相同的输入分别调用原始WASM模块可以通过Node.js的WebAssemblyAPI动态加载测试和你的重构函数对比输出是否逐字节相同。从一个简单输入开始逐步增加复杂度。5. 常见问题与深度排查技巧在实际逆向中绝不会总是一帆风顺。下面是一些我踩过坑后总结的排查技巧。5.1 问题一反编译代码过于混乱无法理清逻辑技巧不要试图一次性理解整个函数。先找“锚点”比如明显的常量、固定的循环次数64次可能是MD5/SHA-25680次可能是SHA-1。然后重点关注对这些“锚点”数据的操作流程。使用wasm2wat生成文本格式虽然难读但你可以用文本编辑器的搜索功能精确查找对特定常量或变量的所有操作从而画出数据流图。5.2 问题二动态调试时无法在正确的时机断住或内存数据看不懂技巧除了在函数入口断点还可以在WASM内存的特定地址写“访问断点”或“写入断点”。如果你知道加密结果大概存放在哪个内存区域比如通过观察JS代码读取内存的地址可以对该区域设置写入断点从而定位到具体是哪一段代码生成了最终结果。对于内存数据将其以十六进制、无符号整数、ASCII码等多种格式显示交叉查看。5.3 问题三算法中掺杂了外部导入函数增加了不确定性技巧WASM模块可以导入JS函数。用wasm-objdump -x查看Import部分。常见的导入有Math.random用于加盐、Date.now用于时间戳、甚至是一些自定义的加密函数。你需要去分析调用这些导入函数的JS代码弄清楚它们的作用。有时所谓的“加密”核心可能只是一个简单的变换真正的随机性来源于导入的JS函数。5.4 问题四重构的代码结果总差一点排查清单初始化向量确认四个或八个初始哈希值是否正确。消息填充填充规则位填充1、补0、附加长度是否完全一致长度是位长度还是字节长度附加的长度是小端序还是大端序循环处理循环轮数对吗每轮中使用的消息子块索引是否正确运算细节rotl循环左移的位数对吗加法模2^32处理了吗最终输出哈希值是从A、B、C、D寄存器按什么顺序拼接的是小端序输出吗最有效的调试方法是“差分调试”。让原始WASM模块和你的重构代码在完全相同的输入下打印出每一轮、甚至每一步运算后的中间状态哈希变量A、B、C、D的值进行逐行比对找到第一个出现差异的地方那里就是bug所在。5.5 对抗混淆与优化更高阶的WASM模块可能经过了混淆或激进优化。控制流平坦化打乱函数的基本块顺序用调度器控制执行流程。这会使反编译代码看起来像一个巨大的switch-case。需要耐心分析调度逻辑还原原始控制流。虚拟化将部分算法逻辑用自定义的字节码解释器执行这大大增加了分析难度。需要识别出解释器循环和指令分发逻辑。激进编译器优化编译器可能会内联函数、展开循环、常量传播使得算法面目全非。此时动态调试比静态分析更可靠专注于输入输出和关键内存区域的变化。面对这些核心策略依然是动态分析为主静态分析为辅。牢牢抓住“数据”这条线——原始输入是什么最终输出是什么在内存中数据是如何被一步步变换的。通过大量的断点和内存监视总能理清其主干逻辑。这个过程极其考验耐心和细心但每破解一个这样的模块你对系统底层和加密学的理解都会深一层。