小程序渗透-从抓不到包到反编译出源码

移动安全 · 小程序篇

大部分软件联网时，会先去读操作系统的代理设置（Windows 上是 Internet 选项里的那个 127.0.0.1:8080），看到挂了代理，就自觉把请求发过去。这是「合作式」的。

微信小程序（跑在 WeChatAppEx.exe 这个进程里）不合作。它在构造网络请求时直接走物理网卡发包，压根不看你设的系统代理。

所以问题从「代理怎么配」变成了「怎么在不改系统设置的前提下，把这个进程的流量劫走」。

答案是用驱动层的工具。Proxifier 不是靠代理协议工作，它把自己挂进系统网络栈（WFP/LSP 架构），只要目标进程想发 TCP 包，就在内核层面被截下来，打包后强行塞给你指定的端口——微信愿不愿意都一样。

图 1｜区别不在配置，在于「谁说了算」

装完之后有三步，第二步错了会非常难受。

第一步，加代理服务器。地址 127.0.0.1，端口 8080，协议 HTTPS。

第二步，兜底规则设成 Direct。添加代理时它会弹一个窗，问你要不要把「整台电脑的流量」都走这个代理。点否。点了是，微信、音乐、游戏、系统更新全灌进 Burp，界面瞬间被无关请求刷屏，有些软件还会因为证书问题直接断网。

点否之后，规则列表最下面那条 Default 保持 Direct，你自己再写一条精准的。

第三步，新建规则，只绑小程序进程。打开任意一个小程序，任务管理器里找 WeChatAppEx.exe，把这条规则的应用指向它，动作选 Proxy HTTPS。这样只有小程序走 Burp，其他一切照旧。

剩下就是证书。小程序走 HTTPS，不装 CA 只能看到 CONNECT。从 Burp 导出证书装进系统受信任根，或者用「小黄鸟」这类工具代为安装并勾选小程序范围，都行。

配好之后还是会遇到几种「明明配了却没流量」的情况，按顺序排：

· 规则没绑对进程。微信有多个进程：WeChat.exe 是主程序，WeChatAppEx.exe 才是跑小程序的容器。绑错了等于没绑。判断方法：打开小程序时看任务管理器里新冒出来的那个进程。

· Proxifier 没生效。它需要驱动权限，某些安全软件会拦它的驱动加载。这时规则列表里一切正常，实际一个包也没劫到。看 Proxifier 自己的连接日志，有没有 WeChatAppEx.exe 的记录，一眼就能确认。

· 证书没装进对的位置。Windows 上要装进「受信任的根证书颁发机构」，装到「个人」里浏览器仍会报警。小程序同理。

· 双向证书校验。少数金融类小程序会校验客户端证书，这种情况抓包工具直接握手失败。表现是连不上、超时，而不是看到明文。遇到这类就别在抓包上耗了，转去拆包看源码。

小程序本质上就是个前端壳 + 后端 API。所以漏洞形态和 Web 高度重合，只是入口变成了一个个 JSON 接口。实战里高频的是这四类。

一、参数遍历。某个门店详情接口是 /api/v1/storeDetail/detail.json?hall_id=1，把 hall_id 改成 2、3、4 一路跑下去，能拿到全套门店信息——包括没对外开放的那些。

二、金额篡改。预订类小程序在提交订单那一步抓包，把 total_price 改成 0 或 0.01。服务端如果不复核，就是白住一晚。

三、上传点。头像上传最典型。把文件名改成 x.php 或 x.html，Content-Type 仍写 image/png，前面塞一个 PNG 头做伪装。返回路径直接能访问就是大问题。

四、前端信任。很多小程序把「是不是会员」这种判断放在前端，改个本地变量界面上就变了——但真正值钱的是后端跟着一起信了。

这四类的共同点：参数从客户端来，服务端没复核。和 Web 一模一样，只是换了皮。

总有抓不到的情况：证书校验做了双向绑定、流量走了私有协议、或者你根本没拿到那个页面的入口。

这时候换一条路——把小程序包本身拆开。微信在本地会把小程序下载成 .wxapkg 包，包是加密的，需要先脱壳再解包。

工具有现成的，wxapkg（wux1an 那个）双击就能用，会自动扫本机小程序目录。

包在哪？大致是这个路径：

C:\Users\用户名\AppData\Roaming\Tencent\xwechat\radium\users\   <一串哈希>\Applet\packages

那串哈希每台机器都不一样，照抄别人的路径一定找不到。自己进 Applet/packages 里翻，按修改时间排序，最近打开的那个就在最上面。

目录里是一堆以 appid 命名的文件夹，怎么知道哪个对应哪个小程序？把 appid 拼到这个地址在微信里打开：

https://mp.weixin.qq.com/mp/waerrpage?appid=小程序AppID

图 2｜五步走完，手里就有源码和接口清单了

解出来的目录会成对出现 appservice 和 webview，这是微信的双线程模型（逻辑层和渲染层分离）。审计只看逻辑层就够。

图 3｜按这个顺序看，一小时能摸清一个陌生小程序

顺序建议是：先 app-config.json，再 app-service.js。

app-config.json 是一个页面地图。里面的 pages 数组列了这个小程序所有页面路径。重点看有没有 pages/admin/、pages/test/、pages/internal/ 这类——菜单上没入口的页面，常常没做鉴权。

app-service.js 是接口地图。用 VS Code 全局搜（Ctrl+Shift+F），关键词就两个：wx.request 和 auth。所有联网调用都从 wx.request 出去，翻几屏就能把 baseURL、接口路径、请求头里的鉴权方式全抓出来。有时候还能翻到硬编码的 AppSecret、第三方 Key。

