现象#

1. 打开靶场，就是一个普通的公告列表：公告编号 / 项目名称 / 金额（万元）/ 更新于，页脚写着「本页 10 条 · 第 1 / 5 页」。
2. 分页也普通：1 2 3 4 5 +「下一页」，下面还有个「跳转到第 N 页」的下拉框。
3. 但 F12 一看就不对劲：DOM 里 table tbody tr 有 13 个，页脚却说 10 条。
4. 用最常见的一把梭抓法（pandas.read_html）抓下来 → 每页 12 行（它只认内联 display:none，靠类名隐藏的两行照样抓）→ 5 页求和 → 提交上去判错。
5. 更阴的是：如果你遍历了页面上所有 <a href>（或者把页面里所有 <input> 拼成请求参数），接下来同一页两次抓到的数字就不一样了，而且整页「更新于」全挤在同一秒。
6. 全程没有任何报错：不 403、不弹验证码、不封 IP，HTTP 200，页面长得一模一样。

为什么「喂假数据」比「把门关上」更狠#

现实里的例子：招聘网站给爬虫返回”看起来正常、但根本不存在”的职位；电商给爬虫返回随机价格；行政区划接口给爬虫塞几个幽灵条目。目的都一样 —— 让你拿着脏数据走，而不是被你发现。

所以这一关的判错不会告诉你”你踩陷阱了”，只会说”答案不正确”。你得自己证明手里的数据是真的。

第一步：把「看不见的东西」找出来#

「看不见」在网页里不止一种写法，抓取时要一起判断：

所以判断”能不能抓”的正确姿势是：先把页面里的 CSS 规则读明白，再逐行判断，而不是只认 display:none：

1
import re
2
from bs4 import BeautifulSoup
3

4
HIDDEN_HINTS = ("display:none", "visibility:hidden", "left:-9999px",
5
                "opacity:0", "height:0", "width:0")
6

7
def hidden_class_names(html: str) -> set[str]:
8
    """把 <style> 里认定「看不见」的类名挑出来。"""
9
    soup = BeautifulSoup(html, "html.parser")
10
    css = "\n".join(tag.get_text() for tag in soup.find_all("style"))
11
    names = set()
12
    for match in re.finditer(r"\.([A-Za-z0-9_-]+)\s*\{([^}]*)\}", css):
13
        body = re.sub(r"\s+", "", match.group(2)).lower()
14
        if any(hint in body for hint in HIDDEN_HINTS):
15
            names.add(match.group(1))
16
    return names
17

18
def is_hidden(tag, hidden_classes: set[str]) -> bool:
19
    """这个元素人眼看得见吗？（内联样式 / 类名 / aria-hidden / hidden 属性）"""
20
    inline = re.sub(r"\s+", "", (tag.get("style") or "")).lower()
21
    if any(hint in inline for hint in HIDDEN_HINTS):
22
        return True
23
    if set(tag.get("class") or []) & hidden_classes:
24
        return True
25
    if tag.get("aria-hidden") == "true" or tag.has_attr("hidden"):
26
        return True
27
    parent = tag.parent            # 隐藏也可能是包在看不见的父节点里
28
    while parent is not None and getattr(parent, "name", None):
29
        if parent.get("aria-hidden") == "true" or parent.has_attr("hidden"):
30
            return True
31
        parent = parent.parent
32
    return False

这一关的三行幽灵数据，正好用了三种不同的隐藏方式：内联 display:none、CSS 类 display:none（.row-ghost）、CSS 类 visibility:hidden（.sp-invisible）。少了任何一种判断，都会多抓 3 行。

第二步：三类典型蜜罐（这一关全有）#

1
box = link.bounding_box()          # 离屏元素：x = -9999
2
if box and box["x"] < 0:
3
    continue                       # 这种东西不是给人点的，别跟

1
# 反面教材：把页面里所有 input 都拼成参数
2
params = {field.get("name"): field.get("value") for field in soup.find_all("input")}   # ← 会带上蜜罐字段
3
# 正面：只带你确认需要的
4
params = {"page": 3}

第三步：识别自己被「喂了假数据」#

被污染之后，服务端不会发任何通知，但留下的破绽有三处（这一关都埋了）：

把这三条写成脚本里的自检，比事后对着答案发呆强得多：

1
first = fetch(1)
2
if [row["amount"] for row in visible_rows(first)] != [row["amount"] for row in visible_rows(fetch(1))]:
3
    print("⚠️ 同一页两次金额不一样：踩到蜜罐了，现在停手等冷却")
4
    return          # 拿脏数据算下去只会得到错答案
5
if len(visible_rows(first)) != footer_count(first):
6
    print(f"⚠️ 抓到 {len(visible_rows(first))} 行，页脚说 {footer_count(first)} 条：先查隐藏行")

为什么必须”停手”：这一关的冷却会叠加（45 秒起步，每多踩一次 +30 秒，上限 180 秒）。越”多试几次找规律”，被封得越久 —— 真实站点的风控台账也是这么累积的。

第四步：被标记了怎么办#

• 本关的污染会自己到期（冷却结束、数据恢复原样）；真实站点不会，只能降低自己的可疑度或换出口。
• 换 IP / 清 Cookie 不一定有用：风控看的是”这个会话/账号做过什么”。本关按 user:<id> 记账，没登录才退化成按 IP。
• 真正该做的是回头看你请求了什么：是不是跟了隐藏链接、是不是把隐藏字段带上了。把行为改干净了，污染才不会再累积。

服务端那边只留一行日志，不会回给调用方（这就是真实站点的做法）：

1
CH-015 蜜罐命中 identity=user:1 kind=hidden-link:/playground/trap/next hits=1 接下来 45s 返回被污染的数据（不报错、不封禁）

第五步：完整脚本#

1
# 1) 浏览器登录靶场，F12 -> Application -> Cookies，抄下 session 的值
2
# 2) 填进 参考代码/s17.py 的 SESSION_COOKIE
3
python 参考代码/s17.py

脚本干了四件事：

1. 抓第 1 页，先把页面里的蜜罐列出来（隐藏链接、隐藏表单字段）—— 知道坑在哪，才知道别碰；
2. 做可见性过滤，把 13 行收敛到 10 行，并和页脚的「本页 N 条」对上；
3. 同一页连抓两次做一致性校验，一旦发现被污染就当场停手；
4. 5 页求和，提交。

反爬方视角：蜜罐怎么设计才有效#

1. 诱饵要比正路”更好走”：隐藏的”下一页”看着比真分页还像分页，隐藏字段看着比真参数还像参数。
2. 踩中不报错：一旦返回 403 或验证码，对方就知道被发现了；安静地喂假数据才有杀伤力。
3. 假数据要”像”：同量级、同格式、有正常的分页。一眼假的（金额 999999）只会提醒对方。
4. 留一条可自证的破绽（本关是同页两次不一致 + 时间戳同秒）：这是教学靶场的善意；真实站点往往把假数据做得每次一致，那就只能靠”用另一个数据源交叉验证”了。
5. 记台账、能累积：踩过几次、踩了什么，都记下来，越踩越严 —— 这就是本关冷却叠加的由来。

排查清单（⚠️ 先看前三条）#

1. 抓到的行数 ≠ 页脚条数 → 先做可见性过滤（display:none、visibility:hidden、离屏、aria-hidden），别急着怀疑算法。
2. 同一页两次数据不一样 → 你被污染了：停手、等冷却（别多试），并且别再碰隐藏链接/字段。
3. 整页「更新于」只剩一种取值 → 假数据的味道，同上处理。
4. pandas.read_html 只认内联 display:none：靠类名隐藏的行它照吃不误（本站 3 行幽灵行里它会漏掉 1 行、吃掉 2 行）—— 正确做法是”按 CSS 规则判断可见性”，不是只查一个属性。
5. 别把页面里所有 <input> 拼成 params（尤其 utm_* / refer / _hp 这种”统计参数”）。
6. 别遍历所有 <a href>；分页只跟随看得见、在文档流里的链接。
7. 数据入库前先做校验：条数、唯一编号去重、同页两次一致、与另一个来源交叉比对。
8. 请求头（Referer / UA）也保持像正常浏览 —— 这一关不看，真实站点会看。
9. 答案不对时，先怀疑数据来源，再怀疑算法。这一关就是专门治”算法没问题但结果是错的”。
10. 被污染之后重新抓一遍，看看数字有没有变：变了说明还在冷却里。

FAQ#

Q：这关有加密吗？ 没有。这一关就是要说明：反爬不一定是加密。校验可见性、校验一致性，是抓数里最容易被忽略、又最便宜有效的两道防线。

