[原创] 某书 X-s 签名逆向分析(含风控点)-有了 AI人人都能还原VMP

首先抓包分析 /api/sns/web/v1/homefeed 接口，发现请求头中有两个关键签名参数：全局搜索 X-s，定位到签名生成位置：跟进 seccore_signv2：签名流程很清晰：url + body → MD5 → mnsv2 加密 → JSON 包装 → 自定义 Base64核心就是 window.mnsv2。这是最难的一步。window.mnsv2 只是个入口，实际执行的解释器藏在别处。VM 的典型特征：我使用自研的逆向 MCP 工具，通过 Hook + 调用栈追踪：最终定位到 VM 文件：VM 解释器代码当然是混淆的。使用 Babel AST 配合 AI 进行解混淆：解混淆后得到可读的解释器代码。在代码中找到这样的字符串：这就是 VM 的字节码，通过自定义的 switch 基于栈来执行。基于栈的 VM 只是一种实现方式，还有基于寄存器的 VM，原理类似。分析解释器的 switch-case，构建操作码映射：这一步用 AI 辅助分析非常高效。有了操作码表，就可以对字节码进行反编译：这里需要多次动态调试来验证反编译结果的正确性，同样交给 AI 完成。反编译产出一个大文件，需要分割成独立函数：有些厂商会在这层再加控制流平坦化，这时需要在浏览器中 trace 执行流程。最后，结合静态分析和动态调试，还原完整算法。Base64 表:JSON 结构:关键点：mns0301 使用 RC4 + 预置 S-box 加密，服务器持有相同的 S-box，可以完全解密还原原始数据。签名不只是"防篡改"，更是"行为数据上报通道"。回顾 135 字节输入结构，关键字段都是风控相关：服务器解密签名后，可以进行以下判断：核心机制：行为数据全局累积，每次请求时打包进签名为什么选这些元素？ 都是用户正常浏览必然会经过的区域。如果一个"用户"发了 100 个请求，但从未触碰过这些核心元素 → 爬虫。服务器通过对比多次请求中的计数器变化来判断：从反汇编还原的逻辑：人类点击的物理极限约 50-100ms，77ms 是一个合理的阈值：对于不使用浏览器、直接发 HTTP 请求的纯协议爬虫，这套风控机制带来了显著挑战：问题：计数器不能恒定纯协议必须维护会话状态这套风控的设计意图结论：纯协议爬虫必须维护会话状态，模拟计数器的单调递增趋势，这大大增加了爬虫的开发成本。mns0301 使用 RC4 流密码 + 预置 S-box，整体难度适中，核心在于定位 VM 入口和还原字节码逻辑。try {

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-289656.htm

看看先

tql

听君一席话 胜似一席话