为什么需要

开发时使用的调试开关、测试账号入口或日志，可能随构建进入正式包，暴露内部信息或额外操作能力。

检查要点

• 核对发布配置。

• 移除测试入口和内部地址。

• 日志不输出密码、完整令牌等敏感内容。

为什么需要

游戏经过修改、重签名或二次分发后，可能仍能使用正常账号和接口。单纯确认能够安装，无法判断是否为预期版本。

检查要点

• 维护合法签名与版本范围。

• 检查关键文件完整性。

• 异常有上报、限制或复核策略。

为什么需要

奖励、属性和校验等逻辑如果容易被定位，就可能成为分析和篡改的目标。勾选过保护配置，不代表最终模块已被覆盖。

检查要点

• 列出核心模块。

• 核对保护后的发布产物。

• 验证关键功能、启动和运行开销。

为什么需要

函数名、错误提示及业务字符串可能帮助分析者快速定位奖励、计费和安全检测逻辑，明文凭据还会带来额外风险。

检查要点

• 清理非必要调试符号。

• 处理高敏感业务线索。

• 排查密钥、令牌和内部接口信息。

为什么需要

IL2CPP 改变了代码形态，类型和方法信息仍可能提供分析线索。仅改名或隐藏 metadata 文件位置不足以说明保护有效。

检查要点

• 原生模块与 metadata 均纳入评估。

• 抽查关键逻辑可恢复的信息。

• 验证相关功能兼容性。

为什么需要

渠道重签名、SDK 替换或独立构建，可能改变原有保护配置。一个母包检查通过，不能替代对最终分发版本的核对。

检查要点

• 记录渠道与构建版本。

• 核对保护步骤和合法签名。

• 回归登录、支付及更新流程。

为什么需要

资源暴露除了影响美术资产，还可能泄露活动配置、关卡规则或尚未公开的内容。不同资源的保护优先级应结合业务确定。

检查要点

• 列出核心资源。

• 核对保护范围。

• 确认依赖、第三方加载和性能满足项目要求。

为什么需要

更新资源可能走独立构建流程，遗漏保护步骤；加载时也可能留下未预期的明文缓存。

检查要点

• 更新构建包含保护步骤。

• 缓存复用、重启加载后保护仍有效。

• 没有长期保留未预期的明文副本。

为什么需要

资源即使加密，也需要确认来源和版本。错误配置、文件替换或旧资源重用，可能改变玩法、奖励或加载行为。

检查要点

• 更新清单与内容有可信校验依据。

• 拒绝非预期版本组合。

• 正常回退经过授权和验证。

为什么需要

敏感值即使没有写入文件，也可能在运行中被观察或改写。只保护显示值，而业务计算使用另一份数据，仍可能留下缺口。

检查要点

• 识别真正参与计算的数据。

• 安排必要的内存保护与校验。

• 联网项目结合服务端业务依据复核。

为什么需要

注入模块或替换函数返回值，可能改变原本正常的业务流程。启动时检查一次，也可能遗漏运行后才出现的变化。

检查要点

• 覆盖调试与注入风险。

• 关注异常进程、模块及运行中变化。

• 验证关键业务阶段的检测与处置。

为什么需要

代码在包体中受到保护，运行时仍可能被修改。若全部判断依赖一个可被替换的结果，后续检查也可能一起失效。

检查要点

• 明确关键代码范围。

• 按风险安排多个检查路径。

• 异常有可追踪的处理策略。

为什么需要

Root 或越狱可能扩大对应用和系统的控制能力，但检测到此类环境并不能直接证明玩家作弊。

检查要点

• 明确检测覆盖及平台限制。

• 结合其他风险信号判断。

• 保留复核、白名单或策略回退方式。

为什么需要

这些环境可能用于正常游玩，也可能被用于批量账号或刷取资源。风险取决于玩法、运营规则及具体行为。

检查要点

• 明确允许范围。

• 区分环境信号与作弊证据。

• 记录运行中变化及策略命中原因。

为什么需要

存档或配置即使不易阅读，也不代表修改能够被识别。游戏若直接认可本地数值，仍可能形成进度和收益篡改。