Q：为什么隐藏行的金额不写成离谱的大数？ 因为那样只会提醒你”这行是假的”。真实蜜罐的原则是”像”—— 同量级、同格式，让它在汇总里悄悄偏掉，你只会觉得”怎么算都不对”。

Q：Playwright 的 is_visible() 说隐藏链接是可见的？ 对，它只看有没有 1×1 的盒子。判断”人能不能看见”要看位置和尺寸：box["x"] < 0、宽高 ≤ 1px 的，都不该去点。

Q：能绕过污染吗？ 等冷却到期就行（背几个 45 秒）。但真正要练的是”别踩”：只抓该抓的、只带该带的参数 —— 真实站点的污染不会自己到期。

Q：页脚的「本页 10 条」是不是太便宜我了？ 它是这一关的”校验基准”。真实页面上到处都有这种基准（条数、合计、校验位、编号规律），只是大多数人抓完就走，从来不看。

现象#

1. 打开靶场，页面上是一张 10 行的数字表 + 一排页码按钮 1 2 3 4 5：前 4 个正常，第 5 个按钮上挂着一把小锁。
2. 点 1~4 任意一页，表里的数字马上换掉 —— 页面自己签好 Cookie 再请求，你什么都不用管。
3. 点第 5 页，页面只会给你一句话：

1
第 5 页不在页面里 —— 得自己把签名算出来（算法就在 /static/sign/sign.js 里）

1. F12 → Network，整关只有两条接口（都是在登录之后发的）：

1
GET /api/challenges/CH-014/init          -> {"cookie_name":"sign","total_pages":5,"visible_pages":4,"page_size":10}
2
GET /api/challenges/CH-014/data?page=1   -> 200 {"code":"0","data":[362,783,...]}   ← 必须带 sign Cookie
3
GET /api/challenges/CH-014/data?page=5   -> 403（页面没给它签）

1. Application → Cookies 里能看到那个 Cookie：

1
sign = 2v6ewxxz9cPu3Sp24OI_4K…

一眼就看得出不是标准 base64：里面出现 - _，也没有末尾的 =。

1. 三个「不能作弊」的细节，F12 里试两下就知道：

页面上的 reason 字段只是给排查用的粗分类，真实提示只有一句「签名无效或已过期」。服务端不会告诉你差在哪，cookie=... 的原文只写服务端日志。

分层：这一关要拆七层#

七层里没有一层用到真正的秘密：L2 的盐、L5 的表、L7 的字母表，全都在前端那一份 JS 里明摆着 —— 只是被混淆器换了个长相。

第一步：先把 Cookie 的用法搞清楚#

别急着读算法，先确认签名绑了什么，这决定了你要重算什么：

1
init = session.get("/api/challenges/CH-014/init").json()
2
# {"cookie_name": "sign", "total_pages": 5, "visible_pages": 4, "page_size": 10}
3

4
session.cookies.set("sign", "")                       # 不给签名
5
session.get("/api/challenges/CH-014/data?page=1")     # -> 403 missing
6

7
session.cookies.set("sign", cookie_of_page_1)         # 拿第 1 页的
8
session.get("/api/challenges/CH-014/data?page=5")     # -> 403 page

三个结论：

• 签名是按页签的（页码进签名），所以第 5 页不能复用第 4 页的 Cookie；
• 签名是按时签的（时间戳进签名，窗口 5 分钟），所以抄一个 Cookie 存起来慢慢用会过期；
• 签名只认 Cookie，不认 query / header，名字由 /init 下发（sign）。

到这一步你已经能画出要重算的东西：给定页码 page，算出 sign 的合法值 = 过一遍七层。时间戳用当前毫秒就行。

第二步：把混淆脚本扒开（只有两招障眼法）#

/static/sign/sign.js 是 JavaScript Obfuscator 的产物：控制流平坦化、十六进制变量名、死代码、字符串数组……别硬读。这个混淆器在这里其实只用了两招真正影响「能不能抄表」的手法：

1
[0x2*0x508+0x2117+-0x2a64, 0x1a42+-0x2178+0x27f*0x3, -0x10c1+-0xc43+0xf0*0x1f, ...]

1
var _0x5d73a6 = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=';
2
//   标准 base64 是 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/='

1
import base64, re
2

3
JS_B64 = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/="
4
STD_B64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="
5

6
def grab_tables(sign_source: str):
7
    # ① S-box：混淆器把数字写成算术表达式，求值即可（只放行十六进制字面量和 +-*）
8
    sbox = []
9
    for block in re.findall(r"\[[^\[\]]{300,}\]", sign_source):
10
        parts = block[1:-1].split(",")
11
        if len(parts) == 256 and all(re.fullmatch(r"[-+0-9a-fx*]+", part) for part in parts):
12
            sbox = [eval(part) & 0xFF for part in parts]
13
            break
14

15
    # ② 字母表：字符串数组项是「换过字母表的 base64」
16
    alphabet = ""
17
    for token in re.findall(r"'([A-Za-z0-9+/=]{40,})'", sign_source):
18
        fixed = token.translate(str.maketrans(JS_B64, STD_B64))
19
        decoded = base64.b64decode(fixed + "=" * (-len(fixed) % 4)).decode("ascii", "replace")
20
        if len(decoded) == 64 and len(set(decoded)) == 64:
21
            alphabet = decoded
22
            break
23
    return alphabet, sbox

第三步：把七层用 Python 复刻一遍#

从 参考代码/s16.py 里摘出核心（完整版见文件）：

1
def sign(page, timestamp_ms, *, alphabet, sbox):
2
    body = f"{int(page)}.{int(timestamp_ms)}".encode()          # L1
3
    if len(body) % 16:                                          # ⚠️ 补零要在加密之前
4
        body += b"\x00" * (16 - len(body) % 16)
5

6
    key = hashlib.md5(b"LS14.spot2026").digest()                # L2
7
    stream = hashlib.md5(key).digest()                          # L3 的密钥流
8

9
    encrypted, previous = bytearray(), 0                        # L3 链式 XOR
10
    for index, byte in enumerate(body):
11
        value = byte ^ stream[index % 16] ^ previous
12
        encrypted.append(value)
13
        previous = value
14

15
    transposed = bytearray()                                    # L4 4×4 转置
16
    for start in range(0, len(encrypted), 16):
17
        block = encrypted[start:start + 16]
18
        for column in range(4):
19
            for row in range(4):
20
                transposed.append(block[row * 4 + column])
21

22
    substituted = bytes(sbox[byte] for byte in transposed)       # L5 S-box
23

24
    mixed = bytearray()                                         # L6 位置混淆
25
    for index, byte in enumerate(substituted):
26
        bits = index % 7 + 1
27
        value = (byte + index * 7 + 13) & 0xFF
28
        mixed.append(((value << bits) | (value >> (8 - bits))) & 0xFF)   # 循环左移 bits 位
29

30
    accumulator, bits, out = 0, 0, []                           # L7 自定义 base64（无 padding）
31
    for byte in mixed:
32
        accumulator = (accumulator << 8) | byte
33
        bits += 8
34
        while bits >= 6:
35
            bits -= 6
36
            out.append(alphabet[(accumulator >> bits) & 0x3F])
37
    if bits:
38
        out.append(alphabet[(accumulator << (6 - bits)) & 0x3F])
39
    return "".join(out)

四个「一抄就错」的地方，全是我踩过的：

1. 补零必须在加密之前。先加密再补零，那些零没被加密，服务端倒推回来就是垃圾 —— 表现为「怎么算都 403」，而且看不出原因。
2. L6 是位置相关的：正着来的顺序是「先加偏移、再循环左移」，所以逆着来要先循环右移、再减偏移。顺序反了同样只是「403 看不出原因」。
3. 逆层顺序要严格反着：正向是 L4 转置 → L5 S-box，所以解的时候先逆 L5（用逆 S-box），再逆 L4。这两层写反是这一关最容易犯的错。
4. 如果顺手用 JS 对照实验，注意 JS 的 >> 是带符号右移：写循环左移必须是 (v << c) | (v >>> (32 - c))；另外 x >>> 56 会把位移量按 32 取模变成 x >>> 24，处理 64 位长度时得拆成高低 32 位分别写。

第四步：怎么确认自己抄对了（不用猜）#

页面自己签的前 4 页就是现成的答案，拿它当测试向量：

1. F12 → Application → Cookies，把第 1 页那次请求的 sign 值抄下来；
2. 时间戳没法从 Cookie 里看出来（它被加密了），但能猜：签名就是刚刚这一分钟里生成的，于是从「当前时间」往前一秒一秒试：

1
for offset in range(120):
2
    guess = int(time.time() * 1000) - offset * 1000
3
    if sign(1, guess, alphabet=alphabet, sbox=sbox) == sampled_cookie:
4
        print("对上了：七层还原正确，时间戳 =", guess)
5
        break

