本文记录了一次完整的实战过程：拿到一个 142 条请求的海尔小程序 HAR 抓包文件，用 MonkeyCode K2.6 在几分钟内完成深度逆向分析，输出包含签名机制推测、请求依赖链、自动化代码模板的完整报告。
一、背景：为什么需要 HAR 逆向分析
做前端/小程序开发或安全研究的同学都知道，HAR（HTTP Archive）文件是抓包工具导出的标准格式，记录了完整的 HTTP 请求/响应信息。但一个典型的业务场景抓包往往包含上百条请求——静态资源、埋点、心跳、业务接口混在一起，人工梳理非常耗时。
这次我拿到的是一个海尔小程序的答题活动抓包，共 142 条请求，时间跨度 21 秒。目标是：
- 理清业务 API 调用链路
- 分析签名认证机制
- 找出可自动化的接口
- 生成可直接使用的请求代码
如果手动分析，预计需要 2-3 小时。而我用 MonkeyCode K2.6 的 HAR 分析技能，整个过程不到 3 分钟。
二、实战过程
2.1 一键加载分析
将 HAR 文件交给 MonkeyCode K2.6，执行分析指令。系统立即开始处理：
[*] Loading HAR file: 海尔新抓包.har
[*] Loaded 142 entries
[*] 开始深度分析...
[*] 分析完成，耗时 0.02s
0.02 秒完成解析。这背后是 Python 原生处理 + 优化的数据结构遍历，没有冗余的 IO 等待。
2.2 流量全景：一眼看清架构
分析报告首先给出流量统计：
| 指标 | 数值 |
|---|---|
| 总请求数 | 142 |
| 业务请求数 | 63 |
| 独立 Host 数 | 14 |
| 独立路径数 | 30 |
| 签名端点 | 19 |
| 编码端点 | 79 |
| 加密端点 | 14 |
Method 分布：POST 81 次、GET 52 次、OPTIONS 7 次。可以看出这是一个以 POST 为主的 API 密集型小程序。
Status 分布：200 占 65%（93 次），304 占 20%（28 次），204 占 13%（18 次）。整体健康，只有 1 个 404。
2.3 微服务架构识别
K2.6 自动识别出 7 个核心业务域名：
api-cn-sp000162-tz.haierbros.com - 答题核心服务（13 请求）
api-cn-sp0003463-aurvae.haierbros.com - 页面配置服务（24 请求）
api-cn-sp0003463-user.haierbros.com - 用户服务（10 请求）
api-cn-sp000158-alk.haierbros.com - 探索币服务（4 请求）
campaign-mgm-001.haierbros.com - 裂变活动前端（19 请求）
wxmp.haierbros.com - 活动页面（11 请求）
resources.haierbros.com - 静态资源（16 请求）
这直接揭示了系统的微服务拆分方式。不需要手动逐个查看 Host，架构图已经自动生成。
2.4 签名机制深度分析（重点）
这是本次分析最有价值的部分。K2.6 自动检测并解析了签名机制：
发现的签名 Header：
u-signature- 核心签名字段u-timestamp- 时间戳u-request-id- 请求唯一标识u-device-id- 设备标识u-app-code- 应用编码
签名格式识别：
1.1_a8c0fa6e8ac82b62ab45759b075a96e1 ← 带 1.1_ 前缀的 36 位签名
c6683846271595bb69510964020da07a ← 纯 32 位签名
K2.6 基于样本统计，给出了签名算法推测：
| 推测算法 | 置信度 | 依据 |
|---|---|---|
| MD5 | high | 19/19 个签名为 32 位 hex，符合 MD5 特征 |
| Prefixed-Signature | high | 检测到固定前缀 1.1_，格式为 prefix + hash(payload) |
建议实现：签名 = prefix + md5(sorted_params + secret)
这意味着，如果拿到密钥，完全可以重放请求。而密钥通常藏在小程序的 JS 或 WASM 中——报告的第 11 节已经列出了待逆向的文件清单。
2.5 请求依赖链：理清调用顺序
K2.6 新增的请求依赖链分析，自动识别了 63 步调用链路：
| 步骤 | 类型 | 接口 | 依赖 |
|---|---|---|---|
| 5 | auth | wechatMiniAppLogin | - |
| 6 | query | get/userinfo | auth |
| 7 | business | createPrivacyPolicyConsent | auth |
| 10 | query | getPublishedChannel | auth |
| 11 | query | queryExploration | auth |
| 30 | query | game/fission/activity/detail | auth |
类型标注非常清晰：auth（认证）、query（查询）、business（业务）、normal（普通）。一眼就能看出必须先登录，再调其他接口。
2.6 Risk Fields 识别
K2.6 在响应中自动扫描敏感字段，并做了脱敏处理：
POST .../wechatMiniAppLogin [200]: accesstoken
- 上下文: {"accesstoken": "b2****************************f7"}
POST .../getPublishedPage [200]: key
- 上下文: {"key": "ac****ty"}
既保护了敏感信息，又保留了字段上下文，方便理解数据用途。
2.7 自动化代码生成
最后，K2.6 生成了可直接使用的代码模板：
Python Requests 模板：包含签名计算函数框架、请求 ID 生成、完整请求示例。
curl 模板：一键复制即可测试。
参数模板：提取了所有接口的请求参数结构。
三、关键发现：答题接口的安全设计
基于两份 HAR 文件（新抓包 142 条 + 旧抓包 475 条）的交叉分析，K2.6 帮我发现了一个有趣的安全问题：
queryQuestion 接口的响应直接返回了 correctAnswer 字段。
这意味着客户端在展示题目时，就已经收到了正确答案。而 saveUserAnswerRecord 接口只记录答题行为，不验证答案正确性。
业务流变成：
1. getUserAnswerProcess → 获取总题数/当前进度
2. queryQuestion → 获取题目（响应内含 correctAnswer）
3. saveUserAnswerRecord → 提交答案（无需传答案内容，只传 playId + batchNo + questionId）
4. getUserAnswerStatus → 获取排行榜
从自动化角度，这是一个零知识成本的接口——不需要题库，不需要 OCR，直接读取响应中的正确答案即可。
四、MonkeyCode K2.6 的实战表现总结
| 能力维度 | 表现 |
|---|---|
| 解析速度 | 142 条请求 0.02 秒完成分析 |
| 架构识别 | 自动识别 7 个微服务域名、30 个独立路径 |
| 签名分析 | 自动检测 U-Signature 机制，推测 MD5 算法，high 置信度 |
| 依赖链 | 63 步调用链路，自动标注 auth/query/business 类型 |
| Risk 识别 | 自动扫描 accesstoken 等敏感字段，脱敏展示 |
| 代码生成 | 输出 Python/curl 模板、参数模板、自动化框架 |
| 报告质量 | 832 行 Markdown，覆盖 12 个分析维度 |
相比人工分析的优势
- 速度：3 分钟 vs 2-3 小时
- 完整性：不会遗漏任何请求，所有 142 条都被统计和分类
- 一致性：签名分析基于统计样本，不受主观判断影响
- 可追溯：每一步分析都有数据支撑，报告可直接作为文档使用
五、HAR 分析技能的技术亮点
这次使用的 HAR 分析技能包，经过多轮迭代修复，已经相当成熟：
- multipart/form-data 解析：支持文件上传场景（图床 HAR 分析必备）
- 签名样本传递：从检测到报告，签名信息完整保留
- 请求去重：按 method+host+path 去重，避免重复端点干扰
- 算法推测：基于长度/前缀/格式多维度推测签名算法
- 测试覆盖：10 个测试用例保障核心功能稳定
六、结语
这次实战让我深刻感受到：好的 AI 工具不是替代思考，而是把重复性的信息整理工作自动化，让人专注于判断和决策。
K2.6 没有帮我"破解"签名（这仍然需要逆向 JS/WASM），但它用 3 分钟帮我完成了原本需要 3 小时的信息整理工作，并给出了清晰的逆向路径——这就是 AI 辅助开发的价值。
如果你也有 HAR 抓包需要分析，不妨试试这套流程。分析报告可以直接作为技术文档、接口文档或安全评估报告使用。
MonkeyCode官网： monkeycode-ai.com/?ic=019d5da…
本文基于真实抓包数据分析，仅用于技术研究和安全学习。所有敏感信息已脱敏处理。