检查要点

• 区分普通设置与关键业务数据。

• 按需保护保密性和完整性。

• 明确异常恢复方式。

为什么需要

旧存档本身可能完整且合法，但重复恢复某个状态，仍可能重复领取奖励。加密不能单独解决历史状态复用。

检查要点

• 有账号或云同步时核对身份关联。

• 校验关键收益记录。

• 纯离线项目重点检查回滚及本地恢复。

为什么需要

写入客户端的秘密可能被提取；日志、缓存或备份中的令牌也可能被再次使用。更换名称或编码不能代替权限控制。

检查要点

• 服务端秘密不随包分发。

• 客户端凭据按权限和有效期管理。

• 核对系统安全存储、备份及退出清理。

为什么需要

HTTPS 保护的是传输过程，不能证明客户端没有被修改。业务请求即使经加密传输，内容仍需要独立校验。

检查要点

• 敏感通信使用适当加密。

• 正确验证证书与服务端身份。

• 第三方请求也纳入检查。

为什么需要

合法请求可能被复制到不合适的时间再次提交。客户端持有的签名材料也可能暴露，签名无法替代权限及业务校验。

检查要点

• 按需绑定会话、内容与唯一标识。

• 检查时效及协议重放。

• 业务重复发放另按收益控制项目检查。

为什么需要

客户端显示退出，不等于服务端会话已经失效。旧凭据继续可用，可能导致账号切换串用或异常访问。

检查要点

• 明确会话期限及刷新方式。

• 退出和高风险变更后按策略失效。

• 账号切换不复用旧身份。

为什么需要

知道一个角色或订单编号，不代表有权查看和操作它。只验证是否登录，可能放过跨账号的数据访问。

检查要点

• 每次请求核对身份与对象归属。

• 区分玩家及管理权限。

• 不信任客户端传入的账号或角色标识。

为什么需要

请求格式正确、数值处于允许范围，不代表玩家已经满足领取条件。客户端上报结果仍需核对业务依据。

检查要点

• 收益关联具体业务记录。

• 核对前置条件和领取状态。

• 无法实时完整复算时有补充校验或复核方式。

为什么需要

同一业务可能因超时重试或并发请求被执行多次。只检查单次请求是否合法，无法防止重复发奖或扣款不一致。

检查要点

• 以具体业务流水去重。

• 状态变更与资产操作可靠执行。

• 核对重试、并发及失败恢复后的资产一致性。

为什么需要

作弊不一定产生越界数值。变速、无敌或自动化行为，也可能表现为耗时、动作顺序和多项结果组合异常。

检查要点

• 检查业务状态与动作顺序。

• 结合多项行为及历史判断。

• 异常记录可复核，处置不只依赖单一阈值。

为什么需要

客户端的支付成功提示不能单独作为发货依据。重复通知或订单状态不同步，还可能导致重复发货和资产不一致。

检查要点

• 服务端核验支付依据。

• 订单与商品、账号绑定。

• 按规则处理重复通知、退款和状态修复。

为什么需要

组件更新、渠道替换或配置变化，可能改变权限和数据处理行为。只保留早期接入清单，无法反映最终包。

检查要点

• 清单与正式产物匹配。

• 确认版本及相关风险修复。

• 移除非必要权限、测试地址和默认凭据。

为什么需要

SDK 可能在启动或后台自动初始化，实际采集时机、范围与原有说明存在差异。只确认弹窗出现，不能说明处理流程正确。

检查要点

• 明确实际采集项和使用场景。

• 核对授权及拒绝后的行为。

• 更新组件后同步检查对外说明。

为什么需要

只有异常次数而缺少发生场景，往往难以判断影响范围。环境信号或一次校验失败，也不应直接等同作弊结论。

检查要点

• 记录必要的版本、渠道与业务上下文。

• 关联多种风险信号。

• 控制日志访问与留存。

为什么需要

发现问题后，仍需要确定谁处理、如何止损以及怎样避免复发。过于激进的处置也可能影响正常玩家。

检查要点

• 明确责任人与处置策略。

• 支持复核和必要回退。

• 修复后覆盖原问题及相关渠道版本。