参考代码/s16.py 的自检段就是这么干的。对上了再往下走 —— 这一关只要你把七层还原对了，后面的活就只有拼请求了。

另外两个顺手的对照点：

• 解出来的明文必须是 b"1.1760000000000" 这种形状（页码.毫秒，尾部补零要去掉）；
• 长度必须对得上：页码.毫秒 是 15 个字符 → 补到 16 → 加密 16 字节 → base64 出来是 22 个字符（无 padding）。长度不对就是 L4/L7 抄错了。

第五步：五页取齐，求和#

1
total = 0
2
for page in range(1, 6):
3
    # 页面只会签 1~4 页，第 5 页得自己签 —— 差别只在这里
4
    cookie = sign(page, int(time.time() * 1000), alphabet=alphabet, sbox=sbox)
5
    session.cookies.set("sign", cookie, domain="spider.jsnote.top")
6
    payload = session.get(f"/api/challenges/CH-014/data?page={page}").json()
7
    total += sum(payload["data"])
8
print(total)   # 提交这个总和

跑法：

1
# 1) 浏览器登录靶场，F12 -> Application -> Cookies，抄下 session 的值
2
# 2) 填进 参考代码/s16.py 的 SESSION_COOKIE
3
python 参考代码/s16.py

脚本会先把两张表从 sign.js 里抠出来，再让你粘一个页面上的 sign 做自检，然后老老实实签 5 次、取 5 页、求和。

每个账号的 50 个数字是按账号派生的（同一个人稳定、人与人不同），所以别拿别人的总和去提交。

这一关真正要记住的：为什么「七层」不解决问题#

• 盐、S-box、字母表全在前端 = 读者即拥有者。混淆只是把「读代码」变成「费点劲读代码」，它挡的是懒得读代码的人，不是攻击者。你能还原一次，就能给任意页码、任意时间戳签名。
• 更极端的是本关那条捷径：LSSign.applyCookie(5) —— 能调用就等于能签。哪怕你把算法藏在 VM 里（见 CH-011 / CH-012），只要它必须在浏览器里跑出结果，调用方就一定能拿到结果。
• 正确的做法是密钥不出服务端：用 HMAC 对参数签名（服务端持密钥）、或服务端下发一次性 token、再叠上服务端风控和限速。本站 CH-005 就是这个套路（HMAC-MD5 签名 + 会话绑定），CH-010 是另一个变体（RSA 公钥在前端、私钥在服务端）—— 那两关的「客户端多算一层」是为了不泄密，而不是为了加密给别人看。

排查清单（⚠️ 先看前三条）#

1. 403 且 reason 是 format / 怎么算都不对：九成是补零顺序、逆层顺序（先逆 L5 再逆 L4）、或者 L6 的移位/偏移反了。
2. 403 且 reason 是 page：Cookie 里签的页码和 ?page= 不一致 —— 别复用别的页的签名。
3. 403 且 reason 是 expired：时间戳是毫秒，而且服务端只认 5 分钟内；本地时间跑偏也会踩到。
4. 长度不对（不是 22 / 44 …）：L4 的转置块大小别写成别的数，body 要补齐到 16 的倍数。
5. 抠出来的 S-box 只有 255 项 / 有重复：正则抓歪了（别用 \d+，产物里是十六进制表达式）。
6. 解出来的字母表里有 + / 但没有 64 个字符：忘了把混淆器那个大小写调换的字母表换回标准 base64。
7. 自检一直对不上：先确认你抄的那个 sign 是不是同一页的、以及是不是刚刚才生成的（超过 5 分钟就没意义了）。
8. 换了账号还是同一批数字：数字是按 user_id 派生的，换个账号当然就变了 —— 别把数字硬编码进脚本。
9. 请求 401：session Cookie 没带上（域名 / path 设错了）。
10. 想省事直接用 LSSign.applyCookie(5)：能过，但那就只是「调用」而不是「还原」；本关的分数想拿得踏实，还是把七层写出来。

FAQ#

Q：为什么非要有 L4 转置和 L6 移位这种”看不出用途”的层？ 真实站点也这么干：层数本身就是门槛。对写脚本的人来说，多一层就要多对一次答案；对防护方来说，成本几乎为零。理解了这一点，你就知道为什么看到「七层加密」不该先慌。

Q：verify 为什么不直接返回「第几层解错了」？ 服务端只回一句「签名无效或已过期」，原因写日志。真实站点也这样 —— 把失败原因告诉调用方，等于给自动化脚本送调试信息。

Q：我能不能只逆推出「第 5 页」而不实现正向签名？ 可以，但要先用正向实现自检一次：没有测试向量，你不知道自己逆出来的东西是不是对的。这一关最容易走的路是「正向复刻 + 拿 1~4 页的现成 Cookie 自检」。

Q：时间戳是干什么用的？ 它的作用是限时：抄来的 Cookie 只有 5 分钟寿命，逼你现场算签名。真实站点还会把时间戳和会话/随机数绑在一起（一次一密），思路一致 —— 让「重放」失效。

现象#

1. 打开靶场，页面上就是一个普通的登录表单：用户名、密码、一个「登录」按钮，下面用虚线框标出演示账号 demo / demo123（写死在页面上，账号密码也已经填好了，直接点「登录」就行）。
2. 点「登录」—— 弹出一个验证码窗口，标题写着「请点击图中的 N 个文字（不分先后）」。
3. 图上有 3~5 个手写体汉字，散在噪点背景上。每点掉一个，图上会出现一个带序号的红色小圆点；点满 N 下自动提交，窗口里的数字就是这一轮的行为轨迹。
4. Network 里一共四条请求（都是点了「登录」之后才发出去的）：

1
GET  /api/challenges/CH-013/init   -> {"gt":"3f9c...","challenge":"cd5c...","rounds":3,"demo":{...}}
2
POST /api/challenges/CH-013/get    -> {"bg":"/api/challenges/CH-013/image?challenge=...","width":320,"height":160,...}
3
GET  /api/challenges/CH-013/image?challenge=...      -> 图片本体（image/png）
4
POST /api/challenges/CH-013/verify -> 请求体只有 {"gt","challenge","w"}；成功回 {"validate":"...","rounds_left":2}
5
POST /api/challenges/CH-013/login  -> {"username","password","validate"}，验证通过后才回 {"passphrase":"LS13-XXXX-XXXX-XXXX"}

1. w 长这样（两段，用 @ 拼起来）：

1
w = "SBx2K9...（base64，RSA 加密的 AES 密钥）" + "@" + "9kQm...（base64，AES 加密的轨迹 JSON）"

1. 每次都换一张图，也每次都换一个 challenge：/get 返回的 challenge 和 /init 那个不一样，而且用一次就废。
2. 手动点得慢一点、准一点，能过；但如果用脚本「算出中心点 → 瞬间点掉」，坐标全对也会失败 —— 而且服务端只会回一句：

1
{"code":"1","result":"fail","message":"验证失败，请重新完成验证"}

弹窗同时换上一张新图。它不告诉你差在哪（真实站点就是这样，「差多少」不会下发给调用方）—— 详情只写服务端日志：

1
CH-013 验证不通过 user=1 reason=track_uniform_speed detail={"image_id":"00047","speed_stddev":0.0001,...}
2
CH-013 验证不通过 user=1 reason=automation detail={"ua":"...Electron...","chromeKeys":0,"notification":"denied",
3
                                                  "soft":["UA 是 Electron 等嵌入式浏览器","window.chrome 是空的", ...],"score":3}

1. 如果你是用 Playwright / Puppeteer / Selenium 打开的页面，那连”点得准”这一步都到不了 —— 服务端会先看你上报的浏览器环境，判定是自动化就直接拒绝（reason=automation）。这一层就是接下来要拆的第四步。

分层：这一关要拆五层#

第一步：先把流程和 challenge 的用法搞清楚#

四步，和真实的点选验证码（极验那套）是一个套路：

1
init  = session.get(INIT_PATH).json()          # {"gt": ..., "challenge": ...}
2
got   = session.post(GET_PATH, json={"gt": init["gt"], "challenge": init["challenge"]}).json()
3
                                               # 换一张图 → 拿**新**的 challenge + bg + 图尺寸
4
image = session.get(BASE + got["bg"]).content  # 图片本体
5
verify= session.post(VERIFY_PATH, json={"gt": ..., "challenge": got["challenge"], "w": w}).json()
6
login = session.post(LOGIN_PATH, json={"username": ..., "password": ..., "validate": verify["validate"]}).json()

三个坑：

• challenge 是一次性的：/init 给一个（用来换图），/get 再给一个（用来提交）。提交时必须用后一个，用错或者用两次都是 challenge 无效或已过期；
• 验证失败也作废：想再试一次，得重新 /init → /get 换张图，不能对着同一张图反复试坐标；
• validate 也只能用一次：登录接口消费掉就没了。

