抖音 Web 请求签名机制分析：a_bogus 参数的逆向研究与 Python 实现探索（附源码）
从 Web 安全角度分析 a_bogus 签名生成流程：纯 Python 实现实践
你发个请求，返回 {"status_code": 10111, "status_msg": "invalid a_bogus"}——额……签名不对，直接拒绝。
市面上主流的方案是两种：
- execjs + JS 文件：每次算签名起一个 Node.js 子进程，慢，还要装运行时
- Selenium 补环境：跑一个完整浏览器，几百兆内存起步，容易被检测
我想要的很简单：纯 Python，不装 Node.js，不跑浏览器，依赖尽可能少。
果断网上搜了一圈，很贵！！！。那就自己搞。
二、过程
第一步：定位生成函数
抖音的 JS 经过 webpack + 混淆，变量名全是 t、e、n、o。找生成函数就是顺着调用链往前追：从 axios.get(url, { params: { a_bogus: o() } }) 找到 o，再从 o 找到它里面调用的加密函数。Chrome DevTools 的 “Go to definition” 在 Source Map 不可用时不好使，更多是靠手动搜索函数体特征——比如找那一排硬编码的 256 长度的数组，那是 RC4 key scheduling 的标志。
找到目标函数后，复制出来格式化，逐行拆解。
第二步：逐块还原算法
1. SM3 哈希——算两次，但第二次的输入不是 hex 字符串
抖音没有用 MD5 或 SHA，用了国密 SM3。这个门槛直接过滤了一批只会 import hashlib 的人。
关键细节：算两次。
第一次：对 urlencode(params) + "cus" 做 SM3，输出 32 字节。
第二次：把第一次输出的 32 个裸字节（不是 hex 字符串，不是 ASCII 文本）再算一次 SM3。
我一开始理解错了第二次的输入形式，以为喂的是 hex 字符串（64 个 ASCII 字符），结果每字节都对不上。卡了两小时才在 JS 里打日志发现套的是 SM3(bytes.fromhex(h1))。
参数要算一次（params + “cus”），HTTP 方法也要算一次（method + “cus”）。"c