签名定位思路：别盯着 sign 字符串，先找“请求何时变合法”

很多人做接口逆向，一看见请求里有 sign、sig、token、auth 这种字段，就立刻开始全局搜字符串。这个动作不是完全没价值，但经常效率一般。因为真正让请求“合法”的，往往不是某个字段名字，而是一整段在发送前完成的约束链路。

先说结论：签名定位不是找一个字段，而是找“合法性生成点”

你真正要回答的问题其实是：

• 哪些参数进入了签名输入
• 它们有没有排序、拼接、过滤
• 中间有没有时间戳、nonce、设备信息混进来
• 最后哪个动作让请求从“普通参数集合”变成“可被服务器接受的请求”

第一步：先从请求侧判断“谁最像约束字段”

对照几组样本，先粗分：

• 业务字段
• 会话字段
• 设备字段
• 时间/随机字段
• 疑似摘要/签名字段

这样做的好处是，你不会一上来就被几十个参数拖进泥潭。

第二步：锁定“组包前最后一层”

很多签名逻辑不会直接写成一个很直白的 calcSign()。它更可能分散在：

• 参数收集
• 排序
• 字符串拼接
• 摘要/加密
• header/body 回填

所以与其盲搜 sign，不如找“请求发出前最后一次大规模整理参数的地方”。

第三步：盯排序、拼接、摘要，而不是只盯 crypto API

很多人一做签名定位就猛找 MD5、SHA、HMAC、AES。这个方向当然有用，但很容易漏掉更关键的前置步骤：

• 到底哪些字段参与了输入
• 字段顺序是否固定
• 空值、默认值、可选值是否被过滤
• 拼接格式是不是有隐含分隔符或前后缀

很多时候你算法猜对了，结果还是不对，根因就在输入边界没还原。

第四步：动态确认“输入是什么，输出去哪了”

一旦锁定可疑函数，最值钱的动态问题通常只有两个：

1. 它真正吃进去的原始输入是什么
2. 它吐出来的结果最终被填进了哪里

如果这两个问题都答清了，签名定位通常就已经过半。

最容易犯的错误

• 死搜 sign、sig、auth，忽略真实组包点
• 只盯 hash API，不还原输入链
• 看到一个固定长度字段就武断认定是签名
• 请求偶尔成功一次就以为链路已经还原完毕

我更推荐的定位顺序

1. 样本对照，先分业务字段和约束字段
2. 锁定组包前最后一层
3. 重点看排序、拼接、摘要三步
4. 动态确认输入输出边界

这条路线的底层逻辑很简单：先搞清楚请求为什么能成立，再谈怎么复现签名。

结尾

签名定位最怕的不是“算法复杂”，而是你还没把请求合法性拆开，就开始在名字和 API 上乱撞。只要你把问题重新表述成“请求在什么时候、通过哪一段处理链变合法”，路径通常就会清楚很多。