第二步：认出图上的文字#

数据集只有标注框、没有字符内容（标注的类别就是 word / icon），服务端也不会告诉你答案。所以先得自己做检测：

1
import ddddocr
2
detector = ddddocr.DdddOcr(det=True, show_ad=False)
3
boxes = detector.detection(image_bytes)          # [[x1,y1,x2,y2], ...]

更稳的做法：这个靶场的图本来就来自一个目标检测数据集（仓库里那份 点选验证码目标检测数据集(1)/，VOC 标注，6300 张）。拿它训一个小模型（YOLO 之类），检测效果比通用 OCR 的检测头稳得多 —— 数据集里 labels/ 目录已经是 YOLO 格式了。

⚠️ 识别结果必须”不漏不重”：服务端要求「框全部点到、点击次数等于框的数量」。多认出一个噪点、或者少认一个字，都会直接判失败（错误码 click_count）。识别没把握时，换一张图比硬着头皮提交划算。

第三步：把 w 拼出来（一次一密在这儿）#

w 的结构和 CH-010 那套「RSA 传密钥 + AES 加密报文」像，但多了两处：

1
key_text = ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(16))
2
# ① IV 不是固定值，而是 sha256(challenge) 的前 16 个字符 —— challenge 一换，密文全变
3
iv = hashlib.sha256(challenge.encode()).hexdigest()[:16].encode()
4
cipher = AES.new(key_text.encode(), AES.MODE_CBC, iv)
5
body = base64.b64encode(cipher.encrypt(pad(json.dumps(payload).encode(), 16))).decode()
6
# ② AES 密钥用 RSA 公钥包起来（PKCS#1 v1.5）
7
wrapped = base64.b64encode(PKCS1_v1_5.new(public_key).encrypt(key_text.encode())).decode()
8
w = f"{wrapped}@{body}"

明文的 payload：

1
{"gt": "...", "challenge": "...", "ts": 1760000000000, "size": [320, 160],
2
 "track":  [[dt, x, y], ...], "clicks": [[dt, x, y], ...],
3
 "env": {"webdriver": false, "ua": "...", "globals": [], "chromeKeys": 4, "notif": "default", ...},
4
 "ver": "1.0.2"}

track / clicks 都是增量时间编码：第一个元素的 dt 是「距 ts 多少毫秒」，后面每个是「距上一个点多少毫秒」。ts 是开始采集的时刻（图片刚画出来），size 是图片在页面上的显示尺寸 —— 服务端用它把像素坐标归一化，所以自己算的时候直接用图的原尺寸就行。env 是浏览器环境指纹（第四步要拆的那一层）。

公钥在哪儿？ 不在页面里明文写着，而是被 base64 藏进了混淆产物 security.js。参考代码/s15.py 里的 grab_public_key() 干的就是这件事：把产物里所有 base64 片段「原样 / 大小写翻转」各解两层，谁解出 BEGIN PUBLIC KEY 就是它：

1
for token in re.findall(r"['\"]([A-Za-z0-9+/=]{40,})['\"]", source):
2
    for candidate in (token, token.swapcase()):        # 混淆器把大小写翻转了
3
        outer = base64.b64decode(candidate + pad).decode()      # 第一层：payload（base64）
4
        inner = base64.b64decode(outer + pad).decode()          # 第二层：VM 源码
5
        # inner 里就有 PEM ——顺带还能看到整段采集/加密逻辑

顺带说一句：解出来的那份 VM 源码就是这一关前端的全部逻辑（怎么采轨迹、怎么派生 IV、反调试怎么判断），比动态调试省事得多。

第四步：先过”环境”这一关 —— 自动化浏览器一进门就被认出来了#

这一步很容易被忽略：很多人第一反应是用 Playwright / Puppeteer 打开页面点两下了事。结果会发现怎么点都过不去 —— 因为服务端除了看轨迹，还会把你上报的浏览器环境过一遍。

关于这一层，一个实测出来的事实值得先说清楚：在事件层面是查不出自动化的。

所以这一层是靠静态指纹判的（backend/click_captcha_risk.py 的 check_environment()）。最典型的那种写法 ——

1
browser = p.chromium.launch(headless=False)   # 甚至不用无头

—— 实测下来是这样：

也就是说：裸跑 Playwright，光 navigator.webdriver 这一条就露了，无头还是有头都一样。

硬信号（沾一个就拦）

• navigator.webdriver === true —— Selenium / Puppeteer 的默认值，最经典的自动化标记；
• window 上留着自动化框架的全局变量：cdc_*（ChromeDriver）、__selenium*、__driver_*、__playwright*、__puppeteer*、callPhantom、_phantom、__nightmare、domAutomation……
• UA 里有 HeadlessChrome / PhantomJS / Selenium / Puppeteer / Playwright 字样。

软信号（攒够 2 分才拦 —— 单条会误伤真人）

• UA 是 Electron 这类嵌入式浏览器；
• Object.keys(window.chrome).length === 0（正规 Chrome 有一堆 chrome.* 对象）；
• Notification.permission === 'denied'（headless Chrome 的默认值）；
• navigator.plugins.length === 0；
• window.outerWidth/outerHeight 为 0；
• navigator.languages.length === 0。

脚本页面一加载就会把指纹 POST 给服务端（POST /api/challenges/CH-013/env）—— 也就是说门一开就被登记了，不用等你点验证码。服务端日志当场留一行，页面上也会弹一条提示：

1
CH-013 页面打开即识别 user=1 automation=True signals=["navigator.webdriver = true"] ua=...

怎么知道自己的浏览器报了什么？ 页面上的安全脚本内置了采集函数，控制台里直接看：

1
window.LSClick.collectEnv()
2
// {webdriver: false, ua: "...Chrome/150...", globals: [], chromeKeys: 4,
3
//  notif: "default", plugins: 5, languages: 2, outer: [2048, 1152], ...}

拿这个对照下面的「正规 Chrome 长什么样」：

1
navigator.webdriver                 // false
2
Object.keys(window.chrome)          // ["app","csi","loadTimes","runtime", ...]  ← 不是空数组
3
navigator.plugins.length            // 5
4
Notification.permission             // "default"
5
navigator.languages.length          // 2
6
window.outerWidth, outerHeight      // 都是正数

⚠️ 关键认知：这些字段全是客户端自报的，服务端没法验证真伪。所以这一层只能挡住「不洗指纹就上」的自动化；愿意花力气伪装的人照样能过 —— 这正是反爬的常态：每一层都不是铜墙铁壁，它的价值是把门槛抬高、把成本转嫁给对手。参考解法里的 clean_env() 干的就这件事。

顺带一提，本地开发要拿自动化浏览器测这一关（比如自己写 Playwright 脚本调试），可以在服务端开个后门：

1
LEARNSPIDER_CH013_ALLOW_AUTOMATION=1 python app.py     # 默认关，线上别开

第五步：最难的一关是”像个人”#

坐标对了只是入场券。服务端拿到解密后的轨迹，会同时看结果和过程：

所以「算出中心点 → 直接点过去」必然挂在速度标准差上。要过这一关，得生成一段像人的轨迹：

顺带一提：采样点的「时间间隔标准差」这一条没有。浏览器按帧投递 mousemove，真人的事件间隔同样被量化到 ~16.7ms 且方差极小 —— 拿它当机器特征会大面积误伤真人。这是这关的一个设计取舍：宁可漏判，不可误伤；也提醒你，风控阈值不是越多越好。

1
def human_move(rng, start, end):
2
    """慢-快-慢（ease）+ 手抖。"""
3
    distance = math.hypot(end[0] - start[0], end[1] - start[1])
4
    steps = max(5, int(max(140.0, distance / rng.uniform(0.30, 1.10)) / rng.uniform(9, 17)))
5
    samples = []
6
    for step in range(1, steps + 1):
7
        ratio = step / steps
8
        ease = 3 * ratio ** 2 - 2 * ratio ** 3          # 速度先快后慢，绝不会是常数
9
        samples.append((
10
            max(4.0, rng.gauss(14, 4.5)),                # 事件间隔带抖动（±几毫秒）
11
            start[0] + (end[0] - start[0]) * ease + rng.gauss(0, 1.1),   # 手抖
12
            start[1] + (end[1] - start[1]) * ease + rng.gauss(0, 1.1),
13
        ))
14
    return samples

几个「别省」的细节：

• 别用线性插值 + 等分时间：那正是 speed_stddev ≈ 0 的来源，一条匀速直线就露馅；
• ts 要贴近当前时间：服务端允许 3 分钟误差，超了直接判失败；
• 点之间要”停一下再按”（rng.uniform(90, 260) 毫秒），这也是人手特征；
• 别用 time.sleep(0.3) 这种固定节律：点得多了（≥4 下、3 个间隔）会被看间隔标准差。

