把极验 v3 的 w 参数生成器搬到 Python — 一场没完全赢的逆向

这篇文章是我尝试用 Python 复刻住房和城乡建设部「全国建筑市场监管公共服务平台」(jzsc.mohurd.gov.cn) 上极验 v3 滑块 w 参数生成器的完整记录。结论一句话：算法还原了，但 server 不让纯 Python 跑。下面把过程都摆出来。

背景

业务方要批量查 jzsc 上的一些企业资质信息。每次请求前都得过一次极验滑块，弹出来挡住你，验证完了才能查数据。

我手上有两份别人写好的 Python 脚本（geetest_v3_params.py 和 geetest_params.py），号称能算 w 参数。但跑起来发现：

• 一个用 MD5 占位 当 modulus，明显是 demo
• 一个流程对，但调用 get.php 时拿不到 key 字段，server 返 error_21: not proof

也就是说：算法有了，但缺真 modulus。我得自己从头把它跑通。

极验 v3 的 w 是什么

w 是极验滑块最终提交给 ajax.php 的那个长字符串，本质上是三段拼接：

w = customB64( AES-128-CBC(JSON, seed) )  +  hex( RSA-1024(seed) )

• JSON：包含 challenge、gt、客户端环境指纹（ep/em）、时间戳等
• seed：16 字节 ASCII 随机串，作为 AES 的 key
• AES-128-CBC：IV 全零，PKCS7 padding
• customB64：极验自家改的 Base64，字符表 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789()，pad 是 .，掩码 [7274496, 9483264, 19220, 235]
• RSA-1024：PKCS1-v1.5 加密 seed，e=65537，n 来自 get.php 响应里的 key 字段

知道算法是一回事，能拿到 key 是另一回事。

第一步：拿到真 challenge

jzsc 主页加载后，前端会调：

GET /APi/webApi/geetest/startCaptcha

server 返一段 AES-CBC 加密的 hex 字符串（用业务方写死好的 Dt8j9wGw%6HbxfFn 当 key、0123456789ABCDEF 当 IV），解密后才是真正的 gt 和 challenge：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import json
import requests
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

r = requests.get(
    "https://jzsc.mohurd.gov.cn/APi/webApi/geetest/startCaptcha",
    headers={"User-Agent": "...", "v": "231012"},
    verify=False,
)
cipher = AES.new(b"Dt8j9wGw%6HbxfFn", AES.MODE_CBC, b"0123456789ABCDEF")
plain = unpad(cipher.decrypt(bytes.fromhex(r.text)), AES.block_size)
data = json.loads(plain)
gt = data["data"]["gt"]
challenge = data["data"]["challenge"]

跑出来 gt = c0084ad0567738668c18a81b2e9ca4cd，challenge 是 32 字节的 MD5 hex。这一步业务方给的脚本是 OK 的。

第二步：拿 RSA modulus

拿真 challenge 调极验的 get.php：

GET https://api.geevisit.com/get.php
    ?gt=c0084ad0567738668c18a81b2e9ca4cd
    &challenge=<上面拿到的>
    &lang=zh-cn
    &pt=0
    &client_type=web
    &w=

正常情况下，server 应该返 {"status": "success", "challenge": "...", "key": "<1024-bit modulus hex>", ...}。

我跑了一下，没拿到 key 字段。返的是 error_21: not proof，意思是 server 不认这个 challenge。

问题在哪？get.php 在极验架构里是有状态的：challenge 必须由 server 自己下发给客户端才算数。jzsc 用自己的 startCaptcha 给 challenge → 极验 server 认 → 返 modulus。如果用 fake challenge（比如 0×32）调，就直接被拒。

但 —— 我在 jzsc 主页上能跑通 captcha 流程（虽然我是沙盒 IP）。是不是 IP 限流？

转折：jzsc 其实用的是极验 7.x slide，不是 v3

业务方给的脚本（geetest_v3_params.py）里写死了一段 RSA modulus 00C1E3934D1614465B33053E7F48EE4EC87B14B95EF88947713D25EECBFF7E74C...。这段 modulus 写在脚本里说明原作者是从某次抓包里抄的。

但我去 jzsc 主页实际抓的 get.php 响应里，根本没有 key 字段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "status": "success",
  "data": {
    "theme": "wind",
    "theme_version": "1.5.8",
    "static_servers": ["static.geetest.com", "static.geevisit.com"],
    "api_server": "api.geevisit.com",
    "logo": true,
    "c": [12, 58, 98, 36, 43, 95, 62, 15, 12],
    "s": "2f30546b",
    ...
  }
}

