发包前参数组装链：别只盯最终包，要看参数从哪来、怎么拼、何时定型

很多人分析协议，一上来就抓最终发出去的包。这没问题，但容易错过关键信息：参数是什么时候定型的、经过了哪些处理、有没有动态生成的部分。真正完整的协议分析，需要把组装链也还原出来。

先说结论：参数组装链决定了你能不能把请求复现出来

一个典型的组装链通常包括：

• 字段收集（从配置、内存、用户输入、前置接口）
• 字段过滤（去掉空值、默认值、敏感字段）
• 字段排序（按 key 字典序、按固定顺序、按自定义规则）
• 字符串拼接（加前缀、加分隔符、加后缀）
• 编码处理（URL 编码、Base64、自定义编码）
• 签名生成（把拼接结果做摘要或加密）
• 最终组装（把原始字段、签名、时间戳等拼成最终包）

你如果只盯着最终包，很容易漏掉中间某一步的自定义逻辑。

第一步：先找到参数从哪来

不同来源的参数，稳定性和可控性完全不同：

• 硬编码配置
• 运行时内存
• 用户输入
• 前置接口返回
• 设备信息动态采集
• 时间/随机数动态生成

来源搞清楚，你才知道哪些字段可以固定，哪些必须动态处理。

第二步：跟踪参数怎么被加工

最常见的加工包括：

• 类型转换（int 转 string、bool 转 0/1）
• 空值处理（跳过、留空、填默认值）
• 排序规则（字典序、插入序、自定义）
• 拼接格式（key=value、key:value、纯 value 拼接）
• 嵌套结构（JSON、Protobuf、自定义二进制）

每一步都可能有项目自定义的逻辑，不能假设是标准做法。

第三步：确认参数什么时候定型

关键问题：

• 参数是在业务逻辑层就定好了，还是在发包前最后一刻才组装？
• 有没有中间缓存或临时结构？
• 签名是在组装前生成还是组装后生成？

定型时机决定了你 hook 或 patch 的最佳位置。

最容易犯的错误

• 只抓最终包，不还原组装过程
• 假设排序、拼接、编码都是标准做法
• 忽略了某些字段的动态来源
• 没确认签名生成时机

我更推荐的追踪顺序

1. 找到发包函数入口
2. 往前追溯参数收集点
3. 跟踪参数加工链
4. 确认定型时机和最终组装逻辑

这样做的好处是：你不仅能复现请求，还能理解为什么这样设计。

结尾

参数组装链分析真正值钱的地方，在于它能把“一个看似随机的请求包”还原成一条清晰的处理流水线。一旦你把这条线理顺，不管是复现、篡改还是构造新请求，都会变得有章可循。