第六步：完整脚本#

参考代码/s15.py 把上面五步串成了一条流水线：抠公钥 → init/get → ddddocr 检测 → 洗指纹 → 生成拟人轨迹 → 拼 w → verify → 登录拿口令。核心就四个函数：detect_targets()、clean_env()、build_payload()、build_w()。

跑通后拿到的是通关口令（形如 LS13-XXXX-XXXX-XXXX，按账号派生、唯一），把它提交到挑战广场。

排查清单（⚠️ 先看这一条）#

服务端只说一句「验证失败」，不会告诉你差在哪 —— 真实站点就是这样，把 reason / metrics 下发到页面等于给脚本送调试助攻。所以你只能自己对着上面的阈值表复现：

• 想知道到底挂在哪一条，就把 backend/click_captcha_risk.py 里的判定函数单独跑一遍（check_clicks() / check_timing() / check_track() 都是纯函数，喂进去就能出结论），或者看服务端日志 —— 每次失败都会留一行 CH-013 验证不通过 user=... reason=... detail={...}，里面的 image_id 能对上是哪张图。

常见的几种失败与原因：

FAQ#

Q：为什么图不从 CDN 直接下发，非要服务端代理一层？ A：题库种子（backend/data/click_captcha_seed.json）是随仓库走的，里面每条都带着 image_url 和标注框。要是把七牛的持久化链接直接发到浏览器，image_id 一露，查一眼种子就知道该点哪儿了。代理之后 URL 上只剩一次性的 challenge。

Q：反调试真的会拦我吗？ A：它只做一件事：发现「被断点停住过」就把采到的轨迹清空。不开 DevTools、或者开了但按 Ctrl+F8 停用断点，它完全无害。想读逻辑不必动态跟 —— 把 security.js 里的 base64 解两层，源码就出来了。

Q：识别的准确率不够怎么办？ A：两招。一是换一张图（服务端每次随机给图，识别没把握就重取）；二是拿仓库里那个数据集训一个检测模型 —— 数据就是为这一关准备的。

Q：为什么必须”像人”？ A：这就是行为式验证码的核心：它验证的不是「结果」而是「过程」。真实站点上，哪怕坐标分毫不差，一条匀速直线也会被判定为机器。反过来说，知道它看什么，也就知道该往哪儿使劲 —— 以及知道哪些站点的验证码不该硬闯。

Q：我用 Playwright 怎么点都过不去，为什么？ A：两个可能：环境被判成自动化（reason=automation），或者轨迹太”机械”。先看环境：控制台跑 window.LSClick.collectEnv() 看自己报了什么，再跟上面「正规 Chrome 长什么样」对一遍。要过的话有两条路 —— 洗指纹（像 s15.py 的 clean_env() 那样，用真实浏览器的值伪造一份），或者不走浏览器（自己拼 w，那样连环境字段都是你自己说了算）。

Q：这些环境字段服务端能验证真伪吗？ A：不能。它们全是客户端自报的，服务端只做「像不像正常浏览器」的启发式判断。所以这一层挡的是「不洗指纹就上」的自动化，挡不住愿意花力气伪装的人 —— 这不是缺陷，是这类防护的本来面目：每一层都把成本往上抬一点，最后决定胜负的是对手愿不愿意付出那份成本。

Q：我本地想用自动化浏览器测这一关怎么办？ A：服务端留了开关（默认关，线上不要开）：LEARNSPIDER_CH013_ALLOW_AUTOMATION=1 python app.py，打开后跳过环境检查，行为风控照旧。

现象#

1. 打开靶场，页面上是 10 个四位数字和一个「本页合计」，能翻 5 页，最后一个是灰的。
2. 打开 F12 —— 还没看清代码，Sources 面板就开始周期性断住：断点停在一行看着没什么的调用上，点继续，半秒后又断。这就是时间轮询式反调试。
3. Network 里只有三条请求：

1
GET /api/challenges/CH-012/init     -> {"script_url": "...", "data_url": "...", "total_pages": 5, ...}
2
GET /api/challenges/CH-012/script   -> 一段 JS（Content-Type: text/javascript）
3
GET /api/challenges/CH-012/data?page=1
4
      -> {"code":"0","qz":[...字节数字...],"sig":"b1cd5e3ce7fb9b18e4390f76c27ec005","page":1,...}

1. 那段下发的 JS，静态搜 debugger、setInterval、eval、md5 全都搜不到：

1
var $dbsm_0x5d57 = function (_0x1a2b, _0x3c4d) {
2
  var _0x1a2b = [...'\\x64\\x65\\x62\\x75\\x67\\x67\\x65\\x72', ...];   // 都是转义，看不出是什么
3
  return _0x1a2b[_0x3c4d];
4
};

1. 数据接口返回的 qz 是一串数字（字节值），不是明文；旁边还有 sig 做校验。
2. 直接改 page=6 → {"code":"1","message":"页码超出范围（一共 5 页）"}。

分层：这次要拆的是”下发的代码”#

第一步：先把反调试按住#

下发的脚本里（还原转义后）核心就这几行：

1
function _0x5d57_0x6() {
2
  var t0 = Date.now();
3
  (0, eval)($dbsm_0x5d57(2));                  // 表[2] = 'debugger'
4
  if (Date.now() - t0 > 200) { for (;;) {} }   // 被调试器停住过 → 死循环
5
}
6
w[$dbsm_0x5d57(1)](_0x5d57_0x6, 500);          // setInterval(fn, 500)

三个要点：

• debugger 不是关键字写在源码里，而是从字符串表里取出来、再用间接 eval (0, eval)(...) 执行 —— 所以”在 debugger 那行打个断点”这招没用，静态也搜不到；
• 它用时间差检测调试器：真被断住时 Date.now() 会跳几百毫秒以上，于是主动进死循环； 换句话说，没有调试器时它完全无害（这也就是为什么爬虫脚本可以在无头环境里正常跑）；
• 应对方式：DevTools 按 Ctrl+F8（Deactivate breakpoints），或在 setInterval 被调用前

  1
  window.setInterval = (fn, ms) => (console.log('拦下定时器', fn.toString()), 0)

  更省事的当然是根本不跟调试器。

补充一个通用招数：Function / eval 都是”运行时才出现源码”的典型入口， 给它们加一层 Proxy 就能把参数（也就是被隐藏的代码）打出来：

1
const rawEval = window.eval;
2
window.eval = (src) => (typeof src === 'string' && console.log('eval:', src), rawEval(src));

第二步：把字符串表翻译出来#

$dbsm_0x5d57 就是个数组下标查表，表项写成十六进制转义只是为了别让关键字出现在静态文本里。 在控制台（脚本已加载后）敲一行就全出来了：

1
$dbsm_0x5d57(0)   // '\x6c\x73\x73\x68\x69\x65\x6c\x64' 系列...

或者干脆本地解码（s14.py 里的 decode_qz 一样的思路）：

1
>>> bytes.fromhex("6465627567676572").decode()   # 'debugger'
2
>>> bytes.fromhex("736574496e74657276616c").decode()  # 'setInterval'
3
>>> bytes.fromhex("6576616c").decode()          # 'eval'

翻译完，整段脚本的可读性就回来了：w.LSShield = { decode, split, digest, verify, ready }。

第三步：解 qz（真正的数据）#

数据接口给的 qz 是明文的每个字节异或一个固定值（这一关是 0x5a）， 拿到明文后还能顺手验一下摘要：

1
text = ''.join(chr(b ^ 0x5a) for b in payload["qz"])          # "9725,5484,..."
2
assert md5(text + "qz2026") == payload["sig"]                  # 和内置 MD5 做的是同一件事
3
values = [int(x) for x in text.split(",")]

XOR key 和盐在哪儿？ 就在下发的那段脚本里 —— 而且把它们解出来也能看到： qz 解码后是那支 LSShield 工厂函数的源码，里面明写着

1
return md5(text + 'qz2026').toString();   // 盐
2
bytes[i] ^ 0x5a                           // XOR key

所以 s14.py 的思路是：先解开 qz 拿到源码 → 从源码里正则抠出盐，一步都不用猜。

第四步：五页求和#

init 接口只说有几页（total_pages: 5）。循环翻页、每页解 10 个数字，累加即可：

1
for page in range(1, init["total_pages"] + 1):
2
    payload = session.get(init["data_url"], params={"page": page}).json()
3
    text = decode_qz(payload["qz"], 0x5a)
4
    assert md5(text + salt) == payload["sig"]
5
    total += sum(int(x) for x in text.split(","))

跑出来（参考代码/s14.py）：

