全栈攻城狮

Appearance

行为检测与反脚本 ​

概述 ​

协议加密挡得住抓包，服务端权威挡得住改数据，但脚本外挂（自动点击、自动对局、多开挂机）用的是完全合法、却异常频繁或机械重复的操作。行为检测从"人的行为特征"出发识别脚本：操作频次、节奏规律、IP 聚集、设备指纹。本文讲清楚四类检测模型的落地方式。

一、操作频次检测模型 ​

1.1 频次维度 ​

人类操作特征：
  频率有上限（手速、APM）
  有思考间隙（决策时间）
  节奏有波动（不可能完美均匀）

脚本特征：
  频率超过人类上限
  间隔完全均匀
  全天无休息（不睡觉不吃饭）
// 基础频次限制（协议层）
// 单位时间操作数上限
if (counter.incrementAndGet(key) > LIMIT) {
    return reject(TOO_FAST);
}
// 滑动窗口（Redis ZSet 或令牌桶）防突发

1.2 滑动窗口计数 ​

方案对比：
  固定窗口：临界点可突破（00:59 与 01:00 各刷一次）
  滑动窗口：任意 60s 内计数（更准）
  令牌桶：平滑限速（允许小突发）

// 滑动窗口（Redis ZSet）
long now = System.currentTimeMillis();
redis.zremrangeByScore(key, 0, now - 60_000);  // 清旧
long cnt = redis.zcard(key);                    // 窗口内计数
if (cnt >= LIMIT) return reject(TOO_FAST);
redis.zadd(key, now, seq);                      // 记录
redis.expire(key, 60);

1.3 频次之外的节奏特征 ​

节奏特征（脚本识别）：
  操作间隔标准差过小（过于规律）→ 疑似脚本
  间隔符合固定周期（如精确 500ms）→ 疑似脚本
  点击坐标完全一致/等差 → 疑似脚本

// 间隔方差计算（流式）
double mean = ...;   // 维护最近 N 次间隔均值
double variance = ...;
if (Math.sqrt(variance) < EPSILON) {
    flag("间隔过规律");   // 疑似脚本
}

二、异常行为模式分析 ​

2.1 规则引擎 ​

规则引擎（先上线，可解释）：
  胜率异常：连续 N 场胜率 100%（超出概率）
  收益异常：单位时间收益超阈值（刷资源）
  时间异常：24 小时在线、凌晨固定时段活跃
  账号异常：新手期直接高段位操作

规则示例：
  IF 对局时长 < 3s 且连续 50 场 THEN 挂机/脚本
  IF 每日收益 > 均值 × 10 THEN 疑似刷资源
  IF 同设备 24h 内登录 > 20 账号 THEN 多开
// 规则引擎框架
Rule { name, condition(上下文), action(标记/处罚) }

// 示例：对局时长过短
if (battle.duration < 3000 && battle.continuousCount > 50) {
    risk.mark(RISK_SCRIPT, "对局时长异常");
}

2.2 机器学习（辅助） ​

机器学习方案：
  特征：频次、间隔、操作序列、时长分布、收益曲线
  模型：隔离森林（无监督异常检测）、梯度提升（有监督）
  样本：历史封禁账号行为作为正样本

落地注意：
  先规则后模型（规则可解释、易迭代）
  模型给"风险分"，规则给"确定性"
  误杀控制（先观察后处罚）
  特征持续回流迭代
// 风控评分流程
int score = 0;
score += ruleEngine.evaluate(ctx);     // 规则命中加分
score += mlModel.predict(ctx) * 100;   // 模型风险分
if (score > HIGH)  { 立即封禁 }
if (score > MEDIUM){ 观察标记 + 人工复核 }
if (score > LOW)   { 记录日志，累积 }

2.3 处罚梯度 ​

处罚梯度（从轻到重）：
  L1 提醒/限制：验证码、限速、临时禁操作
  L2 软封：限制收益、降匹配优先级、警告
  L3 硬封：封禁账号/设备，需申诉
  L4 法务：涉及黑产/诈骗走法律途径

原则：
  先给低风险处理（验证码拦截）
  高风险直接封禁
  申诉渠道（防误杀）

三、同 IP 多账号检测 ​

3.1 聚集特征 ​

