👦百趣云

wbi 的设计哲学：密钥动态化B站 2023 年起大面积启用 wbi 签名，取代旧的 appkey+appsign 体系。它的设计思路和别家相反：算法完全公开（就是 md5），但密钥不在客户端写死，而是藏在接口返回的图片 URL 里，定期轮换。防护思路从"算法保密"转向"密钥时效"，对逆向者反而友好了。完整流程拆解第一步：拿密钥原料。请求 https://api.bilibili.com/x/web-interface/nav（无需登录），返回：{ "data": { "wbi_img": 取两个 URL 的文件名去扩展名：img_key =

先认清对手：a_bogus 是 VMP 保护的抖音 web 端的签名参数从 _signature 到 X-Bogus 再到现在的 a_bogus，防护强度一路升级。当前版本的生成代码在 webmssdk.js 里，整个文件跑在字节自研的 JS 虚拟机上——你看到的不是 JS 代码，而是一堆字节码和一个巨大的 switch-case 解释器。这意味着"读源码理解算法"这条路基本被堵死：不是不能，是投入产出比极低。工程上成熟的打法是整段抠出 + 补环境，让这段 VMP 代码在 Node 里原样跑起来，我们只管调它的导出函数。第一步：确认签名入口webmssdk 加载后会在 window 上挂出入口

签名公式：教科书级的"摘要套摘要"知乎 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