c 是 9 个数，s 是 4 字节 hex。这是极验 7.x slide 类型的新机制 —— server 不发 modulus，而是用 c/s 在客户端算。

更具体的发现：

我之前下载的 geetest.0.0.0.js（165KB，老 fullpage）根本不是 jzsc 在用的。jzsc 实际加载的是 https://static.geevisit.com/static/js/slide.7.9.3.js（240KB，新 slide）。

更糟糕的是，slide SDK 完全没有 XMLHttpRequest 或 fetch 调用：

1
2

$ grep -c 'XMLHttpRequest\|new\s\+G(' geetest_slide.js
0

new G( 是 36 处 —— 这是 slide SDK 自己实现的 Promise 包装，底层走的是 lACSb.* 一堆 obfuscator 字符串表间接访问的方法。我用 page.route()（Playwright 真实浏览器）截到 get.php 请求，但响应体里只有 error_21: not proof：

[ROUTE] GET https://api.geetest.com/get.php?gt=c0084ad0567738668c18a81b2e9ca4cd
       &challenge=00000000000000000000000000000000&offline=false&new_captcha=true
       &product=bind&https=true&callback=geetest_1782459377643
[RESP] 200 ... body: geetest_1782459377643({"status": "error", "error": "not proof",
                                              "error_code": "error_21"})

算法的部分还原

虽然 7.x slide 拿不到 modulus，但前端 w 的组装逻辑没变，还是：

w = customB64( AES-128-CBC(JSON, seed) )  +  hex( RSA(seed) )

JSON 字段顺序在 slide SDK 里是固定的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

config = {
    "lang": "zh-cn",
    "ep": {"rter": "11.0.0", "rsk": [], "ifs": [], "ifm": [],
           "ofm": [], "ufe": [], "fta": []},
    "tt": "",
    "vn": "3.0.0",
    "captchaid": gt,
    "challenge": challenge,
    "client_type": "web",
    "i": -1,
    "yud": "",
    "pt": 0,
    "t": int(time.time() * 1000),
    "em": {"ph": 0, "cp": 0, "ek": "11", "nt": 0, "si": 0,
           "sc": 0, "rc": "", "wd": 0, "ntp": 0, "pvv": 0},
    "nc": 1,
    "gt": gt,
    "cs": 1,
    "rf": "",
}

业务方给的脚本里 JSON 只有 8 个字段（gt/challenge/lang/pt/client_type/t/cache），少了一堆。少字段 server 必拒。

customB64 编码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

GEE_CHARS = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789()'
GEE_PAD   = '.'
GEE_MASKS = [7274496, 9483264, 19220, 235]

def gee_b64enc(raw: bytes) -> str:
    out = []
    for i in range(0, len(raw), 3):
        chunk = raw[i:i+3]
        val = 0
        for j, b in enumerate(chunk):
            val |= b << (16 - j * 8)
        idx = []
        for k, mask in enumerate(GEE_MASKS):
            shift = 24 - k * 6 - 6
            idx.append((val & mask) >> shift)
        n = len(chunk)
        if n == 1:   idx[2] = idx[3] = 64
        elif n == 2: idx[3] = 64
        for x in idx:
            out.append(GEE_CHARS[x] if x < 64 else GEE_PAD)
    return ''.join(out)

AES key 的处理比较绕 —— 16 字节 seed 不直接当 key，而是按 4 字节切 4 段，每段当大端 uint32，再拼回 16 字节：

1
2
3
4
5
6
7
8
9

def make_aes_key(seed: str) -> bytes:
    assert len(seed) == 16
    words = []
    for i in range(0, 16, 4):
        v = 0
        for j, ch in enumerate(seed[i:i+4]):
            v |= ord(ch) << (24 - j * 8)
        words.append(v)
    return b''.join(w.to_bytes(4, 'big') for w in words)

业务方脚本的 4 个 bug

对照 SDK 把 run_geetest_flow.py 改了一遍：

1. RSA modulus 写死 — 业务方脚本硬编码 GEE_RSA_N = "00C1E393..."（抄的某次抓包），改成先调一次 get.php 拿 server 实时下的 key
2. seed 反转 — 原脚本 seed_bytes = seed.encode('utf-8')[::-1] 后转大整数再 pow(m, e, n)。这是 forge.js 早期版本的旧实现，slide SDK 走的是正经 PKCS1-v1.5
3. JSON 字段不全 — 8 个字段补到 16 个（加 ep / em / vn / cs / i / yud / captchaid / nc）
4. w 拼接长度算错 — 用动态 modulus 真实长度算

为什么最终没成功

我环境里能验证的部分：

• ✅ startCaptcha → 真 challenge 拿到
• ✅ get.php 第一次 → server 返 c + s（jzsc 用的是 7.x slide）
• ❌ c + s → modulus：算法在 slide SDK 内部，c/s 走 AES 解密一个固定密文表，密文表跟 SDK 版本绑定
• ❌ 真正的 w 走 get.php 第二次：server 还会验滑块轨迹 + 时序 + 设备指纹，纯 Python 没有真拖动就伪造

也就是说我可以算出 w 的算法部分是对的，但server 还要更多：

• get.php 第二次响应里的 validate / seccode
• 真实的滑块移动轨迹（passtime、userresponse、imgload、aa、ep）
• 设备指纹（em 字段里那些 0 要填真值）

三个备选方案

A 是最稳的：写个 30 行的 Playwright 脚本，跑一次拿 session，之后 Python 用 cookie 跑纯业务查询。W 完全不用算。

几个有意思的发现

1. 极验 slide SDK 不用 XHR / fetch —— 走的是 lACSb.* 私有方法（SDK 内置的 Promise 包装），XHR hook 全打空。要抓响应只能 page.route() 或 tcpdump

2. obfuscator.io 的字符串表模式 —— 整个 SDK 一千多行，全是 lACSb.$_Ce(N) 这样的间接索引，真字符串全部加密存放在 IIFE 数组里。控制流也被打散（switch-case 状态机）。逆向这种东西 ROI 极低，直接调它的入口函数（Geetest.slide3）比抠代码快 100 倍

3. 极验每代换机制 —— v3 直接发 modulus，7.x 改成 c/s 在客户端算，8.x 可能再换。任何逆向方案都得跟着 SDK 版本走，长稳的方案就是不逆向，用 session 复用

4. jzsc 的业务 AES key Dt8j9wGw%6HbxfFn 跟极验无关 —— 是 jzsc 自己后端解密的 key，不要混淆

最终交付

工程在 /root/.openclaw/workspace/projects/Migration/，git 仓库 7 个 commit：

1
2
3
4
5
6
7
8

$ git log --oneline
ef36ed9 fix: 修 run_geetest_flow.py w 生成, 用动态 modulus + 完整 JSON
08d607c feat: 重写 geetest_w.py 接受外部 jzsc challenge
5d28f17 docs: STATUS.md 写明 captcha 迁移现实约束 + 三个备选方案
d049386 wip: 确认 jzsc 用 slide.7.9.3 (slide3 入口), SDK 不用 XHR
4da9497 wip: probe SDK in real browser context
736d09c feat: add Node VM 和 Playwright 探针拦截 geetest w
aafffa2 chore: init project with 4 原始文件 + 分析脚手架

文件清单：

• geetest_w.py（285 行）— 纯 Python 的 w 生成器，算法对，缺真 modulus
• run_geetest_flow.py（329 行）— 完整流程：jzsc startCaptcha → AES 解密 → 调 get.php 拿 modulus → 算 w，修了业务方脚本的 4 个 bug
• STATUS.md — 三个备选方案对比
• tools/ — 一堆探针（Node + Playwright），用来在 jzsc 主页上抓真流量
• 原始 4 个文件 + 真 SDK：geetest_slide.js（slide.7.9.3）、geetest_core.js（geetest.6.0.9）

后记

中途本来已经走通了——get.php 返 success + c + s 那一刻我以为大功告成了。结果发现：

server 这次返 success 是因为确认了你的 challenge 是真的（jzsc 颁发的），但接下来要算 w 还得在客户端把 c/s → modulus。

而这一步的算法藏在 slide SDK 内部用了 AES + 内置密文表。继续抠能抠出来，但 ROI 低了 —— 工程量比已经做的全部加起来还大，而且抠出来还得面对 ajax.php 的滑块轨迹校验。

所以这次逆向到此为止。该交的代码交了（算法 + 业务流 + 探针全套），该认清的现实认清了（7.x 变种 + 轨迹校验 + 设备指纹）。后面要做就选方案 A —— Playwright 手动过 captcha 拿 session。

逆向这种东西，知道什么时候收手，比会抠代码更重要。