微信小程序反编译原理与实战：从wxapkg解密到代码还原

简介面向小程序开发者与逆向学习者的 wxapkg 解包工具包基于 wxappUnpacker 整理可将 .wxapkg 反编译还原为 .wxml、.wxss、.json、.wxs 等源文件用于学习小程序编译结构、在桌面端复用已授权代码或研究本地运行原理。整个 zip 包仅 13 个文件、39KB主体是 7 个 Node.js 脚本覆盖 wxapkg 主包解包、配置拆分、JS/WXML/WXSS 还原等任务另有 3 份 Markdown 文档和 LICENSE、package.json便于阅读项目说明并快速配置运行。脚本划分清晰、体积紧凑适合新手对照源码边运行边理解解包流程也能让进阶者进一步分析尚未完成的分包拆分逻辑。目前该资源已被 1327 人学习对想快速摸清小程序打包产物结构的开发者来说是一份低成本入门的参考工具。1. 微信小程序反编译包不是黑匣子但开锁的钥匙在客户端里微信小程序反编译本质上不是对抗加密而是对抗格式。小程序发布到用户手机上的不是源码而是一个经过打包、压缩、加密的.wxapkg文件里面的 JS 被编译成语法树再重新生成WXML 被转换成一堆嵌套的函数调用肉眼几乎没法直接看。但小程序必须能在本地运行所以解密、解包、还原所需的信息——包括密钥、包结构、编译规则——全都留在客户端或包本身里。换句话说只要你在微信里能打开这个小程序就一定能从本地找到它的包并且有办法把它还原成接近工程形态的代码。这篇文章写给两类人一类是拿到一个旧项目但丢了源码想从线上包抢救回页面结构和接口逻辑的前端另一类是做安全评估、需要审计第三方小程序是否存在敏感信息泄露的开发者。我会把完整链路拆开包怎么落盘、加密怎么解、文件表怎么解析、编译后的 JS/WXML 怎么还原成可读代码以及每一步最常见的翻车点。整个过程用 Python 为主Node 为辅不需要特殊设备一台能跑微信客户端的电脑就够。2. 反编译前的底牌小程序包结构、加密与密钥2.1 wxapkg 的落盘位置与文件结构小程序在 PC 端微信里打开过一次之后完整代码包就会缓存在本机。路径在不同版本微信里不太一样老版本通常在用户目录的WeChat Files下新版本挪到了xwechat_files之类的目录每个微信账号对应一个带 wxid 的文件夹小程序包在其中的Applet子目录里。判断哪些文件是目标直接看扩展名.wxapkg文件名一般是wx开头的十六进制串或_加数字后缀。拿到包之后第一件事不是急着解密而是用十六进制编辑器或一条 Python 命令看文件头。一个正常的 PC 端 wxapkg 开头是 6 个字节的明文头后面紧跟一大段加密数据。加密数据从偏移 6 开始常见魔数是0xBE 0x00 0x00 0x00如果你看到的文件头完全不是这个形态先别怀疑加密大概率是文件没找对。import struct with open(applet.wxapkg, rb) as f: header f.read(64) print(header[:6].hex()) print(header[6:10].hex())这段代码只做一件事读前 64 字节确认头部结构。header[:6].hex()输出的是明文头正常值是类似06000000 0100这样的形态前 4 字节是首个数据块偏移后 2 字节是标记位header[6:10].hex()输出的是加密区开头如果是be000000说明包结构正常可以进入下一步。看到别的值要么文件损坏要么这个包是某个特殊版本客户端生成的继续往下解密大概率会出乱码。2.2 加密算法是 AES-256-CBC密钥藏在客户端本身PC 端小程序包用的是 AES-256-CBC 加密这基本是公开的事实。算法本身没什么好说的重点是密钥和初始向量从哪来。常见做法是直接在客户端安装目录的静态配置里找不同版本微信维护了不同的密钥和 IV 组合而且不止一套。网上流传的「固定密钥」在某个版本里可能是对的换一个微信版本就解密失败这是所有人第一次反编译时都被坑过的地方。我的做法是维护一个本地的密钥表文件里面按微信版本号或客户端特征值记录多套候选 key 和 iv每次解密失败就换下一套试。密钥来源主要有两个方向一是客户端安装目录下的配置资源文件里直接搜固定字节串二是从客户端运行时内存里提取。对于初学者第二种方式门槛太高我建议先用公开的候选密钥表配合自动遍历的逻辑来碰。import base64 keys [ (密钥A的Base64, IV_A的Base64), (密钥B的Base64, IV_B的Base64), ] for key_b64, iv_b64 in keys: key base64.b64decode(key_b64) iv base64.b64decode(iv_b64) if len(key) 32 and len(iv) 16: print(候选密钥长度匹配: AES-256-CBC) break这里把密钥和 IV 用 Base64 存是为了避免在代码里裸写二进制串实际使用时直接把十六进制或 Base64 字符串填进来就行。校验长度是 AES-256-CBC 最基本的要求key 必须是 32 字节、iv 必须是 16 字节不满足的候选直接丢弃。真正解密时我会把这段逻辑包进循环里解密出来的数据如果开头是0xBE 0x00 0x00 0x00或能直接看到app-config等明文字符串说明密钥对了。2.3 主包、分包、插件包的形态差异一个完整的小程序不一定只有一个包。主包负责启动页和公共逻辑分包按业务拆开按需加载插件包则是独立发布的第三方能力包。反编译时最常见的情况是你在本地找到一堆 wxapkg 文件其中有一个体积明显偏大的是主包剩下几个几十到几百 KB 的是分包光靠文件大小就能做个初步区分。主包和分包的文件表头结构不一样。主包明文头部直接就是文件数量和文件索引分包则多了一段描述信息解析时偏移位置会差几个字节。如果你拿解析主包的逻辑去解析分包常见表现是文件数量读出来是天文数字或者第一个文件名就是乱码。所以解密之后先看头部结构判断主/分包再决定用哪套解析参数。插件包更特殊代码里会引用plugin-private://这样的私有协议路径还原时需要在解析器里做路径映射否则跑起来全是找不到文件的报错。对大多数反编译需求来说插件包可以先丢一边先把主包和分包的页面逻辑还原出来已经能覆盖 90% 以上的诉求。3. 本地解密 wxapkg用 Python 把加密包还原成明文3.1 定位包文件先找到 wxid 目录下的 .wxapkg解密之前先要找到目标包。PC 端微信的小程序包存放目录在不同版本里差异很大我一般先全盘搜*.wxapkg再从结果里按时间、大小筛选。一个小技巧是先在微信里搜索并打开目标小程序随便点一两个页面让分包都被加载一遍然后立刻去小程序目录看最新修改的文件这些就是刚刚运行过的代码包。找到文件后复制到一个干净的目录里不要在微信目录里直接改文件。微信客户端运行中可能会重新下载或覆盖包文件你解了一半文件被替换前面全白干。复制的时候保留文件原始修改时间如果后面解密失败这个时间能帮你判断拿到的是不是最新版本。3.2 解密脚本读头部 1024 字节、解密、校验魔数解密是整个反编译链路里最简单也最容易出玄学问题的一步。核心逻辑就一句话跳过文件开头 6 个字节的明文头从第 7 个字节开始把剩余数据全部用 AES-CBC 解密然后按包结构解析。下面是一个最小可用的解密脚本我按「能跑 能看清每一步」的标准写了注释。from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes import struct def decrypt_wxapkg(data: bytes, key: bytes, iv: bytes) - bytes: # 微信小程序包前6字节为明文头加密数据从偏移6开始 encrypted data[6:] # 对齐到16字节块AES-CBC要求输入长度是块大小的整数倍 block_size 16 if len(encrypted) % block_size ! 0: encrypted encrypted[:-(len(encrypted) % block_size)] cipher Cipher(algorithms.AES(key), modes.CBC(iv)) decryptor cipher.decryptor() plaintext decryptor.update(encrypted) decryptor.finalize() return plaintext with open(applet.wxapkg, rb) as f: raw f.read() # 候选密钥按实际维护的密钥表逐一尝试 key bytes.fromhex(你的密钥十六进制字符串) iv bytes.fromhex(你的IV十六进制字符串) decrypted decrypt_wxapkg(raw, key, iv) # 校验解密结果头部应该是0xBE000000或者能直接看到app-config字样 if decrypted[:4] b\xbe\x00\x00\x00: print(解密成功魔数校验通过) else: print(解密结果头部:, decrypted[:16].hex(), 密钥可能不对) with open(decrypted.bin, wb) as f: f.write(decrypted)data[6:]是解密核心文件前 6 个字节不参与解密len(encrypted) % block_size这行的作用是处理加密数据长度不是 16 倍数的情况实际微信包基本都是对齐好的但脚本里保留这层防御逻辑可以避免个别边界文件让整个流程崩溃。解密后校验0xBE000000是第一个可靠信号看到这个值说明 key 和 iv 都对了。如果解密出来的头部是一串无规律字节直接换下一套候选密钥不要浪费时间检查前面的代码逻辑。3.3 参数说明与失败分支从 PC 端拿包和从手机端拿包的区别手机端小程序包的解密方式和 PC 端不完全一样。Android 上小程序的目录在应用私有数据区没有 root 权限很难直接拖出来iOS 更麻烦基本要依赖备份或越狱环境。所以对没有特殊设备的人来说PC 端微信是唯一靠谱的获取渠道。PC 端拿包有一个天然优势包文件落在普通用户目录权限不受限制路径也好找。PC 端解密失败时九成是密钥版本不匹配。微信升级后密钥表换了旧的候选密钥当然解不开新包。这不算 bug换一套候选密钥重试就是。另有一成情况是包文件本身不完整——小程序可能只下载了外壳业务代码还在懒加载中这时候去把小程序所有页面点一遍再回来重新复制文件往往就完整了。还有一个小坑某些小程序开启了分包预下载本地会同时存在多个版本的同一分包解密时要以文件修改时间最新的为准别拿旧包做分析然后得出一个过时的结论。4. 解析与还原从 wxapkg 提取出 js、json、wxml、wxss4.1 文件表解析主包与分包的文件表头差异解密之后拿到的是一片连续的二进制数据里面包含一个文件索引表和多个文件实体。文件索引表的结构很直接文件数量占 4 字节紧接着是每个文件的条目——文件名长度 4 字节、文件名若干字节、文件内容偏移 4 字节、文件内容长度 4 字节。我写了一个解析器把每个文件按名导出结构体定义见下面的代码。import struct, os def parse_wxapkg(data: bytes, output_dir: str): # 跳过解密后的文件头标记4字节这里从偏移4开始读文件数量 offset 4 file_count struct.unpack_from(I, data, offset)[0] offset 4 os.makedirs(output_dir, exist_okTrue) for _ in range(file_count): name_len struct.unpack_from(I, data, offset)[0] offset 4 name data[offset:offset name_len].decode(utf-8, errorsreplace) offset name_len content_offset struct.unpack_from(I, data, offset)[0] offset 4 content_len struct.unpack_from(I, data, offset)[0] offset 4 file_data data[content_offset:content_offset content_len] safe_name name.lstrip(/).replace(/, os.sep) out_path os.path.join(output_dir, safe_name) os.makedirs(os.path.dirname(out_path), exist_okTrue) with open(out_path, wb) as f: f.write(file_data) print(name, content_len)struct.unpack_from(I, ...)表示按小端序读一个 4 字节无符号整数这是 wxapkg 文件表的标准编码方式errorsreplace是为了防止个别文件名里有非 UTF-8 字节导致整个脚本中断。解析完你会得到一个典型的微信小程序目录app.json、app.js、app.wxss、pages/...、components/...看到这个结构基本就成功了一半。分包解析时头部偏移要额外跳过0xBE000000之后的若干保留字段最简单的办法是先用0xBE000000在明文里定位再从这个位置往后找文件数量字段而不是硬记偏移。原因就是前面说的主分包表头不一致硬编码偏移在分包上必翻车。4.2 前端代码还原编译后 JS 的去混淆与美化导出的 JS 文件不是人能直接看的形态。小程序的 JS 在打包时会经过一层编译源码被解析成抽象语法树再按内部规则重新生成变量名被替换成t, e, n这类短名字符串被合并进一个大数组函数调用变成t(0), t(1)的格式。这个过程类似 JavaScript 的 minify但规则是微信自定义的通用美化工具只能格式化缩进没法还原变量名和字符串引用。我的标准做法分两步先用通用格式化工具做美化再用一套基于 AST 的还原脚本把字符串数组映射回引用位置。具体的 AST 还原逻辑在第六章展开这里先只做格式化。npx js-beautify app-service.js app-service.beauty.jsjs-beautify能把压缩成一行的代码还原成有缩进、有换行的可读形态这是后续所有分析的基础。但你要有预期美化之后代码还是t(0)这种模样阅读体验只能说从「完全不能看」变成「勉强能搜」。真正要理解逻辑还得配合字符串还原和调用关系梳理。格式化后发现某些 JS 文件里什么业务逻辑都没有、只有一堆__wxConfig之类的运行时声明别慌。这是正常的主包的app-service.js通常包含的是小程序框架的初始化代码页面真正的逻辑在按页面拆分的pages/xxx/xxx.js里。找目标逻辑时先看app.json里的页面路由表按路径找文件效率比在巨型 JS 里全文搜索高一个数量级。4.3 WXML/WXSS 还原从模板函数反推页面结构导出文件里没有.wxml对应的是.wxml.js。WXML 在编译阶段被转换成一个巨大的模板函数每一行模板结构都变成了数组或函数调用的形式。还原 WXML 的核心思路是识别模板函数里那些固定的调用形态比如构建元素节点、绑定事件、设置属性然后反向拼接出 XML 字符串。// 还原后的伪代码示意模板函数的结构 function render() { return { tag: view, attrs: { class: container }, children: [ { tag: text, attrs: { bindtap: handleTap }, children: [Hello] } ] }; }这段代码不是真实产物而是还原后期望得到的目标形态一个元素节点描述对象包含标签名、属性集和子节点列表。写还原脚本时我会先在一两个页面上人工对照模板函数的输出和实际渲染效果总结出这套微信版本的元素构建规则再批量套用到所有页面。每个微信版本的规则不完全一致换了版本就要重新校准这也是为什么完全自动化的 WXML 还原工具很难跨版本通用。WXSS 相对简单编译后基本就是加了几个前缀的选择器重写直接格式化就能读。真正影响 WXSS 还原的是rpx单位换算和内置组件样式覆盖这几个不影响阅读只影响你拿还原结果去二次开发时的视觉还原度。所以我会在还原时把rpx保留原样不做任何换算后续要用再按设计稿基准值统一处理。5. 微信小程序反编译避坑五个最常见的翻车现场5.1 解密后头部校验失败内容全是乱码现象解密完写入文件打开一看全是随机字节既没有0xBE000000魔数也看不到任何字符串。原因密钥版本不对最常见于微信客户端升级后旧候选密钥对新包无效。解决扩充密钥候选表从当前版本客户端的配置模块里提取新密钥或者降级微信客户端到密钥匹配的版本。我一般两种方案同时做本地维持一份 5 组左右的候选密钥表遇到新版本先试旧密钥全失败就去客户端目录里提取新密钥。这一步是纯体力和耐心活没有捷径。5.2 包文件找到但解析时文件数量异常现象解密成功、魔数也对但文件表解析出来的第一个文件名就是乱码文件数量巨大或为 0。原因拿主包解析逻辑去解析分包表头偏移对不上或者这个包是插件包结构差异比主分包更大。解决先用0xBE000000魔数定位真正的数据起始点从魔数之后重新解析文件表如果还是不对手工看文件表起始 32 字节的十六进制确认是不是多读或少读了 4 字节的保留字段。5.3 还原出的 WXML 里事件绑定全部丢失现象页面结构还原成功view、text这些节点都在但所有bindtap、catchtouchmove事件绑定没了只剩一堆空壳标签。原因模板函数里事件绑定是通过属性对象和事件表分开注册的只还原节点构建逻辑拿不到事件映射表。解决回头分析模板函数末尾或单独的事件注册区那里通常有一个eventMap之类的对象把事件名和处理函数名对应起来再合并回还原结果。我踩过这个坑之后现在写还原脚本时会把事件表提取作为单独的检查项解析完先确认事件数量不为 0 再继续。5.4 还原后的代码运行起来白屏现象代码目录、文件结构、JS 逻辑看着都合理但把还原结果放到开发者工具里一运行页面直接白屏控制台报错找不到App()或Page()注册。原因还原的是编译后的产物不是工程源码App()和Page()的调用可能在字符串还原时被改动或模块导出方式和原始工程不同。解决不要把还原结果当成可二次开发的工程源码它只能用来分析逻辑和定位接口。真要二次开发正确做法是分析清楚业务逻辑后用原生的App()/Page()重新写页面而不是试图修复还原代码。这个预期如果不提前建立反编译这件事做完你会觉得自己白忙一场。5.5 分包的 app.json 还原后路由缺失现象主包还原后的app.json里只有pages数组的前几项分包页面全找不到但分包文件确实存在。原因分包有自己的app.json配置段和独立的路由表主包app.json里的subPackages字段才是分包路由的入口只还原主配置看不到分包页面。解决解析分包目录时把每个分包的根目录和app.json提取出来再回到主包app.json里找subPackages字段做路由映射。整包的路由全貌 主包 pages 所有 subPackages 下的 pages。6. 进一步反编译技巧把逆向结果变成可读的伪源码6.1 用 AST 恢复被压缩的变量名与字面量字符串前面提到编译后 JS 会变成t(0)加字符串数组的形式不还原就只能靠猜。用 AST 工具可以把字符串数组和调用点关联起来先定位数组定义再找到所有t(index)的调用位置把索引替换成实际字符串。变量名也能恢复一部分——如果你能拿到同版本框架编译后的源码映射可以直接套用映射表拿不到的话至少能把具名函数和模块导出名还原出来阅读体验会有质的提升。const parser require(babel/parser); const traverse require(babel/traverse).default; const generate require(babel/generator).default; const fs require(fs); const code fs.readFileSync(app-service.beauty.js, utf-8); const ast parser.parse(code); // 定位字符串数组定义 traverse(ast, { VariableDeclarator(path) { if (path.node.id.name e path.node.init.type ArrayExpression) { // 把 e[n] 的取下标引用替换为实际字符串字面量 const arr path.node.init.elements.map(el el.value); path.scope.rename(t, str); // 实际逻辑需要按调用形态匹配这里只是框架 arr.forEach((val, idx) { console.log(idx, val); }); } } });这段代码是一个最小检查脚本逻辑是找到字符串数组的声明节点遍历数组元素打印索引和实际字符串的对应关系。这样做的目的是先把字符串表导出来人工确认它是业务字符串还是框架字符串再决定要不要做全量替换。全量替换脚本的复杂度主要在处理嵌套引用有的字符串索引不是直接写数字而是e[t(1)]这种二次间接引用这种情况要递归展开才能拿到最终值。我一般分两轮做先处理直接索引再处理间接引用命中率能做到八成左右。6.2 把分包合并回主包的相对路径映射分包还原最头疼的是路径问题分包内的pages/index/index.js实际运行时的路径是packageA/pages/index/index.js在分析接口时会分不清两个同名文件到底谁是谁。我一般在解析分包时强制把分包根目录名作为路径前缀合并到统一的伪工程目录里。# 伪工程目录结构示例 extracted/ ├─ app.json ├─ app-service.js ├─ packageA/ │ └─ pages/index/index.js └─ packageB/ └─ pages/shop/list.js合并时有一个注意点分包之间的相对路径引用比如../../utils/api.js在合并后路径关系会改变。我会在合并前先扫描所有 JS 文件里的require路径按原包结构计算相对位置合并后再校验一遍是否仍能指向存在文件。路径错了的引用在 IDE 里一看就懂但运行时只会报模块找不到。早校验早省事。6.3 一个习惯逆向之前先看 app.json 的功能范围再决定深度反编译不是越全越好而是越「够用」越好。有一次我拿到一个包全部解密、还原、美化做完猛然发现目标功能在一个不起眼的插件包里主包和分包的分析白做了大半。之后我养成了一个习惯解出app.json的第一时间先看页面路由、分包列表、插件引用判断目标功能到底落在哪个包、哪个页面再针对性地深入。具体的分析路线是先读app.json看页面结构再打开目标页面对应的 JS 文件搜索wx.request、wx.cloud调用拿到接口域名和参数最后用 WXML 反推页面交互逻辑。中间发现包不完整就回到微信里把小程序的页面都点一遍触发分包加载后再拉一次包。用这个顺序做目标明确的话一小时内能出结果没有目标地乱翻翻一天也是一堆半成品。这个习惯帮我省掉了大量无用功也把反编译这件事从「玄学」变成了「按流程走」的活。希望帮到你。本文还有配套的精品资源点击获取