多开/工作室特征：
  同 IP 大量账号（IP 聚集）
  同设备大量账号（设备聚集）
  注册时间集中（批量注册）
  行为相似（同脚本同节奏）

检测维度：
  IP：单位 IP 在线账号数、注册数
  设备：单位设备账号数（见设备指纹）
  时段：账号活跃时段重合度
  资源流向：收益集中转给同一账号
// 同 IP 聚集统计（Redis 计数）
long accounts = redis.sadd("ip:" + ip, accountId);
if (accounts > IP_ACCOUNT_LIMIT) {
    risk.mark(RISK_MULTI_ACCOUNT, "IP 聚集: " + ip);
}

3.2 资源流动检测 ​

工作室特征（重点）：
  产出账号（脚本打金）→ 集中转移 → 主账号（出售）
  小额多笔、跨账号频繁转账
  转入转出时间集中

检测：
  转账图分析（转账网络）
  出金账号标记（转入量 > 阈值且无对等游戏行为）
  限制：交易给陌生账号需二次验证
// 出金检测
// 账号 A 频繁转出到多个小号
// 小号无真实游戏行为（对局数/在线时长近 0）
if (outflowCount > LIMIT && gameDepth == 0) {
    flag(RISK_FARMING, "疑似打金号");
}

四、设备指纹接入 ​

4.1 指纹要素 ​

设备指纹（稳定唯一）：
  硬件：CPU/GPU/主板/硬盘序列号
  系统：OS 版本、语言、时区
  网络：MAC、IP、运营商
  应用：浏览器/客户端版本、UA

获取方式：
  客户端主动上报（加密）
  服务端通过连接信息补充（IP、端口）
  防伪造：多点交叉校验
// 指纹字段（上报）
DeviceFingerprint {
  hardwareId: "xxxx",   // 硬件指纹（不可清除）
  osInfo: "Android 14",
  screen: "2340x1080",
  lang: "zh-CN",
  timezone: "UTC+8"
}

4.2 指纹应用 ​

指纹用途：
  同设备多账号检测（主打击）
  封禁设备（硬封设备 ID）
  设备白名单/绑定（防盗号）
  风控关联（同一指纹的账号打标）

指纹管理：
  指纹库（Redis/数据库）存储
  指纹与账号多对多关系
  指纹可信度（伪造检测）
// 指纹风控查询
String f = getFingerprint(accountId);
long accountsOnDevice = deviceDao.countAccounts(f);
if (accountsOnDevice > DEVICE_ACCOUNT_LIMIT) {
    risk.mark(RISK_MULTI_ACCOUNT, "同设备多账号");
}

五、检测到处置的完整链路 ​

5.1 数据流 ​

行为检测链路：
  埋点：操作日志（见日志审计章节）实时上报
  聚合：频次统计、窗口计数（实时流式）
  判定：规则引擎 + 模型风险分
  处置：限流/验证码/封禁（按梯度）
  反馈：封禁结果回流（模型迭代）

要求：
  实时性（秒级判定）
  低误杀（宁可漏不可误，误杀影响营收口碑）
  可解释（处罚有依据，可申诉）

5.2 防误杀设计 ​

防误杀：
  判定阈值灰度（先观察名单）
  高价值玩家人工复核
  申诉渠道 + 自动解封（首次轻罚）
  指标回看（封禁后对局质量是否改善）
// 处置异步化（不影响主流程）
// 判定结果进 MQ，风控服务消费处置
kafka.send("risk-topic", RiskEvent {...});
// 主流程只记录日志，不因风控阻塞

六、实现要点 ​

行为检测核心：
  频次检测：滑动窗口计数 + 节奏规律
  异常模式：规则引擎 + 机器学习风险分
  同 IP/同设备多账号：聚集检测 + 资源流动
  设备指纹：多要素采集 + 交叉校验
  处置梯度：验证码 → 限流 → 封禁 → 申诉

常见坑：
  只限频次 → 脚本改成慢速也防不住
  规则不灰度 → 误杀正常玩家
  无申诉渠道 → 运营事故
  检测到不处置 → 形同虚设

与其他系统衔接：
  埋点数据 → 日志审计章节
  实时流处理 → 消息队列章节
  封禁能力 → 运营后台 GM 章节
  客户端采集 → 协议加密上报