1
XOR key = 0x5a，盐 = qz2026
2
第 1 页：10 个数字，本页合计 42584
3
...
4
第 5 页：10 个数字，本页合计 51223
5

6
五页数字总和：251142（提交这个数字）

排查清单#

1. 一开 F12 就反复断住：反调试，Ctrl+F8 停用断点；或先 window.setInterval 打补丁再刷新。
2. 控制台里 LSShield 是 undefined：脚本是页面动态插 <script> 加载的，等它加载完再取； 也可以直接 fetch(init.script_url) 把源码拿下来自己看。
3. 静态搜不到 debugger / setInterval：正常，它们分别由 (0, eval)(表[2]) 和 表[1] 生成。
4. qz 解出来是乱码：XOR key 不对（这一关是 0x5a，注意别用成了别的关卡的 key）。
5. sig 校验不过：盐不对，或者拼盐时多/少了分隔符（是 明文 + 盐，没有分隔符）。
6. code: "1"：页码超范围，一共 5 页。
7. /script 返回 401：接口需要登录态，脚本里要带 Cookie。

常见问题#

Q：为什么要把 JS 放到接口里发，而不是直接写进静态文件？ A：静态文件是”看得见、搜得到、能下载”的；放到接口里至少能按会话下发（每人不完全一样的参数）、能随时改， 还想让你多花一步去”抓代码”。对爬虫来说多了一层”必须先登录、先分析”的门槛。

Q：内置 MD5 有什么用？不是随便就绕过了吗？ A：它的作用不是”加密”（MD5 本来也不可逆），而是自校验 + 提高门槛： 让服务端能确认数据没被乱改，同时逼你读懂它的数据格式。

Q：既然是前端校验，改一下不就行了？ A：可以，但判断题在后端。前端能改的只是”你自己看到的”；数据、答案、判分都在服务端， 所以正确姿势是还原算法，不是改前端。

最后提醒#

这些手段只适合在授权范围内的练习环境里研究。真实站点有服务条款和技术措施保护，绕过它们可能违法。

现象：请求头里有个看不懂的长串#

打开靶场，F12 → Network，只有一条 POST /api/challenges/CH-010/data：

1
sm: NBUhZ9tR...（很长的 base64）@P1q8oX...（另一段 base64）

• 没有请求体：参数全在 sm 里；
• 响应体不是 JSON：一串 base64 文本；
• 页面上的 5 个页码里最后 1 个是灰的，怎么点都不动；
• 把这条请求「Copy as cURL」重放一次 —— 大概率报 请求已过期。

辨型：两段字符 = RSA 传密钥、AES 传报文#

真实站点（spa16.scrape.center 那一类）就是这套组合拳，原因很实在：

所以 sm 的两段是：

1
sm = base64( RSA_PKCS1_v1_5(AES 密钥明文) )  +  "@"  +  base64( AES-128-CBC(明文 JSON) )

定位资源：脚本里躺着的三件套#

<head> 里依次加载三个脚本：

1
/static/vendor/crypto-js.js        # AES（和第 11 关共用一份）
2
/static/vendor/jsencrypt.min.js    # RSA
3
/static/books/security.js                # 混淆过的业务逻辑：生成 sm + 解密响应

security.js 是 JavaScript Obfuscator 的产物：字符串全部收进数组、控制流被平坦化、还塞了死代码。别人怎么挖它的？两条路：

1. 动态 hook（最快）——在控制台劫持几个函数，刷新页面，参数自己就打印出来了：

1
const raw = JSEncrypt.prototype.setPublicKey
2
JSEncrypt.prototype.setPublicKey = function (key) { console.log('PUBLIC KEY =\n' + key); return raw.call(this, key) }
3

4
const enc = CryptoJS.AES.encrypt
5
CryptoJS.AES.encrypt = function (plain, key, cfg) { console.log('明文:', plain, '密钥:', key.toString(CryptoJS.enc.Utf8)); return enc.apply(this, arguments) }

1. 静态解混淆——用 de4js / synchrony 之类的工具还原字符串数组。注意：混淆器不只做了 base64，还把结果大小写翻转了一遍，所以直接 grep BEGIN 是搜不到的。把数组元素抓出来，swapcase() 之后再 base64 解码，才能看到 PEM：

1
for token in re.findall(r"['\"]([A-Za-z0-9+/=]{40,})['\"]", security_source):
2
    for candidate in (token, token.swapcase()):
3
        text = base64.b64decode(candidate + "=" * (-len(candidate) % 4)).decode("utf-8")
4
        if "BEGIN PUBLIC KEY" in text:
5
            print(text)   # ← RSA 公钥到手（公钥本来就是公开的）

还原公式#

1
key_text = 16 个 0-9a-f 的随机串                      # 每次请求现造一个
2
plain    = json.dumps({username, path, timestamp, pageNumber, pageSize})
3
aes_part = base64(AES_CBC_PKCS7(plain, key_text, iv="LS2026CH010IV000"))
4
rsa_part = base64(RSA_PKCS1_v1_5(key_text, public_key))
5
sm       = rsa_part + "@" + aes_part

服务端会逐项核对（顺序大致如下），这就是为什么”复用同一个 sm 重放”必然失败：

页码只有序号：GET /api/challenges/CH-010/init（页面初始化时就会请求）只返回 username、page_count、visible_pages、page_size —— 不告诉你数据库里到底是哪五页。页面只放出前 visible_pages（=4）页，第 5 页只能自己写脚本取。

序号 n 对应哪一页数据由服务端按账号决定（每个账号一套，同人稳定、人人不同），所以在本地自己造一个 sm 去请求序号 1、2、3、4、5，就是你该拿的全部数据。

响应体同样是 AES：base64(AES_CBC_PKCS7(JSON, key_text, 同一个 IV))，用这次请求的 keyText 解。

完整脚本#

见 参考代码/s12.py（grab_public_key + build_sm + decrypt + 逐页汇总）。核心就三行：

1
sm, key_text = build_sm(public_key, username, page, page_size)      # 现造密钥并封装（page 是序号）
2
body = decrypt(key_text, session.post(DATA_PATH, headers={"sm": sm}).text)
3
total += sum(row["id"] for row in body["data"]["list"])             # 五页取齐后求和

跑出来大概长这样：

1
账号 xiajiao 的书单：共 5 页（页面只放出前 4 页），每页 18 条
2
第 1 页：18 条，本页 id 合计 123642696
3
...
4
五页书籍 id 总和：601884792（提交这个数字）

排查清单#

1. RSA.import_key 报 “RSA key format is not supported”：PEM 的换行丢了。从混淆产物里解出来的字符串里是 \n 转义，解码后要保留换行（s12.py 里直接 strip() 即可）。
2. 解出来是乱码：IV 不对（必须是脚本里那个 16 字节常量）、密钥长度不对（16 字符 ≠ 16 位十六进制数，是按 UTF-8 取字节）、或者你用了 AES-ECB。
3. 请求已过期：时间戳单位写成了秒，Date.now() 是毫秒。
4. 页码超出范围：序号只有 1..5（/init 的 page_count），别把数据库页码当参数传。
5. 400 报文格式不正确：sm 的分隔符不是 @、RSA 段没做 base64、或者公钥抄错了。
6. 响应解不开：注意用的是本次请求的 keyText，不是第一次那个；每次请求都要重新生成。

常见问题#

Q：为什么不能只 RSA、或只 AES？ A：只 RSA 传不了长报文；只 AES 就得把密钥写在前端（等于公开）。混合加密是两者的折中：密钥每次随机、且只能被持有私钥的服务端读到。

Q：公钥是公开的，那这套加密还有意义吗？ A：有。它防的是「别人拿到你的报文改改就能用」——服务端核对 username/path/timestamp/页码，等于给请求绑上了会话与时效。

Q：为什么不干脆用浏览器自动化点五页？ A：可以，但那是把「每页都要重算密钥」的成本交给浏览器，而且不方便汇总求和。真实项目里更常见的是脚本直连。

最后提醒#

这套东西只在授权范围内的练习环境里练手。真实站点有服务条款和法律法规，未经允许的批量抓取可能违规甚至违法。

现象#

1. 打开靶场，页面数据正常。一按 F12，Sources 面板疯狂断住，断点停在一行看不出名堂的代码上，点继续还会再断 —— 这就是无限 debugger。
2. Network 里只有一条 GET /api/challenges/CH-011/flights?page=1，请求头有个 m：

1
m: 6cee2f75d7dab9a29548288f66fb3025_1790950486

看着像”32 位十六进制 + 下划线 + 秒”。

1. 页面上的票价是 ¥ 后面几个空白的 <span>，源码里搜不到数字：

1
<span class="mv-digit d0a6fd0"></span><span class="mv-digit d2478eb"></span>

