🔖JS逆向

_signature：字节系防护的"入门级样本"今日头条 web 端 feed 接口 www.toutiao.com/api/pc/list/feed 带 _signature 参数。它和抖音的 a_bogus 同属字节系安全 SDK（acrawler 家族）的产物，但防护强度低一个档次——没有上 VMP，是普通混淆。这使它成为进军抖音之前的最佳热身目标：同一套方法论，更低的对抗强度。定位：标准 hook 流程const _open = XMLHttpRequest.prototype.open; XMLHttpRequest.prototype.open = function(m, u) ;

先建立正确认知：天眼查的防护重心不在签名逆天眼查之前先泼一盆冷水：如果你带着"搞定签名参数就通关"的预期来，会撞得头破血流。天眼查这类企查平台的防护哲学是行为风控为主、参数加密为辅——签名参数半天就能搞定，但搜索几次就弹出来的滑块才是真正的城墙。理解这个主次关系，后面的投入才不会跑偏。三层防护结构第一层：cookie 设备标识。TYCID 是设备级 cookie，首次访问种下，长期有效。它是行为归因的锚点——你所有请求都会记到这个设备名下，触发风控时按它封。第二层：登录态 token。登录后 x-auth-token 存在 localStorage，请求时放请求头。有效期数天，但有 IP 段绑

tk：指令虚拟机的另一个样本谷歌翻译 translate_a/t 接口的 tk 参数，和百度翻译 sign 用的是同一套设计思想——指令串驱动的位运算器。如果你已经搞懂了百度那套，谷歌这个十分钟就能拿下；反过来也一样。两家"撞设计"不是巧合，这套结构本来就是前端混淆的经典范式。TKK 种子页面里写着 TKK='444385.4274552210' 之类的值，定期更新。它是 tk 计算的初始状态，工程上启动时从 translate.google.com 页面提取，不写死。算法完整实现def xr(a, ops): # 指令执行器：每3字符一条指令 [累加/异或][左移/右移][位数]

参数全家福：每个都不难，组合起来才是防护有道翻译 fanyi.youdao.com 的 translate_o 接口（注意带 _o，不带 _o 的旧接口不校验签名但时好时坏）需要一组参数：参数含义算法lts毫秒时间戳str(now_ms)salt盐lts + 1位随机数bv浏览器标识md5(User-Agent)sign核心签名md5(固定串 + 文本 + salt + 密钥)单个看都是 md5 一把梭，但它们的依赖链才是设计意图：bv 绑 ua，sign 绑文本和 salt，salt 绑时间——改任何一个输入，链条上所有参数都要重算。算法实现import hashlib, time, ran

两个参数，两种获取方式百度翻译 fanyi.baidu.com 的 v2transapi 接口需要 sign 和 token 两个参数，获取方式完全不同：token：页面里写死的，正则一把抠：token: '([0-9a-f]+)'sign：由待翻译文本实时计算，算法在页面 JS 里，种子是页面里的 gtk这个"gtk 种子 + 逐字符位运算"的算法结构，是前端签名里最经典的设计之一，值得完整拆一遍。gtk：算法的种子页面源码里有 window.gtk = '320305.131321201' 之类的定义，两个数字用点分隔。它是 sign 计算的初始状态，会不定期更新——所以工程上 gtk 要