AI 协作下的小程序渗透测试指北

前言

这段时间找了一份实习，也陆续做了几个项目。工作一忙，博客就一直没顾上更新，手里已经攒了好几篇想写的东西，后面应该会找一段时间集中补一补。

最近在一些渗透测试项目里，我越来越明显地感觉到，AI 已经不只是一个“帮我查查资料”的工具了。很多时候，它更像是一个可以一起拆问题、看代码、梳理思路的 partner。尤其是在小程序测试这种信息量很大、流程又比较碎的场景里，AI 能参与的地方其实比我一开始想象得多。

所以这篇文章就想先做一个阶段性的记录：我现在是怎么把 AI 放进小程序测试流程里的，它大概能做到什么程度，以及这段时间我从里面总结出了一些什么经验。

序言

如果按比较传统的方式来看，小程序测试大概会从几个固定动作开始。

首先是获取小程序本体，然后尝试定位相关文件并进行反编译。这个过程中可能会用到一些 GitHub 上的脚本。反编译之后，核心内容通常会集中在 app-service.js 这类文件里，后续很多静态分析工作也会围绕它展开。

接下来就是动态测试。我们一般会先手动点一遍小程序，看看它有哪些功能点、页面之间怎么跳转、不同角色或状态下会不会出现不一样的逻辑。同时，还要配置好抓包环境，把小程序运行过程中的流量拿出来看。这些基本上都是以前做小程序测试时绕不开的准备工作。

再往后，比较麻烦的地方通常会出现在通信加密上。有些小程序的请求参数、响应内容或者签名逻辑都不是明文的。遇到这种情况，如果我们一时没办法直接把加解密过程完整逆出来，就可能会借助 JSRPC 之类的方式，远程调用小程序里的加解密函数：一边断点调试，一边拿到明文，再把自己构造好的数据送回加密函数里，让它帮我们完成后续请求。

这些流程本身并不新，但最近这一两个月我感受比较明显的是：AI 的上下文能力、响应速度和推理能力都比之前好用了很多。放到小程序测试里，它能参与的事情也越来越多。

以前很多需要人一点点翻代码、对接口、整理参数的工作，现在可以先交给 AI 做一轮粗筛和梳理。它不一定能够做到完全的自动化测试，但能够极大程度地加速我们的测试速度，提供更完整的测试面梳理，ROI 确实很高。

所以这篇文章不是想聊一个很宏大的话题，而是想用我最近做小程序测试的一些实际感受，记录一下 AI 到底能帮上哪些忙，以及它比较适合放在哪些环节里。

一、小程序测试过程中会遇到什么问题

一般来说，真正开始测一个小程序之后，最常遇到的不是某一个单点问题，而是一堆事情同时压过来：代码不好读、流量不好抓、参数不好还原、业务逻辑也不一定能靠页面点出来。下面这些就是我最近遇到比较多的情况。

1. 反编译后的代码不太好读

小程序反编译之后，经常会出现多个包，文件也比较分散。你要是直接从目录里一点点翻，体验其实不太好。

另外，有些小程序的 JS 代码还会做混淆，人工审起来很难搞。面对这种情况，我一般会先做一轮代码格式化和简单的反混淆，至少让整体结构变得更容易读。

下面这个网站我实际用过几次，主要是用来美化 JS 代码结构，也能处理一些简单的反混淆场景：

WebCrack

2. 抓包环境需要反复折腾

拿到小程序之后，下一步通常就是抓包。关于小程序抓包，网上能找到的方案很多，不同平台也有不同的处理方式。

比如在 Windows 平台下，可以通过 Proxifier 这类工具把小程序进程的流量转发到 Burp 的代理上。安卓平台会麻烦一些，主要问题在证书信任上。没有 root 的设备会受到系统版本和证书策略的限制；如果是 root 过的设备，就可以通过系统证书、Magisk 模块，或者一些 Hook 类插件来处理证书信任问题。

另外还有一个容易被忽略的点：有些小程序会针对 iOS 或 macOS 做专门的功能适配。也就是说，只在一个平台上点一遍，可能看不到完整的业务面。所以如果想测得更全面，一方面要看静态文件，另一方面也要尽量在多个设备和平台之间切换验证。

3. 抓到包之后，数据也不一定能直接看懂

