🔖api

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

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

m.weibo.cn：大厂接口里的一股清流在各厂疯狂堆签名、堆设备指纹的今天，微博 H5 站 m.weibo.cn 的接口防护朴素得令人感动：没有客户端签名，没有设备指纹，核心就是标准的 XSRF 双 cookie 校验 + 频率限制。它是协议爬虫入门的最佳练手目标，也是理解"限流型防护"和"签名型防护"本质差异的好样本。XSRF 流程：标准到可以写进教科书import requests session = requests.Session() session.headers.update() # 第一步：访问任意页面，拿 XSRF-TOKEN cookie session.get('ht

先搞清楚两个参数的分工闲鱼 App 的 mtop 请求头里有两个关键参数：x-sign 和 x-mini-wua。很多人上来就死磕 x-sign 的算法，方向就偏了——这两个参数是阿里 SecurityGuard 安全 SDK 的一体两面：x-mini-wua：设备环境摘要。设备型号、系统版本、root 状态、模拟器特征等信息的压缩编码，回答"你是什么设备"x-sign：请求签名。用设备标识 + miniWua + 时间戳 + 业务参数算出，回答"这个请求合不合法"服务端两个都验，而且交叉验——x-sign 里掺了 x-mini-wua 的内容，所以改设备信息必须重签，两者是咬合的。Java