2.1 从已知输入做差分#

固定时间、环境和随机序列，每次只修改一个变量，例如 URL 中的一个字符。观察解码后哪些字节发生变化，可以快速区分：

• URL 或 Body 的摘要字段；
• 时间相关字段；
• 环境与设备指纹字段；
• 纯随机或校验字段。

这种单变量实验比直接猜测字段含义可靠。字段位置确定后，再回到 VM 调用点追踪来源，范围会小很多。

2.2 从出口向前回溯#

最终输出使用自定义 Base64，因此先还原字符表，再去掉前缀并逆向异或层，可以看到更稳定的内部结构。外层变换被逐层剥离后，Payload 中的固定区、可变区和随机区会明显分开。

2.3 在随机函数调用点插桩#

对 Math.random.apply 的调用点记录调用序号、上下文和后续指令，可以把随机值与随机头、前缀及位掩码扩展中的注入字节对应起来。

重点不是反编译整个 JSVMP，而是找到少量稳定的输入输出边界：摘要入口、随机数入口、Payload 组装点、校验值写入点和最终编码出口。

3.1 URL 与 Body 使用 SM3 二次哈希#

SDK 使用 SM3，而不是常见的 MD5 或 CRC32。一个明显特征是代码中出现 SM3 初始向量 0x7380166f。输入会先拼接盐值 dhzx，再连续计算两次 SM3，后续只抽取部分摘要字节写入固定字段。

1
h1 = SM3(SM3(query + "dhzx"))
2
h2 = SM3(SM3(body  + "dhzx"))

这里最容易出错的是输入边界：

• URL 只取 ? 之后的查询参数，不包含域名和路径；
• 查询串遵循 URLSearchParams.toString() 的格式，空格编码为 +；
• POST 请求还会处理 Body，GET 请求对应位置通常为空值；
• UA 不直接进入这组摘要，而是通过环境字段产生影响。

如果把整条 URL 送入哈希，即使后续结构全部正确，最终结果也会从摘要字段开始偏离。

真实浏览器最终 query 的闭环验证还修正了一个早期误判：f[12] 不是环境字段，而是 h1[3]。当前已确认的摘要映射包括：

1
f[9]  = h1[18]
2
f[12] = h1[3]
3
f[15] = h1[9]
4
f[33] = h2[10]
5
f[38] = h2[19]

因此环境字段索引集合中必须移除 12。否则即使大部分结构正确，query 变化后仍会在 fixed48 中产生稳定偏差。

3.2 最终输出使用自定义 Base64#

bdms 内置多套编码表，最终输出使用其中一套 URL-safe 变体。它的分组方式与标准 Base64 一致，区别只在字符映射表。

因此分析时不必重新推导 Base64 算法，只需建立自定义字符表与标准字符表之间的双向映射。完成这一步后，最终字符串就能还原为前缀和内部密文。

3.3 外层是固定密钥流 XOR#

外层并不是复杂的分组密码，而是数据与一段静态密钥流逐字节异或。这个结论可以通过选明文差分确认：固定输入和随机状态，多次比较密文变化；再对已知明文与密文做异或，即可观察到稳定重复的密钥流。

XOR 具有自逆性，同一变换既能用于加密，也能用于解密。分析上的价值在于：一旦剥离这一层，内部结构便可以直接按字节观察，不必继续在密文上猜字段。

3.4 位掩码交错扩展#

Payload 会按每 3 字节一组进行扩展，并注入 1 个随机字节，最终得到 4 字节。三组互补掩码分别覆盖输入字节与随机字节，最后一个输出字节保存前三个输入字节被拆出的剩余位。

这类结构看起来像单向混淆，实际是完全可逆的：输入字节可以从互补掩码重新拼回，注入的随机字节也能从前三个输出字节恢复。

另一个细节是余数处理。当 Payload 长度不能被 3 整除时，末尾 1 至 2 字节会直接追加，不参与扩展。若忽略这个分支，签名长度和末尾内容都会出现偏差。

3.5 随机部分来自内部 PRNG#

运行时记录显示，随机头、前缀和位掩码扩展使用的是同一组有序随机调用。调用序号稳定后，可以根据上下文把它们分成几类，而不必为每个随机字节单独猜公式。

底层状态推进呈现 glibc LCG 特征，但复刻时有一个容易忽略的问题：原始计算遵循 JavaScript float64 语义。乘法结果超过 2^53 后会发生舍入，若在其他语言中直接使用任意精度整数计算，第二轮开始就可能与真实序列分叉。

这也是逐字节回归的重要性：结构正确并不代表随机序列一致，首个偏差位置通常能直接暴露语言语义差异。

3.6 六个旧固定值实际来自运行时环境#

早期纯算实现把 fixed48 的六个位置写成全局常量：

1
f[14] = 3
2
f[25] = 0
3
f[27] = 3
4
f[30] = 0
5
f[34] = 0
6
f[45] = 3

对真实 bdms.js 的签名主入口和 Payload 组装入口插桩后，可以把 env 块输入逐值映射到 fixed48。结果表明，这六项全部是运行时环境检测值，而不是算法常量：

另一个重要修正是：真实 Chrome 1.0.1.20 样本的 [27] 和 [45] 同样为 13，并不是 此前根据旧 trace 推测的“Chrome 为 3、Firefox 为 13”。旧值 3 来自不同 bdms 版本， 不能跨版本直接复用。