就算抓包成功，也不代表事情就简单了。有些小程序会有自己的一套加密和验签逻辑。请求参数被改过之后，签名可能就对不上；后端一校验发现不一致，请求直接就被丢掉了。

从我目前遇到的情况看，加密逻辑大致可以分成两类：一类是对称加密，一类是非对称加密。

对称加密相对好处理一些。做代码审计的时候，通常比较容易顺着调用链找到加密逻辑，后面复现起来也会轻松一点。真正麻烦的是非对称加密，因为这时候我们很难直接从流量里看到完整的明文数据结构。

这种情况下，传统做法一般还是回到 JS 调试：在加密函数之前下断点，观察加密前的数据长什么样。后面我会放一个微信小程序强开 F12 调试的 GitHub 项目链接，这类工具在某些场景里还是挺有用的。

不过这也是 AI 开始变得有价值的地方。以前我们可能要自己一点点追调用链、看参数、猜业务逻辑；现在可以先让 AI 帮忙分析静态代码结构，把功能点、接口、参数和业务调用关系先整理出来。它不能保证一次就完全正确，但至少能帮我们把很多隐藏在代码里的信息先捞出来，后续人工验证会轻松很多。

二、这些问题如何解决？

代码美化

VS Code 这个编辑器对于 JS 自动解析并且进行美化的长度是有限制的。反编译后的代码不好读的话，我们优先去上面提到的网站上进行一下格式美化，这样子方便我们在初期审查的时候阅读，后期需要定位具体代码片段的时候也方便查看。

AI 主导的静态代码审计和辅助脚本编写

针对于上面说到的那种，我们发现它存在通信的一个加密，没办法直接获取到明文进行测试，这个时候就要使用到 AI 了。

我在这次的项目中使用最多的是 OpenAI 的 Codex 搭配 GPT-4.5-xhigh，师傅们有用别的模型的话也可以，这里我主要说的就是一个思路。

针对这种情况，我们需要 AI 做到以下几点：

这一轮我希望 AI 先做的事

• 分析完整的代码结构，并且给出从中提取到的所有接口，以及通过代码的业务逻辑分析出来的接口所需要的各种参数，最好能够给出贴合业务实际的拟真测试数据。目的是能让我们在它即便是非对称加密通信的前提下，也能对所需要测试的接口进行测试。
• 如果小程序的通信逻辑中存在加密或者数据包计算签名这种逻辑，你需要结合 Burp 插件 Galaxy 的 Java 模式脚本编写样例，编写出所需的自动化加解密签名计算脚本。
• 完成以上的分析之后，将成果输出成 Markdown 格式的文档，并且给出具体的使用方法。

我们将 AI 放在工作目录下之后，就可以把这些目的性的短语，结合当前业务的实际，直接一股脑地发送给 AI，然后让它自己先去跑第一轮任务，之后不断进行测试直到我们的项目能够使用。

需要注意的一点是，如果你认为这一轮的回答有可能撞到上下文长度限制触发对话压缩的话，最好能够主动触发一次总结然后再进行下一步的操作。这么做是因为目前阶段 AI 在上下文长度达到 80% 左右就会开始出现幻觉，而且这一区间内的 AI 输出质量也会显著降低。

这个过程实际上后面我复用了很多，所以我最终写出来了一个 skill 给它，就是让它发现我需要针对小程序进行测试的时候，就主动去跑这样一套业务逻辑。

AI 完全跑完这一轮的任务之后，你应该就已经可以对整个小程序的业务逻辑，以及它中间会用到什么样子的数据包有一个清晰的认知。这样子就方便我们在之后的手动测试过程中有一个把控，能够知道测试范围是否完全覆盖到了每一个功能点。

没图没真相，下面就是我在实际渗透中使用 AI 的一些产出，我在尽可能保证观感的前提下进行了必要的信息脱敏。

• 静态分析
• 加解密脚本

进行第一步的静态分析方便我们理清程序的具体逻辑和各个参数对应的具体含义。

自动化的生成加解密脚本

针对非对称加密怎么做？

针对非对称加密我们需要先能够对小程序进行调试。这里我使用的是这个项目：

WMPFDebugger

