安全与反作弊

Category

server / security 子树。节点定位：客户端在玩家手里且收益可变现——永远不可信但也不能完全放弃，权威判断必须放对位置；反作弊不止外挂检测。security 子树总纲。

Definition

游戏领域的安全问题，和传统 Web 系统既相似又不同。相似的是，它同样要面对账户盗取、接口滥用、权限越权、数据泄露和供应链风险；不同的是，游戏天然存在一个更强的对抗面，因为客户端在玩家手里，且很多收益可以直接转化成排名、虚拟资产甚至现实利润。

Problem

纯靠客户端检测防不住，纯放服务端又没有体验——核心是把权威判断放对位置：结算级判定必须服务端说了算。「客户端说了算」的单局代币四天能刷出 7680 万，这是权威错位的代价。

为什么游戏安全离不开反作弊

很多互联网产品即使没有完美的客户端信任，也仍然能靠服务端权限和交易约束把损害压低。游戏不一样。只要存在下列任一情况，作弊就会直接破坏产品核心价值：

• 对战公平会影响胜负、段位和留存
• 资源产出会影响经济循环和付费转化
• 排行、社交和公会荣誉会影响舆论和生态
• 高价值账号和虚拟道具能被直接变现

这意味着“安全”和“反作弊”不能分家。安全不是一套通用防护壳，反作弊也不是上线后补个检测脚本。二者都必须围绕业务主链路来设计。

客户端永远不可信，但也不能完全放弃客户端

一个成熟团队通常都会接受这个前提：客户端可以被篡改、调试、注入、抓包、回放、加速、模拟和批量控制。因此关键判定必须尽可能放在服务端。但这不代表客户端防护没有价值。

客户端防护仍然有两个作用：

• 提高攻击门槛，让低成本脚本和批量工作室难以规模化
• 为服务端风控提供更多环境信号，例如调试状态、设备特征、完整性校验结果

真正的问题不在于“要不要做客户端防护”，而在于不要把最终安全性寄托在客户端防护上。只依赖壳、加密和反调试，通常只能挡住最表层的攻击。

更重要的是把权威判断放对位置

在游戏里，最需要保护的通常不是所有数据，而是少数关键状态：

• 战斗结果和结算结果
• 货币、道具、抽卡和交易资产
• 匹配资格、段位、排行榜和赛季奖励
• 支付订单、发货状态和退款状态

这些状态如果由客户端说了算，或者服务端只做形式校验，很快就会被利用。更稳妥的做法通常是：

• 由服务端掌握最终结算和关键状态变化权
• 对来自客户端的输入只接受“意图”或“候选动作”，而不是直接接受结果
• 对高价值操作建立幂等、频率限制和异常行为校验

这会增加部分实现复杂度，但它决定的是系统下限。

反作弊不是只有外挂检测

很多人一提反作弊，首先想到的是透视、加速、自动点击、内存修改。实际上，游戏里的作弊和滥用远不止这些：

• 脚本批量起号和工作室养号
• 代充、退款套利和黑卡支付
• 利用配置漏洞、补偿漏洞和活动规则漏洞刷资源
• 群控设备刷活跃、刷邀请、刷广告收益
• 账号共享、代练和违规交易破坏匹配与经济环境

所以反作弊体系通常至少要分成几层：

• 客户端完整性和环境对抗
• 服务端规则校验和异常行为检测
• 经济与交易异常识别
• 社交传播链和账号关联识别
• 处罚、申诉和回滚处置

只有做到最后一层，反作弊才真正形成治理能力。

常见建设方式与代价

依赖第三方安全壳或反外挂 SDK

接入快，能挡掉一部分低水平攻击，也方便应对渠道或平台的最低要求。但它不可能理解你的玩法规则、经济逻辑和资产风险，因此只能作为基础门槛，不能替代核心校验。

业务内规则检测

很多项目会在战斗、支付、活动、交易等核心模块里写大量规则。优点是贴业务，缺点是规则分散、审计困难、迭代慢，容易变成“谁出问题谁补一个 if”。

独立风控与作弊治理平台

更成熟的做法是把高频信号、处罚策略、审计链路和人工复核平台做成统一能力。但这类平台只有在项目量够多、治理规则较稳定时才真正划算，否则容易平台很重、业务接不动。

常见错误

