从抓包到纯协议复现：还原一个签名算法的一般流程

做协议层自动化时，最硬的一关是签名参数。这里把我常用的流程写下来，重点不是某个具体算法，而是"怎么有章法地逼近答案"。

一、先判断签名是不是必需的

不是所有 sign 都参与校验。做法很简单：把请求原样重放两次，一次保留 sign，一次删掉或改成乱码。如果服务端都返回同样结果，说明它没校验；如果返回 401/403 或者业务错误码，才需要还原。这一步能省掉大量无用功。

二、判断签名的作用域

同一个 sign 可能只签 body，也可能签 method+path+query+body+timestamp+nonce 的全集。判断方法：只改 query 里一个无害参数（比如加个 `&_t=1`），看服务端是否拒绝。逐个字段试，能快速圈出参与签名的字段集合。注意有的实现会对参数名排序后拼接，所以"改顺序不报错"不代表参数没参与。

三、定位到具体实现

移动端有两类：一类在 Java/Kotlin 层，jadx 能直接看到；一类在 native 或者 Flutter/Dart 的 AOT 里，就得靠 hook。定位手段优先用字符串常量（`sign`、`sha256`、`HmacSHA256`、`timestamp`）交叉搜索，命中最多的类通常就是签名工具类。如果看到 `MessageDigest`、`Mac.getInstance`、`Cipher.getInstance`，那就是标准库；如果看到自定义的位移、异或、查表，那多半是魔改过的哈希。

四、动态验证，而不是只读代码

静态读出来的算法一定要动态对拍：hook 关键函数的入参和返回值，用真实请求的数据喂进去，看自己的实现能不能算出同样的 sign。Frida 一行就够：

```javascript

const M = Java.use('com.x.SignUtil');

M.sign.implementation = function (a, b) {

  const r = this.sign(a, b);

  console.log('IN', a, b, 'OUT', r);

  return r;

};

```

拿到几组 (输入, 输出) 之后，本地用 Python 复现，逐组比对。对不上就二分：先确认拼接规则，再确认哈希算法，最后确认密钥和编码（hex 还是 base64，大小写）。

五、把结论写成最小可跑脚本

最终交付物不是一份笔记，而是一个能跑的函数：输入参数和密钥，输出签名，附上三组对拍数据。这样别人接手时能立刻验证对不对，也能在算法变更时快速定位差异。

两个常见坑：一是时间戳参与签名，本地时钟偏差会导致签名"明明算对了却报错"，先对时；二是签名结果有的做了 URL 编码有的没做，同一个算法两种拼法，看看服务端要求的是 raw 还是 encoded。

最后说清楚边界：这套流程只适用于你有权测试的目标——自己的服务、自己买的账号、明确授权的项目。技术是中性的，用在哪里是自己的选择。