关于环境的配置其实有些麻烦，我这边是给 AI 一台新的虚拟机，然后将所有可能需要用到的程序的安装包放在上面，让它自己参考仓库的 README 来进行配置并且进行测试。

配置好后就能在浏览器中对小程序进行调试

通过这个项目，结合之前分析出来的非对称加密逻辑和编写出来的自动加密脚本，拿到加密前参数后，我们就可以进行明文的 Burp 测试了。

What’s More

总结一下我们做了什么？实现了什么？可以继续做什么？

通过反编译小程序获取到源码 → AI 主动分析源码内容，还原功能逻辑 → 自动化地解决通信加解密问题 → 落实成为规范化的成果文档，方便人工进行进一步的手工测试。

那么，我们现在的这一整个工作流还能够继续拓展。比如让 AI 自动化地构建测试样例，然后在流量经过我们 Burp 代理的前提下，自动化地去请求小程序的后端服务进行测试。也可以结合师傅们自己的知识库，让 AI 能够打出一些非常规的测试思路。

除了小程序还适用什么？

其实可以发现，除了反编译获取源码和强开 F12 进行 JS 调试外，我们所做的事情完全可以不局限于小程序。比如针对 Vue 框架的网站——这种前端只负责展示数据并且与后端通信的逻辑都存在于 JS 文件中的网站。我们完全可以在手动爬取到所有的 JS 之后复用这一套测试流程。

在实际的使用中我针对 Vue 类型的网站也进行了测试并且产出了不少成果。

补充：小程序如何反编译？

无脑使用 Tscan 就行。

TscanPlus

在软件中找到小程序反编译功能，然后进行简单配置。之后在电脑上打开对应的小程序即可一键完成反编译和基本的敏感信息提取。这个玩意基本就图一乐，纯规则匹配来的，我是从来没在这个里面匹配到过有价值的信息。

点击查看 Tscan 反编译截图

然后就能得到一堆反编译后的文件了，从文件大小也能看出来我们应该重点关注 app-service.js。

写在后面

也是在工作中与 AI 浅浅的合作后我才发现，AI 在现阶段对我这种水平的网安 er 来说真的能够将自身的能力范围扩大很多。

对于网站 JS 调试不会的话有浏览器的 MCP；对于逆向完全不懂也没关系，IDA-MCP 配合 Claude 能够达到的效果完全比你老老实实从零开始学习逆向来得更方便；域渗透？微软推出的 Microsoft Security Copilot agents 已经能够在一些安全场景里自动化辅助发现和处置问题，我即使学得再多，也很难比微软自己的 AI 更了解 Windows。

包括现在国外的一些大的研究机构也都在推出自己的红队 agent，甚至还有力大砖飞的 Claude Mythos Preview 这种安全模型，它能够达到的水平可能我们再怎么学也很难企及。

前些年大家还在说，一个好的 prompt 对 AI 生成内容有多重要；最近这段时间，话题又变成了各种 skill 怎么搭配。我的感觉反而是：这些东西当然有用，但它们可能没有我们想象得那么长期。

模型的参数量、上下文长度和工具调用能力一直在往前走。今天我们给模型写的 prompt 或 skill，也许现在能提高效率，但过一段时间之后，反而可能变成一种限制。模型靠自身能力，已经越来越能直接解决我们面对的问题，而不一定需要完全依赖我们提前写好的那套东西。

用好 AI 的关键

所以我现在越来越觉得，用好 AI 最重要的不是收集各种 skill，也不只是会写 prompt，而是一种拆分任务的能力。比起“我应该具体怎么操作”，我们更需要知道的是：在当前这种情况下，我应该先做什么、做到什么程度、哪些结果需要人工再验证。AI 很多时候不知道下一步该往哪走，但我们稍微给它一个方向，它就能主动结合已有知识，把目标往前推。

不过有点讽刺的是，这种“知道在当前的这种情况下我应该去做些什么”的能力和我之前提到的所谓 skill 一样，感觉也是一种能靠模型力大砖飞替代的东西。

---

文笔非常烂，文章的东西本身也没有多么的新颖，只是用来记录我最近干的一些事儿和思考的一些东西。如果能有师傅读到这里的话，不妨也说一下自己的看法。另外，如果有更好的结合 AI 进行自动化渗透测试的思路或者方法，也都可以分享一下。