得物的签名架构：算法在 SO，但没有加固得物 App 接口的 sign 参数有一个让逆向者松一口气的特点：算法在 native 层实现，但 SO 没有加固。这意味着两条路都通——IDA 静态分析能看懂，Frida 动态直调更方便。它是学习"SO 层签名对抗"的舒适入门案例。Java 层定位：从参数组装追到 JNI 入口jadx 打开 APK，搜索签名参数的组装点。得物的网络层封装里能找到类似结构：// 特征：TreeMap 排序 + native 方法 Map<String, String> sorted = new TreeMap<>(params); String

_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) ;

12306 的防护哲学：流程即城墙12306 是"重 cookie、轻签名"的极致代表：查询和下单接口没有任何客户端签名，但 cookie 体系和请求编排层层嵌套，缺一个环节就返回"网络可能存在问题，请您稍后重试"——这句提示 90% 的情况不是网络问题，是你的流程不对。核心 cookie 地图cookie作用种下时机JSESSIONID会话标识进站即种BIGipServerotn负载均衡，决定落到哪台后端进站即种_jc_save_fromStation出发站（编码格式：北京,BJP）查询页行为_jc_save_toStation到达站查询页行为_jc_save_fromDate / _jc_

携程的防护结构：标识体系比签名复杂逆向携程接口时容易陷入一个误区：把 sign 参数当主角。实际上携程的防护重心在设备标识体系——GUID、clientid、UBT 埋点标识、指纹 fp 互相咬合，sign 只是把这些标识串起来的最后一环。先理清标识体系，签名水到渠成。标识体系拆解GUID：32 位标识，首次访问由服务端 Set-Cookie 种下，长期有效。它是携程体系里的"设备身份证"clientid：请求头里的客户端标识，和 GUID 关联生成UBT 系列：埋点 cookie（_UBT、_bfa 等），记录页面行为路径，部分接口会校验其存在性fp：指纹值，独立 SDK 采集生成，和 ua

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