🔖验证码

滑块验证的两个子问题滑块验证码（极验、顶象、各厂自研）的对抗拆成两个独立子问题：缺口识别（算出滑块要拖多少像素）和轨迹生成（怎么拖得像人）。本文讲第一个。缺口识别的主流方案对比方案准确率成本适用模板匹配85-95%零成本缺口是固定形状贴图边缘检测+轮廓90%+零成本缺口有明显边缘深度学习（YOLO等）98%+要训练干扰多、缺口形态多变打码平台95%+按次付费不想维护任何代码工程上先上模板匹配，准确率不够再升级——大多数滑块的缺口就是一张半透明贴图，模板匹配足够。模板匹配：标准实现滑块验证给两张图：背景图（有缺口）和滑块图（缺口贴图）。核心思路是在背景图上滑动滑块图，找匹配度最高的位置：impo

打码平台在逆向工程里的位置不是所有验证码都值得自己逆。打码平台（人工+AI 混合识别服务）的价值场景：验证码出现频率低（自建识别不划算）题型复杂多变（语序、推理题，自训模型搞不定）快速验证阶段（先跑通流程，再决定是否自建）把它当成一个"识别能力的外包 API"，工程上要做的是标准化对接 + 稳定性兜底。主流平台与协议对接各平台协议大同小异，都是"上传图片 → 返回答案"的两步或一步到位：import requests, base64, time class DamaClient: # 通用打码客户端骨架（以典型协议为例） def __init__(self, platform

极验的版本差异：不只是界面变了极验（geetest）是国内占有率最高的验证码服务，三代和四代是完全不同的协议体系：三代：gt、challenge 双参数体系，验证流程是"初始化 → 拿图 → 提交轨迹 → 二次校验"四代：captcha_id 单参数，流程合并为"加载 → 验证 → 结果"，参数全面加密升级很多站点还在用三代，新接入的基本是四代。逆向前先确认版本：看页面加载的 JS 是 gt.js（三代）还是 gcaptcha4.js（四代）。三代协议流程拆解1. GET /register?gt=xxx → 拿 challenge 2. GET /get

点选验证码的两种形态点选验证码（"请依次点击图中的汉字/图标"）分两种：文字点选：背景图里有几个汉字，按提示顺序点击（极验、网易易盾的经典题型）图标点选：图里一堆小图标，点击与示例相同的（顶象、部分电商自研）对抗链路相同：识别（知道点哪）→ 坐标转换（页面坐标系换算）→ 加密上传（坐标参数的生成）→ 行为模拟（点击节奏）。识别：三条路线路线一：打码平台（最快落地）超级鹰、图鉴、TT 打码等都支持点选题型：上传图片+题型编号，返回坐标序列。成本约 1-3 分/次，准确率 90-95%。适合业务量小或验证频率低的场景。路线二：目标检测模型（规模化首选）自己训练 YOLO 模型识别图标/文字位置：抓

轨迹是滑块验证的核心校验缺口识别对了却验证失败，问题几乎都在轨迹。风控分析的轨迹特征：时间维度：总耗时、各阶段速度分布、停顿次数空间维度：轨迹点的 x/y 分布、直线度、抖动特征物理合理性：加速度是否连续、起止速度是否为 0真人拖滑块的物理特征：先加速、中段匀速或微调、末端减速并对准（过冲-回调），y 轴有随机抖动。机器生成的匀速直线轨迹，在风控眼里就像黑夜里的探照灯。基础方案：匀加速-匀速-匀减速三段式import random def generate_track(distance): # 三段式轨迹：加速 40% + 匀速 30% + 减速 30% track = []