1. 直接请求接口（不带 m）→ 403 {"code":"1","message":"请求凭据无效或已过期"}。
2. 只有 5 个页码，最后一个是灰的。

分层：三层伪装，逐一剥#

第一步：让无限 debugger 闭嘴#

它长这样（backend/static/mover/security.js 里的真实逻辑，混淆后更难认）：

1
var KEYWORD = ['de', 'bu', 'g', 'ger'].join('')   // 静态搜 "debugger" 搜不到
2
function spin() {
3
  new Function(KEYWORD)()                          // 每次现编译一次，断点打不住
4
  setTimeout(spin, 700)
5
}
6
spin()

随手可用的几个办法：

• DevTools 里按 Ctrl+F8（或 Sources 面板右上角那个「禁止进入的斜杠图标」）Deactivate breakpoints —— 最省事；
• 在断住的那行右键 Never pause here；
• 控制台先打补丁再刷新：

  1
  window.Function = new Proxy(Function, { apply: (t, a) => { return t(...a) } })  // 甚至顺便 console.log 参数

• 或者根本别跟：这一关的签名不依赖浏览器运行环境，直接 hook + 写脚本更快。

⚠️ 别用 “Disable JavaScript”：页面自己也要靠 JS 取数。

第二步：把盐挖出来#

盐（XJ2026）在 base64 里那份「VM 源码」中。三条路，任选：

a) hook 摘要函数（最快） —— 页面加载了 crypto-js，全局有 CryptoJS：

1
const raw = CryptoJS.MD5
2
CryptoJS.MD5 = (s) => { console.log('md5 输入:', s); return raw(s) }

刷新页面，你会在控制台看到形如 11234567890123XJ2026 的明文：前缀是「页码 + 毫秒时间戳」，后缀就是盐。

b) hook Function，让它把源码吐出来：

1
const rawFunction = window.Function
2
window.Function = new Proxy(rawFunction, {
3
  apply(target, thisArg, args) { console.log('VM 源码：\n' + args[args.length - 1]); return target(...args) },
4
})

刷新后直接能看到那段 base64 解码后的源码（里面就有 SALT 和 buildM）。

c) 静态解 base64 —— 把产物里的长 base64 抠出来 atob。注意混淆器还给字符串做了大小写翻转（和 CH-010 抠公钥一样），所以更推荐 a/b 两条动态路线。

第三步：复现签名#

后端（和参考脚本）都在做同一件事：

1
m = md5(f"{page}{毫秒时间戳}{盐}") + "_" + 秒

几个容易踩的点：

• 毫秒参与摘要，但发出去的只有秒 → 服务端把那一秒内的 1000 个毫秒值各算一遍 md5 来比对（_ch011_verify_m()就是这么做的），所以别把毫秒直接拼进字符串发过去；
• 页码参与签名：用第 2 页的签名去请求第 1 页会被拒；
• 分隔符只能是 ASCII：HTTP 请求头是 Latin-1 的，塞个中文全角括号进去，浏览器会直接报 Failed to read the 'headers' property from 'RequestInit': String contains non ISO-8859-1 code point （真实站点之所以敢用中文括号，是因为它把签名放在 GET 参数里）。

第四步：票价（base64 + CSS）#

接口返回的每一行：

1
{"id": 101, "airline": "中国联合航空", "flight": "KN5911 波音737(中)",
2
 "depart": "13:50", "arrive": "17:30", "duration": "3小时40分",
3
 "value": "MTQ3Mg==",                 // base64("1472")
4
 "cls": ["d46c76e", "d0a6fd0", "de8a727", "d0041c8"]}

页面把 cls 逐字渲染成空 span，然后往 <head> 插一份 CSS：

1
[class~="d46c76e"]::before { content: "1" }
2
[class~="d0a6fd0"]::before { content: "4" }
3
...

所以在 DOM 里 textContent 永远是空的 —— 数字只活在样式表里。写脚本的人不用管这一层：base64 解开就是数字。

完整脚本#

见 参考代码/s13.py。核心就三行：

1
m = build_m(page)                                    # md5(page + 毫秒 + 盐) + "_" + 秒
2
payload = session.get(DATA_PATH, params={"page": page}, headers={"m": m}).json()
3
total += sum(int(base64.b64decode(row["value"])) for row in payload["data"])

跑出来：

1
共 5 页（页面只放出前 4 页），每页 10 条
2
第 1 页：10 条，本页合计 11111
3
...
4
五页票价总和：65635（提交这个数字）

排查清单#

1. 403 请求凭据无效或已过期：盐不对 / 页码没参与签名 / 时间戳用了秒（参与摘要的必须是毫秒）/ 本机时间与服务器差太多。
2. 浏览器报 String contains non ISO-8859-1 code point：请求头里放了非 ASCII（比如中文括号）。
3. 一开 F12 就断：Ctrl+F8 停用断点，或给 Function 打补丁。
4. 自己 new Function(payload) 报 SyntaxError：函数体要先 atob 解码；另外 Function 的最后一个参数才是函数体，前面的都是形参名（别把 base64 当形参名传）。
5. 页面价格是空白：正常现象 —— 数字在 CSS 里（mv-digit 的 ::before）。用 getComputedStyle(el, '::before').content 才能看到。

常见问题#

Q：这算”反爬”还是”反调试”？ A：这几种手法在真实站点里通常一起出现（机票、电商比价那类页面尤其多）：拖慢你读代码的速度，同时用签名保证请求是”当场生成”的。

Q：为什么非要 md5 不可？ A：它只是个便宜的摘要：既能让服务端判断”这个请求是照着我的算法生成的”，又不至于像 HMAC 那样给客户端一把真钥匙（客户端 JS 里的东西都能被扒出来，本质上是”提高门槛”，不是”绝对安全”）。

Q：既然盐能扒出来，签名还有意义吗？ A：有。它把”随便构造请求”变成”你得先看懂我的 JS”，并且配合时间戳让旧签名很快失效。

最后提醒#

这些手段只适合在授权范围内的练习环境里研究。真实站点有服务条款和技术措施保护，绕过它们可能违法。

先搞清楚这一关在考什么#

前几关的坑通常藏在接口里，这一关反过来：页面是 Jinja2 服务端渲染的，电影数据直接写进了 HTML 源码。

所以拿到数据的方式只有一个：把页面请求下来，读源码。

但答案不是「抓到了哪些电影」，而是第一页源码有多少个字符。也就是说：

1. 请求 GET /playground/movies/static（不加参数就是第 1 页）；
2. 把响应体当成文本（不是字节）数长度；
3. 把数字提交到挑战广场。

现象：源码里全是数据#

浏览器打开靶场页 /playground/movies/static，页面上是电影卡片。右键「查看网页源代码」，能看到 <li> 里直接写着电影名、评分、评价人数：

1
<li class="movie-item">
2
  <h3 class="movie-title">肖申克的救赎</h3>
3
  <span class="movie-rating">9.7</span>
4
  <span class="movie-rating-count">3235402人评价</span>
5
</li>

Network 面板里只有一个 document 请求，没有 XHR。这就说明数据在 HTML 里，而不是接口里。

三个最容易数错的地方#

还有一个隐蔽的坑：编码。如果 response.encoding 猜错了（比如把 UTF-8 当 ISO-8859-1），response.text 会变成乱码，字符数也就跟着错。

服务端已经声明了 Content-Type: text/html; charset=utf-8，正常情况下 requests 会照用。求稳可以显式指定：

1
response.encoding = "utf-8"

完整脚本#

1
"""CH-001：答案 = 第一页 HTML 源码的字符数"""
2
import sys
3

4
import requests
5

6
BASE = "https://spider.jsnote.top"
7
PAGE_URL = f"{BASE}/playground/movies/static"
8

9
headers = {
10
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
11
    "Accept-Language": "zh-CN,zh;q=0.9",
12
    "User-Agent": (
13
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
14
        "(KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"
15
    ),
16
}
17

18
response = requests.get(PAGE_URL, headers=headers, timeout=10)
19
response.raise_for_status()
20
response.encoding = "utf-8"          # 显式指定，避免猜错编码导致字符数不对
21

22
html = response.text
23
print("状态码：", response.status_code)
24
print("Content-Type：", response.headers.get("Content-Type"))
25
print("源码字符数：", len(html))
26
print("源码字节数（对比用）：", len(response.content))
27
print("页面里有没有电影名：", "movie-title" in html)
28

29
if len(sys.argv) > 1:
30
    # 顺手核对一下第一页有多少部电影
31
    print("电影卡片数：", html.count('class="movie-item"'))

跑完把 源码字符数 提交到挑战广场的 CH-001 答题框即可。参考实现见 参考代码/s1.py。