• 认为接入了某个安全产品就等于完成安全建设
• 只做外挂检测，不做资产、交易和活动规则保护
• 关键状态仍让客户端主导，服务端只做表面校验
• 命中异常后没有处罚、申诉和回滚方案

游戏安全真正成熟的标志，不是“有没有外挂 SDK”，而是当攻击和作弊出现时，系统能否把最贵、最关键、最影响公平和资产的那条链路稳住。

实战案例：一次「单局代币客户端说了算，4 天刷出 7680 万」的结算权威排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「为什么游戏安全离不开反作弊」「客户端永远不可信，但也不能完全放弃客户端」「更重要的是把权威判断放对位置」「反作弊不是只有外挂检测」「常见建设方式与代价」「常见错误」用到深水区：一次春季冲榜活动的代币刷取事故，把安全与反作弊的分家代价、权威位置错配、处置层缺位同时照了出来。

背景与现象：某长线项目春季冲榜活动开跑 7 天，活动代币可兑抽奖券（240 代币兑 1 张），榜前 100 名另发赛季限定称号。配置里单局代币上限 120，但这个上限只在客户端生效，服务端对上报成绩只校验「整数、非负、类型合法」的格式。活动第 2 天起，80 个同源号进场（排行前 100 里占了 80 席，同时段上线、同机型簇、走位轨迹雷同），脚本把单局成绩报成 1200（上限的 10 倍）、日均 200 局，单号日产 24 万，是真人头部玩家约 1 万日产的 24 倍；跑到第 5 天，运营才靠人工比对把 80 个号圈出来。80 个号 × 24 万 × 4 天，累计刷出 7680 万代币，兑成 32 万张抽奖券、已开 29 万张，开出的限定外观 1200 个部分已挂上交易行。团队此前为满足渠道合规接入了反外挂 SDK，上线验收里安全项打勾 1 项；事发后处置只有封号 1 种手段，申诉通道 0 条，回滚方案 0 份。

第一步：现象与口径——先分清「产出有多假」和「存量有多难收」

口径统一：以服务端可复算的「单局产出 × 局数 × 在跑账号」为产出账基准，先记两笔：

• 产出：单号日产 24 万 = 200 局 × 1200/局——上报值是上限 120 的 10 倍、真人头部 1 万的 24 倍
• 存量：80 个号 × 24 万 × 4 天 = 7680 万代币 = 32 万张券，已开 29 万张、待冻结 3 万张

产出账能算平，靠的是上报值没经过任何合理性校验；存量账难收，是因为从产出那一刻起就没有一份可回滚的记录。

第二步：分层归因——从刷量事故到反作弊五层账本

壳账     渠道合规的反外挂 SDK 已接入、验收打勾 1 项——它不懂玩法规则，只挡得住表层攻击
权威账   单局代币客户端上报 1200（上限 120），服务端只校验格式——关键状态客户端主导
识别账   前 100 名里 80 个号行为同源，靠人工比对才圈出——经济异常与关联识别缺位
处置账   处罚只有封号 1 种、申诉通道 0 条、回滚方案 0 份——32 万张券只冻住 3 万张

账本收束：7680 万的存量是权威账欠下的，29 万张已开的券是处置账欠下的——两层账指向同一件事：反作弊五层体系只建到第 1 层半，而「只有做到最后一层，反作弊才真正形成治理能力」。

第三步：根因——壳打了勾，权威放错了位置，处置没有下文

