现象放置类项目后台监控到离线收益结算异常一批账号到手的产出明显高于服务端按规则应发的量且集中在几个高价值道具上。先看协议层排除最常见的两种情况。抓包比对上报请求包签名正确、ts在窗口内、nonce无重复说明既不是链路篡改也不是请求重放签名保证包没被中间改过nonce保证同一个包没被重复提交但这两样都不涉及包体内容本身的真伪。问题出在上报的数据是假的而校验一路放行。排查过程第一层值域校验服务端已有值域校验拿玩家面板快照算理论上限超限丢弃maxDamage atk × critMulCap × hitCap但日志显示异常账号的上报值普遍卡在上限的 90%~95%没有触发任何丢弃。定位到两个问题一是校验用的阈值来源。伤害系数、暴击上限等参数写在随包下发的数值表里客户端可解包获取作弊者据此把上报值压在阈值之下。二是校验失败的返回行为值域不通过时接口返回明确的错误码等价于向客户端暴露了一个判定 oracle通过二分探测即可逼近阈值边界。第二层自洽校验补充字段间的物理约束校验检查单个请求内部是否自相矛盾。例如同一技能的释放次数与其冷却时间、战斗总时长之间存在硬约束// 同一技能释放 n 次至少要跨 (n-1) 个 CDforeach(varginreq.SkillCasts.GroupBy(cc.Id)){longneed(g.Count()-1)*SkillTable[g.Key].CooldownMs;if(needreq.DurationMs){Flag(uid,cd_overflow);// 打标返回照常成功}}上线后拦截到一批伪造请求但仍有一部分账号的上报数据完全自洽产出却对不上。复现分析后确认这部分作弊不修改协议包而是修改客户端运行时——内存改写攻击力、变速工具放大帧率正常完成整局战斗后如实上报。战斗过程在客户端真实发生因此数据在值域和自洽两个维度都无懈可击。值域与自洽校验到此失效。第三层服务端重演对上述情况唯一可验证的方式是服务端重算即上报输入而非结果客户端提交随机种子与操作序列服务端用同一套战斗逻辑重跑一遍比对结果 hash 是否一致。varsimnewBattleSim(snapshot,req.Seed);// 与客户端同一份战斗核foreach(varactinreq.Actions)sim.Step(act);if(sim.ResultHash!req.ResultHash)Flag(uid,replay_mismatch);Settle(sim.Result);// 一律以服务端重演结果结算落地前提是双端计算结果逐位一致否则无法比对。主要有两点浮点运算跨端不一致战斗核需改为定点数实现随机数不能使用引擎自带的UnityEngine.Random改用自带种子的确定性实现且双端每一步的调用次数严格对齐。该改动在项目早期成本可控系统成型后再改动代价很高。一个容易误判的坑重演上线初期replay_mismatch打标量会异常偏高容易被误判为大规模作弊。实际排查后发现绝大多数是客户端与服务端逻辑未对齐导致例如技能结算顺序相差一帧、某处随机调用次数不一致真实作弊占比很低。因此重演上线阶段应仅打标观察不接入封号或拦截结算待双端对齐、mismatch 率降至个位数后再启用处置逻辑否则首轮误伤的多为正常玩家。部署与成本全量重演还是抽样取决于品类的单局输入规模回合制、卡牌、放置单局输入仅几十字节重跑是纯逻辑运算可每局全量重演实时动作、MOBA、射击每帧都是输入单局数据量与重跑开销高出两个数量级只能抽样另对榜单 Top、高价值掉落、已打标账号做触发式全量。处置策略数据判定为异常不等于直接封号。弱网重传、断线补包、低端机 RTC 跳变等正常情况都会产生不合理的数据单条信号误伤率高。采用分级处置先打标再限制变现路径交易、提现、榜单结算多维信号累积到阈值后再人工介入。检查项小结检查项常见疏漏排查要点值域校验阈值随数值表下发客户端校验用阈值服务端单独存不随包下发失败返回校验不过返回明确错误码照常返回成功异步打标不暴露判定自洽校验只查单字段不查字段间约束校验技能次数×CD、消耗与命中等硬约束上报粒度上报客户端聚合后的均值上报原始采样序列判定放服务端服务端重演直接采信客户端结果上报种子操作序列双端一致后重跑重演上线一上线即接封号先打标观察mismatch 降下来再处置处置策略单条信号即封号分级打标→限制变现→人工排查到最后校验该做到哪一层本质是成本问题投入与这份数据的变现价值匹配即可。纯本地、数据只影响自身显示的值域足够涉及交易与提现的服务端重演的工程成本再高也需要覆盖。完整的分层判断逻辑另有整理可搜索「字节暗面 服务端校验」。
