wechat-miniapp-recon

微信小程序逆向分析

使用这个 Skill 对微信小程序反编译代码做聚焦式资产提取。

Outcome

输出一份简洁的逆向分析报告，覆盖：

1. 域名和 base URL 清单
2. 接口和页面端点清单
3. 请求链路和调用锚点
4. 硬编码配置、标识符和疑似 secret
5. 风险说明和置信度空缺

适用场景

用户在以下场景下使用这个 Skill：

• 分析微信小程序反编译后的代码
• 提取域名、接口、API、H5 页面、上传地址、websocket 地址、CDN、OSS、云函数入口
• 查找硬编码的 appid、orgCode、token、secret、key、channel、医院编码、租户编码、城市编码、环境变量、版本号等
• 梳理请求如何构造、签名、加密或路由
• 汇总小程序对外暴露的 Web 资产
• 用户只提供小程序 id 时，先用 wedecode 获取反编译代码，再进入后续分析流程

如果用户需要，也可以把结果输出成 HTML 报告，便于直接打开查看或继续二次整理。

如果来源是 wedecode 的输出，把生成的 bundle 作为主分析面。若本机没有 wedecode，先执行 npm i -g wedecode 安装，并尽量使用最新版本后再进行反编译或重新提取。

Procedure

1. 先拿到反编译代码

如果用户直接给出小程序 id，先通过 wedecode 完成反编译提取，再进入分析。优先确认输出目录、主 bundle、页面目录和 request/service 目录。

如果项目里有 APIdoc、接口文档页、swagger、openapi 或类似说明文件，也要把它们作为接口清单的补充来源，与代码里的真实调用互相校验。

如果用户已经提供了反编译后的目录，直接从这些文件开始。

2. 从具体锚点开始

优先查看这些文件：

• app.js, app-config.json, app.json
• request/request.js, request/.js, service/.js, utils/*.js
• common/vendor.js when request wrappers are bundled there
• Page files that contain obvious business entry points

尽早形成一个局部假设，例如：

• 请求基址初始化于 globalData 或 baseConfig
• API 路径在统一请求封装中拼接
• 敏感常量存放在 globalData、配置模块或压缩后的 service 文件中

在扩大搜索范围前，先对这些锚点做最便宜的验证。

3. 提取域名和资产清单

优先搜索通常保存 Web 资产的字符串和对象属性：

• http:// and https://
• domain, baseUrl, apiDomain, imgDomain, oauthDomain, ws, websocket
• upload, file, oss, cdn, static, assets, h5, webview
• cloud.init, env, service, version

更快的检索方式见 检索模式。

每条发现都记录：

• 字面量值
• 可能用途
• 定义文件
• 直接调用方或消费者（若明显）

按类型归类资产：

• API base domains
• Static or image/CDN domains
• OAuth or SSO domains
• H5 or webview targets
• Cloud or serverless identifiers
• Messaging or websocket endpoints

4. 通过请求链路还原接口

从最近的请求封装向外追踪，不要盲扫所有页面。

推荐顺序：

1. 找到请求封装或 HTTP 客户端
2. 确认 base URL、headers、签名、加密和公共参数如何注入
3. 枚举 service 层方法及其路径
4. 最后再进入调用这些方法的页面补充业务语义

对每个接口尽量提取：

• HTTP 方法
• 路径或路由片段
• 可推导时的完整 URL
• 相关请求参数和 headers
• 鉴权、签名、加密或 token 用法

如果路径是动态拼接的，记录拼接模式，不要凭空猜最终 URL。

5. 提取硬编码信息

重点查看这些位置里的高价值常量：

• App 全局数据
• baseConfig 和 URL 配置文件
• 请求拦截器
• 登录、支付、websocket、消息服务模块
• 仍保留字符串字面量的压缩包

优先提取：

• appid、appId、orgAppId、orgCode、orgCodg、tenant、hospital、cityCode
• channel 标识和产品码
• apiSecret、authCode 占位、key、IV、salt、jump key
• version、dist、env、release channel、功能开关
• template ID、MQTT topic、websocket topic、订阅消息 ID

每个硬编码值都要分类为：

• 业务标识符
• 环境/配置值
• 疑似 secret
• 含义不明确的 token 类值

如果只是标识符，不要过度判断其敏感性。

6. 仅在影响资产判断时检查加密和签名

如果存在加密代码，先回答一个窄问题：

• 它是否隐藏了请求参数、headers 或端点选择？

如果是，再识别：

• 明文输入从哪里进入
• 加密输出附加到哪里
• key 或 IV 是否硬编码
• 签名算法是否暴露固定 salt 或共享 secret

如果加密不影响资产提取，只需简要说明并继续。

7. 结合证据输出报告

按下面的紧凑结构输出结果：

1. Domain inventory
2. Endpoint inventory
3. Hardcoded values
4. Request/signing observations
5. Notable risks or unknowns

每项都要带上文件路径和简短代码上下文作为证据。

质量标准

只有满足以下条件时才算完成：

• 配置或全局数据里明显出现的 base domain 都已覆盖
• 已识别或排除主要请求封装
• 硬编码标识符和疑似 secret 已清晰区分
• 动态或不确定的 URL 已标注为推断而非事实
• 最终报告按资产类型组织，并能回溯到源代码证据

决策规则

• 如果起始文件只是转发配置，就继续往下找真正计算 URL 或发送请求的模块
• 如果有多个候选请求封装，优先选择会注入 header、baseURL 或加密逻辑的那个
• 如果代码严重压缩，先做字面量提取和中心配置恢复，再逐页分析
• 如果公共前端代码中出现 secret，按“客户端暴露常量”报告，不要推断成服务器已失陷

输出格式

除非用户指定别的格式，否则使用下面的报告结构：

1. 域名清单

• 值
• 用途
• 证据

2. 接口清单

• 方法和路径
• 已知时的 base
• 调用方或模块
• 证据

3. 硬编码信息

• 值
• 分类
• 用途
• 证据

4. 备注

• 签名、加密、鉴权流程或不确定项

补充说明

• 优先做窄而可验证的追踪，不要宽泛扫全仓库
• 域名和标识符要保留原始字面量
• 涉及疑似 secret 时要谨慎区分“前端暴露配置”和“可利用凭据”

如果用户要求 HTML 输出，就把最终结果整理为结构化 HTML，而不是纯文本。