对照本页「更重要的是把权威判断放对位置」：四类关键状态里，结算结果、货币与道具、排行榜与赛季奖励三类全部由客户端主导；服务端该做的三件事——「由服务端掌握最终结算和关键状态变化权」「对来自客户端的输入只接受“意图”或“候选动作”，而不是直接接受结果」「对高价值操作建立幂等、频率限制和异常行为校验」——一件都没做。对照「客户端永远不可信，但也不能完全放弃客户端」：本页前提「客户端可以被篡改、调试、注入、抓包、回放、加速、模拟和批量控制」逐字发生，而客户端防护的两个作用——「提高攻击门槛，让低成本脚本和批量工作室难以规模化」「为服务端风控提供更多环境信号」——壳都在场却没派上用场，脚本连壳都没碰、直接在协议层改了上报值，「只依赖壳、加密和反调试，通常只能挡住最表层的攻击」原样应验。对照「反作弊不是只有外挂检测」：滥用形态里「利用配置漏洞、补偿漏洞和活动规则漏洞刷资源」「群控设备刷活跃、刷邀请、刷广告收益」两条命中；五层体系里客户端完整性与环境对抗有壳、服务端规则校验只做了格式，经济与交易异常识别、社交传播链和账号关联识别、处罚申诉回滚处置三层全空。对照「常见建设方式与代价」：正中「依赖第三方安全壳」的定位——「它不可能理解你的玩法规则、经济逻辑和资产风险」「只能作为基础门槛，不能替代核心校验」；贴业务的规则检测一条没写，独立风控平台的高频信号、处罚策略、审计链路也都没影。「常见错误」四条全部命中：接了安全产品当建成、只做外挂检测不管资产与活动规则、关键状态客户端主导服务端表面校验、命中异常后没有处罚申诉回滚方案。

第四步：处置与回填——先把权威收回来，再把五层补齐

修法分两段。应急：T+0 结算收权——单局代币改由服务端按局时与行为序列重算，上报 1200 的单一律按上限 120 结（缩 10 倍），脚本号收益当场断流；T+1 存量处置——待开 3 万张券冻结，已开 29 万张里回收未消耗 11 万张、已消耗 18 万张记活动损耗，限定外观 1200 个回收未绑定 950 个、深度绑定 250 个公告豁免；80 个同源号全封，同簇疑似 600 个号转标记观察（其中 37 个后续坐实转封），不再一刀切。制度三步：第一步权威收权——结算、代币、榜单三类关键状态全部收服务端，客户端只报「意图」；单号日产设 2 万频控上限（真人头部 1 万的 2 倍），超出进队列人工复核。第二步识别层——关键产出接异常检测，单号日产超真人均值 10 倍自动标记；设备指纹加社交传播链聚类，同类同源号从人工圈 80 个变成自动圈 74 个（剩 6 个复核补齐）。第三步处置层——处罚分限流、禁赛、封禁、回收 4 级，申诉通道 1 条（72 小时响应），代币、券、外观三类资产按快照可回滚，对齐「把高频信号、处罚策略、审计链路和人工复核平台做成统一能力」的方向。复核：次月活动压测演练 20 个模拟号全部上报 1200，频控与异常校验当日拦下 20/20、无一进入结算，全流程演练 40 分钟、处置留痕 20/20，演练申诉 5 件 72 小时内答复 5/5。

回填清单：

落点	动作	回填处
权威收权	结算、代币、榜单三类关键状态收服务端，客户端只报意图	更重要的是把权威判断放对位置
安全壳重定位	壳只留提门槛与环境信号两个作用，不再当验收完成项	客户端永远不可信，但也不能完全放弃客户端
识别层补位	产出异常检测与设备、社交链聚类自动圈号	反作弊不是只有外挂检测
处置闭环	处罚四级、申诉 72 小时响应、三类资产快照回滚	常见建设方式与代价

案例的三个教训

1. 验收打勾不等于安全建成——反外挂 SDK 打勾 1 项之后，1200 的单照单全收：安全产品是门槛，不是方案。
2. 关键状态离客户端越近，账单越大——服务端只校验格式的每一天，都是 80 个号 24 倍产出的提款窗口，4 天刷出 7680 万。
3. 没有处置层的反作弊只是报警器——32 万张券只冻住 3 万张；游戏安全成熟的标志，是「系统能否把最贵、最关键、最影响公平和资产的那条链路稳住」。

Used By

反作弊体系建设；结算权威设计评审；外挂对抗的分层策略。

• KBEngine（commit 0bc93d5）：校验点放在服务端、错误码刻意不细分——客户端只上报 loginName/accountName/password/needCheckPassword（kbe/src/server/baseapp/baseapp.cpp:3699），比对在 baseapp 的登录流程完成，「用户不存在」与「密码错误」返回同一个 SERVER_ERR_NAME_PASSWORD（同文件 :3744、:3751），客户端拿不到做账号枚举所需的区分度

Related

关系链：对抗面 → 客户端两难 → 权威位置 → 不止检测 → 建设方式与代价。上游：无（security 入口）。下游：security/03（行为风控）、system 树结算（凭证与幂等）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。