🔖JS逆向

签名公式：教科书级的"摘要套摘要"知乎 API 的 x-zse-96 是逆向圈的经典案例，因为它的设计非常工整，拆开后每一步都清清楚楚：x-zse-96 = "2.0_" + encrypt( md5( "101_3_3.0" + url_path + d_c0 + body_md5 ) )逐个字段说："101_3_3.0"：写死在 JS 里的版本标识，历史上有过 101_3_2.0 等变体，以当前页面为准url_path：接口路径，不含域名和查询串（比如 /api/v4/search_v3）d_c0：cookie 里的设备标识，登录

先看懂 x-s 的结构小红书 web 端每个 API 请求带 x-s 和 x-t 两个头。x-t 就是毫秒时间戳，没花样。x-s 值得细看——base64 解码后是一个 json，长这样：字段编号和含义随版本有变化，但设计思想不变：签名值 + 签名的"元信息"打包传输，服务端根据元信息选择校验策略。这种设计的好处是算法升级时服务端可以灰度，坏处是——对逆向者来说结构全写在脸上。定位：签名入口其实挂在 window 上小红书前端是 webpack 打包，但签名函数最终暴露成了一个全局函数，名字形如 window._webmsxyw。最快的确认方式：// Console 直接试 typeof wi

问题的本质：anti_content 不是签名，是"答卷"很多人把拼多多的 anti_content 当成普通接口签名来逆，这是方向性错误。普通签名回答的是"这个请求有没有被篡改"，而 anti_content 回答的是"你这个客户端是不是一个真实的、可信的浏览器"——它是一份环境答卷，里面塞满了设备指纹、行为特征、运行时自检结果。抓包能看到它长这样：0an 开头的一长串编码，每次请求都不同，长度随环境信息浮动。web 端由风控 SDK（riskControl 相关 chunk）生成，App 端则是 native 层（安全 SDK 的 SO）产出，两端算法同宗但密钥和采集项不同。本文讲 web