工程实现应把这些值放入带站点、版本和浏览器范围的 profile，而不是继续留在 build_fixed48() 中：

1
fixed_field_overrides = {
2
    14: 3,
3
    25: 40,
4
    27: 13,
5
    30: 0,
6
    34: 0,
7
    45: 13,
8
}

差分请求显示，服务端能够接受这些字段在真实环境中出现的多个取值，因此它们更接近软 信号。profile 能保证当前已验证环境可用，但若目标是与任意时刻的浏览器逐字节一致，仍需 从运行时动态采集。

4.1 一条真实签名的脱敏解码#

为了让结构不只停留在公式上，我对一条真实 bdms 1.0.1.20 签名做了完整逆向解码。 文章中仅保留长度、结构、固定域字节和校验结果；随机前缀、随机头、指纹原文、时间码原文、 query、Body 与会话信息全部隐藏。

1
样本              D64nDH6L…hhqoE==（中间已省略）
2
编码长度          192 chars
3
自定义 Base64 后  142 bytes = 4B 随机前缀 + 138B codec 密文
4
codec 解密后      138 bytes = 8B 随机头 + 130B packed
5
逆 garble 后      98 bytes Payload
6
Payload 布局      fixed48 + meta2 + 43B fp + 3B time + ',' + checksum
7
fp                <已脱敏：43 bytes，9 个字段，均为可打印字符>
8
time              <已脱敏：3 个十进制字符>
9
随机序列          从 packed 可逆恢复 32 个 rnd 字节
10
codec 往返        通过
11
checksum          实际 129，计算 129，通过

这里的 98 字节余数为 2，因此前 96 字节按每 3 字节扩展为 4 字节，最后的逗号与 checksum 原样追加：96 / 3 × 4 + 2 = 130，与 packed 长度完全吻合。

校验值也能独立闭环：

1
checksum = XOR(header[0:8]) ^ XOR(payload[0:50])
2
         = 129

这条样本不能反推出 query 或 Body 原文。固定域中只保存了双 SM3 摘要的少数字节，表格 展示的是这些派生字节，而不是请求明文。

4.2 fixed48 每个位置的真实值与来源#

这份表还有一个值得注意的新证据：六个慢变位置在该样本中为：

1
{14: 3, 25: 39, 27: 14, 30: 2, 34: 2, 45: 14}

它与前一页载捕获到的 {14: 3, 25: 40, 27: 13, 30: 0, 34: 0, 45: 13} 不同， 但结构、codec 往返和 checksum 都完全成立。这进一步说明六项是运行时软信号，不能把某一 次抓包值升级为跨页面、跨浏览器或跨版本的算法常量。

6.1 签名正确不代表网络环境正确#

这个接口还暴露了一个非常容易误判的问题：服务端不只看 a_bogus，还会检查 TLS/JA3 与 HTTP/2 指纹。

浏览器原始签名经 requests 重放仍被拒，说明失败点位于网络指纹层，而不是签名算法。 最终使用与 UA/profile 一致的 Firefox TLS 模拟：

1
import primp
2

3
client = primp.Client(
4
    impersonate="firefox",
5
    impersonate_os="windows",
6
    http2_only=True,
7
)

在自有授权账号环境中，纯算 SDK + primp 连续 3 次请求均返回 code=0，响应包含销量、 浏览量、合作达人数、结算金额和内容数据。这个结果同时证明了签名结构、环境 profile 和 网络发送链路在当前样本上的整体可用性。

6.2 另外两个工程坑#

• Body 会逐字节进入 h2。签名时使用格式化 JSON、发送时使用紧凑 JSON，即使语义完全 相同也会导致摘要不同。
• x-ms-token 响应头中的值可能已经包含 %3D%3D。若再经一次 urlencode()，会变成 %253D%253D，表现为 HTTP 200 但响应体为空。构建 URL 前应先 unquote()，再统一编码。

这次在线排查也让我把问题明确拆成三层：

1. 业务层：Body 字段、biz_id 和动态 Tab 参数是否真实；
2. 签名层：query、Body、时间与 profile 是否逐字节一致；
3. 网络层：TLS、HTTP/2、UA、Cookie 和会话凭据是否匹配。

只围绕 a_bogus 调参，很容易把 -1025 或环境风险误判为纯算算法错误。

7.1 离线逐字节对比#

固定 query、Body、时间、环境和随机状态，对比原环境与纯算结果。发现差异后，按以下顺序定位首个偏差：

1
原始输入
2
  → URL/Body 规范化
3
  → 摘要字节
4
  → 固定区与可变区
5
  → 随机头和 checksum
6
  → 位掩码扩展
7
  → XOR 密文
8
  → 最终编码

7.2 真实样本反向验证#

对真实环境生成的签名逐层解码，确认 Payload 结构、随机字节恢复和 checksum 关系都成立。这样可以避免只在自行构造的样本中形成闭环。

7.3 服务端交叉验证#

最后使用多组独立请求确认接口返回正常结果。服务端成功只能证明整体可用，不能替代离线对比；反过来，逐字节一致也需要真实请求验证环境与时效性。

7.4 网络指纹隔离验证#

将同一个浏览器合法签名分别交给普通 HTTP 客户端和浏览器指纹客户端重放，可以把 “签名错误”与“网络环境错误”分离。这个对照实验比反复修改签名字段更快，也能避免把 TLS 风控错误归因到 JSVMP 算法。