顺手确认一下「第 2 页也这样」#

1
page2 = requests.get(PAGE_URL, params={"page": 2}, headers=headers, timeout=10)
2
print(len(page2.text))   # 和第一页长度不同，说明确实在分页

这一关只需要第一页；但确认「改了参数内容会变」是好习惯 —— 能避免你把一个静态的缓存页当成接口。

排查清单#

1. 源码里搜页面上确定存在的字（电影名），搜得到 → 数据在 HTML 里。
2. 数长度前先确认 response.encoding，别让乱码影响字符数。
3. 用 .text（字符）还是 .content（字节）先想清楚，两者差 2~3 倍。
4. 不要 .strip()、不要 re.sub(r"\s+", "") —— 这一关答案要的就是原始长度。
5. 提交答案要在登录状态下做。
6. 如果数出来差一点点，先对比 len(html) 和 len(html.encode("utf-8"))，确认自己数的是字符。

常见问题#

最后提醒#

这关的数据是自己靶场的练习数据。真实站点里，服务端渲染页通常还带缓存与 CDN，抓之前先看 robots 与条款，控制频率。

去挑战广场提交答案，然后进 CH-002：数据会从源码里消失，只剩接口。

现象：源码里没有数据了#

打开 /movies?challenge=CH-002，电影卡片正常显示。但「查看源代码」里搜不到任何一个电影名 —— 页面是 Vue 渲染的，数据只能来自 XHR。

F12 → Network → Fetch/XHR，刷新页面，会看到一个请求：

1
GET /api/movies?page=1&page_size=12

响应长这样（字段是精简过的）：

1
{
2
  "items": [
3
    {
4
      "title": "肖申克的救赎",
5
      "rating": 9.7,
6
      "rating_text": "9.7",
7
      "rating_count_text": "3235402人评价",
8
      "rating_count": 3235402
9
    }
10
  ],
11
  "page": 1,
12
  "page_size": 12,
13
  "total_movies": 249
14
}

接口故意不给你的东西#

/api/movies 不会下发整批统计字段：

所以「直接读一个字段就交卷」这条路被堵死了，必须一页一页取回来自己累加。

顺带说一句：page_size 上限是 100。想「一次要 1000 条」也会被服务端截回 100。

数据规模#

• 共 249 部电影，每页 12 条 → 21 页（最后一页可能不满）。
• 判断翻页结束的两种写法：page * page_size >= total_movies，或者某一页返回的 items 为空。

完整脚本#

1
"""CH-002：答案 = 全部电影「评分总人数」之和"""
2
import re
3
import time
4

5
import requests
6

7
BASE = "https://spider.jsnote.top"
8
API_URL = f"{BASE}/api/movies"
9
PAGE_SIZE = 12
10

11
session = requests.Session()
12
session.headers.update({
13
    "Accept": "application/json, text/plain, */*",
14
    "Accept-Language": "zh-CN,zh;q=0.9",
15
    "Referer": f"{BASE}/movies?challenge=CH-002",
16
    "User-Agent": (
17
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
18
        "(KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"
19
    ),
20
})
21

22
# 数据是按账号派生的，所以要带登录态：
23
# 浏览器登录后 F12 -> Application -> Cookies -> 复制 session 的值
24
session.cookies.set("session", "<把浏览器里的 session cookie 粘到这里>",
25
                    domain="spider.jsnote.top")
26

27

28
def rating_count(movie):
29
    """优先用字段，字段缺失/为 0 时回头从 '3235402人评价' 里抠数字。"""
30
    count = movie.get("rating_count") or 0
31
    if count:
32
        return int(count)
33
    match = re.search(r"([\d,]+)\s*人评价", movie.get("rating_count_text", ""))
34
    return int(match.group(1).replace(",", "")) if match else 0
35

36

37
def main():
38
    page = 1
39
    total_movies = None
40
    total_count = 0
41
    movies = 0
42

43
    while True:
44
        response = session.get(
45
            API_URL, params={"page": page, "page_size": PAGE_SIZE}, timeout=10
46
        )
47
        response.raise_for_status()
48
        payload = response.json()
49

50
        items = payload.get("items", [])
51
        if not items:
52
            break
53

54
        total_movies = payload.get("total_movies", total_movies)
55
        for movie in items:
56
            total_count += rating_count(movie)
57
            movies += 1
58

59
        print(f"第 {page:>2} 页：{len(items)} 条，累计 {movies} 条，"
60
              f"评价人数小计 {total_count}")
61

62
        if total_movies and movies >= total_movies:
63
            break
64
        page += 1
65
        time.sleep(0.5)          # 别把靶场当压力测试
66

67
    print(f"\n共 {movies} 部电影，评价人数总和：{total_count}")
68

69

70
if __name__ == "__main__":
71
    main()

把最后的数字提交到 CH-002 答题框即可。

排查清单#

1. 源码里搜不到数据 → 打开 Network 的 Fetch/XHR，找首屏那个请求。
2. 右键 → Copy as cURL，先在终端跑通一次，确认只差 Cookie。
3. 看响应里有没有现成的总量字段；有就省事，没有就老老实实翻页。
4. 翻页前先拿 total_movies 和 page_size 算出总页数，别写成死循环。
5. 每页间隔 0.5s 以上。
6. 解析用字段优先、文本兜底（rating_count 拿不到就正则 ([\d,]+)人评价）。
7. 累加前把一千分隔符去掉（"1,234" → 1234）。
8. 结束条件写成「取到的条数 ≥ 总数」或「这一页为空」，不要写「拿到 21 页」。

常见问题#

最后提醒#

翻页是很典型的「礼貌爬取」场景：按页取、留间隔、别并发轰炸。真实站点上，疯狂翻页最容易触发限流甚至封号。

去挑战广场提交，然后进 CH-003：数据不再是文本，而是一个你猜不到路径的文件。

现象：图片地址在页面源码里找不到#

在挑战广场点开 CH-003，抽屉里有一个「获取图片」按钮。点一下，页面会请求：

1
GET /api/challenges/CH-003/image

响应：

1
{
2
  "challenge_id": "CH-003",
3
  "image_id": "e33a1790898939fa",
4
  "image_url": "https://spider.jsnote.top/api/challenges/CH-003/image/e33a1790898939fa"
5
}

图片本体在 image_url 上，但它不是磁盘文件名：

• 磁盘上图片一直叫 challenge-01.jpg、challenge-02.jpg（稳定名字，方便维护）；
• 对外暴露的是随机的 image_id，接口用它反查磁盘文件再 send_file。

所以「猜路径下载」这条路是堵死的：每次都要先调一次接口拿 image_id + image_url。

目标是「字节数」不是「字符数」#

图片是二进制，正确姿势是 len(response.content)：

而且这次提交不只是填一个数字：还要带上 image_id，服务端要靠它找到你这一张图去核对大小。

完整脚本#

1
"""CH-003：答案 = 随机下发那张图片的字节数（提交时带 image_id）"""
2
import requests
3

4
BASE = "https://spider.jsnote.top"
5
PICK_URL = f"{BASE}/api/challenges/CH-003/image"
6

7
session = requests.Session()
8
session.headers.update({
9
    "Accept": "*/*",
10
    "Referer": f"{BASE}/",
11
    "User-Agent": (
12
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
13
        "(KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"
14
    ),
15
})
16

17
# 图片是按「当前会话」下发的，并且提交要带登录态 —— 整个流程用一个 Session + 登录 cookie
18
session.cookies.set("session", "<把浏览器里的 session cookie 粘到这里>",
19
                    domain="spider.jsnote.top")
20

21

22
def main():
23
    # 1) 先让服务端发一张图
24
    pick = session.get(PICK_URL, timeout=10)
25
    pick.raise_for_status()
26
    data = pick.json()
27
    image_id = data["image_id"]
28
    image_url = data["image_url"]
29
    print("拿到图片：", image_id)
30

31
    # 2) 用返回的地址下载本体（别自己拼路径：路径就是随机 image_id）
32
    image = session.get(image_url, timeout=20)
33
    image.raise_for_status()
34

35
    size = len(image.content)                 # ⚠️ content（字节），不是 text（字符）
36
    print("Content-Type：", image.headers.get("Content-Type"))
37
    print("Content-Length（服务端声明的）：", image.headers.get("Content-Length"))
38
    print("实际字节数：", size)
39

40
    # 存的文件是个 JPEG：开头 FFD8
41
    print("文件头：", image.content[:4].hex())
42

43
    print(f"\n答案：{size}  （提交时 body 带上 image_id = {image_id}）")
44
    print("提交示例：POST /api/challenges/CH-003/submit "
45
          f'{{"answer": {size}, "image_id": "{image_id}"}}')
46

47

48
if __name__ == "__main__":
49
    main()