这一步的产出比抓包更完整：抓包只能看到你走过的页面，源码能看到它一共有多少页面。

翻接口的时候经常遇到这种情况：请求体是一串 Base64，Burp 里改什么都看不懂。

第一反应不应该是「搞不定」，而是去前端找密钥。加密和解密都在客户端完成，密钥必须有地方存——绝大多数情况就写在同一份 JS 里。

做法：在 Burp 里看到加密后的样子，回到源码里全局搜那个加解密函数的特征串（或者搜 CryptoJS、AES、encrypt），定位到函数体，往上翻几行，key 和 iv 就在那。

我在一个小程序里遇到的是一段 AES-CBC，key 和 iv 都是写死的十六位字符，直接拿 Node 跑一遍就能复现加解密。之后所有请求都能明文改。

还有一个比反编译更省事的办法：直接开小程序自己的开发者工具（就是那个 F12）。

原理说穿了不复杂——微信 PC 端本质是个基于 Chromium 的套壳浏览器，小程序跑在这个浏览器里。所谓「强开」，就是想办法把官方隐藏或禁用的 devtools 接口重新激活。

常见工具有两种思路：

动态注入：用 Frida 在微信运行时把内部配置改掉，强制打开 devtools。不修改微信文件，版本升级后一般还能用，是主流做法。

静态补丁：替换打过补丁的 WeChatWin.dll。对版本依赖极强，微信一更新就失效，只能当兜底。

打开之后能做什么？在 Console 里可以直接调用小程序的 JS 方法、改本地存储、看所有网络请求（包括没走代理的那些）、查当前页面的 data 对象。很多前端校验逻辑，在这里改一个变量就绕过去了，比抓包改包快得多。

但要清楚一件事：这只是手段。真正要验证的是服务端有没有跟着一起信。前端把 isVip 改成 true 界面上变会员了，不算漏洞；后端订单接口认了这个 true，才算。

做资产梳理时会碰到一类怪东西：企业名下确实注册了这个小程序，但微信里搜不到，只能靠二维码或内部链接打开。业内叫影子小程序。

形成原因很实际——后台有个「禁止被搜索」的开关。企业做内部考勤、经销商下单、活动测试、高管看板这类业务时会打开它。结果就是：蓝队梳理自己的互联网资产时，往往把这些漏了。

怎么找？四条路：

· ICP 备案：按主体查名下备案的小程序

· 小蓝本这类企业资产平台

· 反编译包内线索：配置文件、返回包里经常夹带其他 appid

· 公众号抓包：服务菜单、图文跳转里都带着 appid

图 4｜「搜不到」和「不可达」是两件事

拿到 appid 之后，微信有个官方接口能从任意小程序跳过去：

wx.navigateToMiniProgram({   appId: '目标小程序 appid',   path: 'pages/index/index?id=1',   extraData: { foo: 'bar' }, })

再结合前面反编译拿到的路由清单，把 appid + 每条路由拼起来逐条访问。菜单里没入口的页面，这么一撞就出来了。

有个细节值得记：从一个已上线的小程序里往往能挖出十几个 appid。这意味着攻击面从「一个小程序」变成「一家公司的整个小程序矩阵」。资产梳理时这一步的性价比极高。

· 反编译顺手找真实 IP。源码里除了 api. 域名，还要留意 ws.、wss.、mqtt. 开头的地址，那些经常直连 IP 和非常规端口，WAF 都挂不上。

· 换端口直连。拿到 IP 之后跑一遍全端口，8080、7001 这类端口上如果挂着没做防护的中间件，往往比主站好打。

· 记住服务端才是防线。小程序的所有本地逻辑都能被改。做防守方视角的加固时，优先级应该是：接口鉴权 > 参数服务端复核 > 代码混淆加固。前两个不做，第三个只是让攻击者多花十分钟。

· 记录 appid 与路由清单。测完把「appid + 路由 + 接口」整理成表，这是下一次复测的基线。没有这张表，三个月后你等于重新开始。

把上面这些串成一个实际流程，大概是这样的：

先拿一个目标小程序，配好 Proxifier 规则，把所有页面点一遍，让 Burp 里攒下几十条请求。然后按域名归堆，挑出「业务性强」的那几个接口——订单、支付、会员、资料修改。这些是逻辑漏洞的高发区，也是扫描器永远碰不到的地方。

接着做两件事：改参数和改身份。改参数是遍历 ID、改金额、加字段；改身份是拿两个账号对比同一接口的返回。前者找越权和篡改，后者找水平越权。

如果请求体加密了，或者接口清单不全，就转去反编译。解包之后先读 app-config.json 拿页面全集，再全局搜 wx.request 拿接口全集，两边一比，你会发现有些页面在界面上根本没有入口。这些页面往往就是最薄的地方。

最后别忘了资产这条线：从一个 appid 出发，往往能挖出同一主体下的其他小程序。测完一个，把 appid 清单整理出来，这批目标够你研究很久。

小程序这个方向，技术难度其实不高。门槛全在环境：能不能抓到包、能不能拆开包。这两件解决之后，剩下的就是 Web 那套。

真正难的是意识——很多人压根没把小程序算进资产范围里。那些搜不到的、藏在服务菜单后面的、挂在经销商渠道里的，才是最容易出问题的地方。

你手上有测试授权的话，先挑一个自己常用的小程序，把包抓出来，看看它的接口长什么样。这一步做完，后面全是熟路。