简介这是一份面向微信小程序开发者与安全研究人员的反编译工具资源包内含 wxappUnpacker 完整项目文件。它支持解析微信小程序的主包与分包将 .wxml、.wxss、.js、.json 等二进制格式还原为可读代码便于分析业务逻辑、定位性能问题或进行安全审计。压缩包共 780 个文件容量 1.97MB主要包含 JavaScript 脚本、JSON 配置、TypeScript 类型定义、Markdown 文档、License 声明以及 Windows 下可用的 cmd/ps1 辅助命令等目录结构完整可直接查阅工具源码与说明。目前已有 268 人浏览学习。通过研读该资源读者可掌握小程序反编译的基本流程与关键脚本用法理解主包与分包的解析差异并在合法合规前提下开展代码学习、漏洞排查或内部机制研究。1. 小程序反编译文件wxappUnpacker这个工具到底在解什么一位开发者同事发来一个后缀为 .wxapkg 的文件说想评估里面某页面模块的交互逻辑结果用文本编辑器打开全是乱码读不出任何结构。小程序反编译文件wxappUnpacker 这类解包工具解决的正是这个诉求把一个 wxapkg 小程序包还原成接近原始工程源码的目录让 JS、JSON、模板和样式恢复可读形态。它适合三种人接手历史遗留包但找不到源码的维护者、想做页面结构梳理的评估人员、以及纯粹想研究小程序打包协议的学习者。注意这不是破解运行时保护而是把平台方打包时用的压缩与编译规则逆向翻回去所以还原结果不会和源码一模一样但足够支撑阅读和二次分析。2. 运行环境与前置准备让 wxappUnpacker 顺利跑起来的最短路径2.1 运行原理不是玄学而是把打包协议翻回去wxappUnpacker 本质上是一个 Node.js 脚本集它的工作可以拆成三步。第一步是解析 wxapkg 的容器格式小程序官方工具打包时会在文件头部写入文件数量、索引区和数据区的偏移信息解包脚本要做的就是把这些字段读出来还原出原始的文件名和二进制内容。第二步是对还原出的 JS 做 AST 解析因为打包后的 JS 是经过压缩和混淆的直接看就是一行长字符串脚本会借助 esprima 这类解析器把它格式化。第三步是把编译后的模板函数还原成近似 WXML 的标签结构这一步做不到完美还原但能给出属性和事件绑定关系。我之所以建议新手先理解这个流程是因为 wxappUnpacker 的运行结果并不是一锤子买卖你会在后续手动处理中反复用到它产出的中间文件。比如解包后发现某个页面 JS 是可读的但对应模板还是函数调用形式这时你需要自己做一层映射。搞清楚每一步在做什么排错时才不会对着报错信息瞎猜。2.2 环境检查清单Node 版本与三条必看命令常见做法是使用 Node.js v14.x 来跑这套脚本v17 以上的新版本在 esprima 的某些解析分支上会报兼容性错误这个坑后面避坑章节还会提到。先做三个检查确认环境正常再进入解包流程。# 检查 Node 版本建议 v14.x node -v # 进入解包脚本目录后安装依赖 npm install # 验证核心解析模块能被成功加载 node -e require(esprima); require(css-tree); console.log(deps ok)第一条命令没什么好说的版本直接决定后续行为差异推荐 v14 不是因为它新而是社区里大量反馈都基于这个版本验证过。第二条命令是安装依赖wxappUnpacker 不只依赖 esprima还会用到 css-tree 处理样式、js-beautify 做代码美化这些依赖如果没有正确安装解包时会报 Cannot find module。第三条命令是一个快速自检如果这条命令输出 deps ok说明核心依赖都加载成功可以继续。如果第三条命令报错优先检查 npm install 时有没有出现红色报错尤其是在网络受限环境下某些依赖下载失败不会中断安装流程但会在运行时暴露问题。此时不要急着重装先看报错信息里缺的是哪个模块再单独执行npm install 模块名补装。2.3 需要准备的样例包从哪里拿一个 wxapkg 文件做验证时你需要一个真实的 wxapkg 文件。常见来源有两个一是自己用开发者工具生成创建一个空白小程序项目后在工具里选择打包为线上版本再从缓存目录中找到产物二是找同事要一个已知的、用于测试的旧包。不要拿线上正式包做练习因为正式包可能有分包加密、插件隔离等额外处理会增加定位环境问题的难度。拿到包后先看文件大小一个只含一个页面的测试包通常在几十 KB 到几百 KB如果文件有几 MB说明里面可能带有较多的图片资源。资源文件解包后占体积但不会影响脚本运行只是读产物时容易被大量图片干扰。3. 反编译完整流程从 wxapkg 到可阅读源码的四个步骤3.1 第一步确认文件头协议判断是否需要解密分支wxapkg 文件有不同的打包协议版本常见的是 V0 和 V1。V1 协议的文件头信息更长同时包含了更完整的文件清单结构而 V0 相对简单。大多数解包脚本能自动识别这两种协议但如果你拿到的包是经过混淆处理的加密包脚本需要走解密分支这通常在命令行里通过-d参数控制。先用十六进制查看工具确认文件头。文件的前几十字节里应当包含可读的文件名信息或者明显的索引区长度字段。# 查看 wxapkg 文件头判断协议版本 xxd demo.wxapkg | head -n 8正常解包后的文件头会有一段保留字段和版本号标识V1 协议通常能在头部看到更长的字符串段。如果你的包在文件头位置全是无规律的二进制内容且长度异常说明这个包可能被二次加密过解包脚本默认分支不会成功。这时不要立刻怀疑脚本坏了先确认是否有配套的加密算法说明因为平台方在特定场景下的加密格式并不公开社区脚本只覆盖主流情况。确认协议版本后在解包命令前加上对应的解析参数。这一步的价值在于它能直接影响你后续用哪个脚本入口。我自己习惯先跑一次无参数命令试探如果输出目录是空的或者直接报文件头解析失败再回头用xxd看文件头结构。3.2 第二步解包主包得到基础目录树确认文件头正常后执行解包命令。社区流传最广的版本里入口脚本通常是wuWxapkg.js它负责把 wxapkg 容器里的所有文件释放到同名目录下。# 解包 demo.wxapkg输出到 demo 目录 node wuWxapkg.js demo.wxapkg执行后脚本会在当前目录生成一个以包名命名的文件夹里面就是还原出的文件目录。你需要重点关注三类东西app.js、app.json 和页面目录下的 js/json/wxml/wxss。如果脚本输出了一行类似unpack done的提示说明容器解析正常。如果没有任何输出就要检查是否因为文件头类型不对导致脚本提前退出。这里有个细节值得说明解包命令执行完后很多文件仍然是压缩成一行的状态。比如 app.js 打开后是密集的代码串中间几乎没有换行这是正常的。因为wuWxapkg.js只负责拆容器不负责美化代码。要让代码可读还需要继续跑代码还原脚本。所以不要在这一步就判定工具失效很多第一次用的开发者走到这里就放弃了其实后面还有关键步骤。3.3 第三步执行代码还原与美化让压缩代码恢复结构拿到基础目录树后下一步是对 JS 文件做格式化处理。wxappUnpacker 里常见还原入口是wux2.js它可以遍历解包目录对所有 js 文件做 AST 解析和重新输出。# 对解包目录执行代码还原与美化 node wux2.js demo/这个脚本会遍历指定目录下的所有 .js 文件把压缩后的代码重新排版变量名不会恢复成原始语义名称但函数边界、缩进、字符串字面量都会变得清晰。你会看到类似var t function() {}的结构其中 t 这类短变量原本就是经过混淆的脚本不会做语义猜测。参数上只需要传入目录路径没有额外的开关。不过我建议在还原前先备份一份原始解包产物因为wux2.js会直接覆盖源文件。如果后续想对比某个文件在还原前后的差异没有备份就只能重新解包。这里还有一个使用习惯先对单页面目录跑一次比如node wux2.js demo/pages/index/确认单页面的还原效果符合预期再对整个目录全量执行避免某个异常文件的解析器报错中断整个任务。3.4 第四步处理分包和插件目录合并出完整结构很多小程序是分包结构主包只包含框架和公共页面业务页面放在分包里。如果只解包了主包你会发现 pages 目录下只有寥寥几个页面。处理分包时通常要对每个分包文件单独执行解包命令然后把产物目录里的子包资源合并到主包目录中。# 解包子包文件 subpackageA.wxapkg node wuWxapkg.js subpackageA.wxapkg # 解包结束后把子包内 pages 目录合并到主包对应位置 cp -r subpackageA/pages/* demo/pages/合并之后还要改 app.json因为分包页面资源虽然搬到了主包目录下但页面路径注册信息仍保留在子包的 app.json 里需要手动把 subPackages 配置段与主包配置合并。常见做法是以主包 app.json 为基底把子包的 pages 路径追加进对应字段。注意某些工具脚本会尝试自动合并但自动合并经常漏掉独立分包配置建议还是手动核对。如果包内包含插件文件插件同样有独立目录。插件的解包逻辑与普通页面一致但产物目录里会多出 plugin.json 和 plugin.js 这类文件它们通常集中在 plugin 目录下。对做页面评估的人来说插件目录一般不需要深究但如果你要完整还原跳转关系就需要把插件暴露的接口文件也读一遍。4. 读懂反编译产物从目录结构到页面逻辑的还原方法4.1 产物目录长什么样每个文件承担什么角色解包并美化后目录结构会和常见小程序工程非常接近外层有 app.js、app.json、app.wxsspages 目录下按页面路径组织每个页面的 js/json/wxml/wxss。不过要注意这里的 wxml 文件并不一定是原始标签语法它可能是编译后的模板函数形态具体取决于打包工具版本和脚本的还原能力。实际的还原产物中你会看到三种形态的文件。第一类是 .json 文件它是完整的配置数据几乎没有丢失页面标题、导航栏颜色、组件引用配置都能从这里直接读到。第二类是 .js 文件经过美化后逻辑可读但变量名是混淆后的短名。第三类是模板相关文件这是还原误差最大的区域。理解这三类文件的还原程度差异能帮你快速判断哪些内容可以直接抄作业哪些需要二次分析。4.2 从 config 和 Page 构造器里找回页面核心逻辑页面的核心逻辑主要集中在 JS 文件的 Page 构造器调用里。还原后的代码通常会保留Page({ data: {...}, onLoad: function() {...} })这样的结构虽然 data 里的字段名可能被压缩但整体调用关系是完整的。读页面 JS 的顺序有讲究先看 data 字段它决定页面初始渲染数据再看 onLoad 和 onShow它决定数据从哪里来比如是请求接口还是读取本地缓存最后看事件处理函数它决定用户交互的响应路径。有些混淆严重的包会把方法名改成 t、e、n 这类单字母这时可以结合模板里的事件绑定属性反查对应函数模板中bindtapt和 JS 中的t: function() {}是能对应上的。如果还原后的页面 JS 里看不到清晰的 Page 结构而是把页面逻辑封装成了某个工厂函数调用那就需要用字符串搜索去定位。常见做法是搜索页面路径名因为路由注册和跳转参数里一定会出现页面路径字符串顺着字符串能找到对应的注册入口。4.3 模板函数还原把编译产物映射成可读 WXML模板还原是误差最明显的环节但也不是完全没有办法。打包后的模板常见形态是一个大函数调用参数里包含节点类型、属性对象和子节点数组。这类结构可以用一个简单的 Node 脚本做二次转换把函数调用映射成类 WXML 标签文本。// 简单的模板函数转标签脚本可处理大部分静态结构 const fs require(fs); function convertNode(node, indent) { const spaces .repeat(indent); if (typeof node string) { return ${spaces}${node}; } const type node.type || view; const attrs node.attrs || {}; const attrStr Object.keys(attrs) .map(k ${k}${attrs[k]}) .join( ); const children (node.children || []) .map(child convertNode(child, indent 2)) .join(\n); return ${spaces}${type} ${attrStr}\n${children}\n${spaces}/${type}; } // 读取并转换 const raw fs.readFileSync(process.argv[2], utf8); const fakeRoot { type: view, attrs: {}, children: [raw] }; console.log(convertNode(fakeRoot, 0));这段脚本的原理很简单把模板函数里的对象数组当作虚拟 DOM 处理递归输出标签结构。它处理不了复杂的条件渲染指令但面对静态页面骨架还原出的结果已经足够阅读。参数上脚本接收一个文件路径作为输入输出格式化后的类 WXML 文本。使用前先手动打开文件确认节点对象里 type 和 attrs 字段的命名不同脚本版本字段名可能不同如果不一致改一下字段读取逻辑即可。注意这类二次转换的输出不能直接放进开发者工具运行因为它缺少编译指令的语义还原。它的价值在于阅读让你知道页面上有哪些节点、每个节点绑定了哪些事件、事件参数又指向哪些数据字段。配合页面 JS就能拼出完整的交互链路。4.4 样式表还原与字体图标资源处理样式文件的还原相对顺滑因为 wxss 经过编译后的结构不像 JS 那样重度混淆通常是规则块顺序打乱和压缩合并字段名和属性值都保留完整。打开还原后的 wxss你可以直接看到类名、颜色值、尺寸值。比较麻烦的是字体图标打包时字体文件会以 base64 的形式嵌在样式里解包产物里没有独立的字体文件但样式里的font-face定义还在可以把 base64 内容提取出来手动转成文件。提取 base64 字体内容时建议直接在 CSS 里搜索font-face然后把 src 字段里的 data 值复制出来用一行命令解码保存为字体文件。这个操作用于还原视觉细节如果只关心逻辑和页面结构可以跳过。5. 反编译避坑指南5 个高频问题与实际排查记录5.1 解包命令报 Cannot find module但 npm install 没有报错现象执行node wuWxapkg.js demo.wxapkg时提示某个依赖模块找不到可明明已经执行过 npm install。原因wxappUnpacker 是一个脚本集不同入口脚本依赖的模块并不完全一致npm install 安装的是 package.json 里声明的依赖但个别入口脚本引用了未声明的模块。解决看报错信息中的模块名单独补装比如npm install js-beautify然后重新执行。不用重新安装全部依赖环境没有坏只是缺一个声明。5.2 解包后产物目录是空的脚本没有报错但什么都没有输出现象命令执行了控制台也没有错误信息但打开输出目录发现只有几个空文件夹没有实际文件。原因没有走解密分支。部分包虽然文件头是常规协议但文件内容经过了简单的加密处理解包脚本只拆出了容器外壳需要加入-d参数触发内容解密。解决用node wuWxapkg.js -d demo.wxapkg重新解包。如果还是没有内容检查文件头是不是非标准变种可以用xxd对比已知正常包的头部结构。5.3 Node.js 版本过高导致解析器报错或产物不完整现象在较新版本的 Node 环境下esprima 解析某些包含特殊字符的 JS 文件时直接抛错或者还原出的 JS 文件比预期少了一大截。原因esprima 的旧版本与新 Node 的引擎兼容性存在差异某些语法分支在 V8 引擎升级后走入了错误的异常路径。解决切换到 v14.x 版本运行脚本。如果是通过 nvm 管理版本直接用nvm use 14。如果必须留在新版 Node可以尝试把脚本中引用的 esprima 升级到较新版本但要注意它与脚本里 AST 遍历逻辑的兼容性升级后可能出现新的解析差异。5.4 子包合并后页面路径跳转 404现象把所有分包解包并把 pages 目录合并到主包后运行时部分页面路径访问不到控制台输出页面 route 找不到的提示。原因app.json 里的 subPackages 字段还是旧配置别人访问子包页面时通过主包框架跳转实际路径没有注册进主包的页面列表。解决合并 app.json 中的分包字段把每个分包的 root 前缀与 pages 路径拼接完整补进主包的 pages 数组。注意独立分包和普通分包的处理方式略有不同独立分包要保持自己的 app.json 配置不能简单合并。5.5 还原后的 WXML 里出现大量冗余空节点现象模板二次还原时输出结果里有很多空的 view 标签层级深且实际页面上看不出任何内容。原因模板编译产物中会包含空白字符节点和注释节点这些节点在原生渲染时被忽略了但直接转换时没有被过滤。解决在转换脚本里增加过滤逻辑遇到空字符串节点直接跳过遇到属性集合全空的节点且没有子节点时也跳过。这个操作能减少一半无效输出读模板时不会眼花。6. 进阶技巧批量解包、结果验证与最小化还原习惯当你要处理的包不止一个时手敲命令就不现实了。一个简单的批量脚本能减轻工作量它遍历目录下所有 wxapkg 文件并逐个调用解包逻辑。#!/bin/bash # 批量解包当前目录下所有 wxapkg 文件 for f in *.wxapkg; do echo unpacking $f ... node wuWxapkg.js $f done这段脚本适合文件都集中在同一目录的场景.wxapkg通配符会匹配当前目录下所有主包和分包。运行时注意检查子包文件的解包顺序建议先主包后分包这样后续合并目录时主包结构先铺好。如果文件放在不同子目录把 for 循环改成find . -name *.wxapkg再加一个循环体即可。解包还原不是终点验证还原结果是否可用同样关键。我的验证习惯分三步第一步随机挑一个页面对比还原后的 JSON 配置与实际页面标题是否一致第二步从还原后的 WXML 里挑三个事件绑定去代码里确认对应函数存在并且函数里有引用 data 字段第三步用页面路由字符串在整个 JS 产物里搜索看路由是否互相闭合。这三步通过后基本可以放心阅读整包内容。最后说一个踩出来的习惯先跑通一个最小页面再全量还原。别第一次就急着把整个包目录一次性格式化完先选中一个页面目录执行格式化脚本确认输出可读、无报错、无缺漏然后再对全局跑。这个习惯帮我省了很多返工的时间因为单个页面验证能暴露脚本在特定 JS 写法下的兼容问题而全量跑的时候这类问题会被文件数量掩盖住。希望帮到你。本文还有配套的精品资源点击获取