为什么需要 MOSS 反作弊
电竞赛事中可能出现的舞弊行为，归纳起来无非三类。理解这三类，才能理解 MOSS 到底在防什么。
身份舞弊
代打、冒名顶替——用他人账号或请人替赛。
设备舞弊
各类注入 / 文件修改型外挂、宏按键等。
场外支援
裁判不公、场外报点、外部协助等。
厂商反作弊的盲区
各大厂商在反作弊上煞费苦心（VAC、Easy Anti-Cheat、BattlEye、FairFight 等），但普遍存在一个共同问题：基本无法应对各类宏输入。而在高水平竞技赛事中，对鼠标宏的检测是非常重要的一环。
MOSS 能完整记录什么
- 选手的随机屏幕状态（不定时截取所有显示器画面）
- 选手所用硬件的唯一设备标识符（含硬盘 / USB 序列号、主板 Sign ID）
- 选手正在使用的外设驱动及其配置文件（罗技 G HUB、iCUE 等）
- 游戏关键文件的 SHA2 校验码
- 当前硬件配置与运行速度（CPU / 显卡 / 内存 / 实时频率）
- 游戏内截图（选手按 PrintScreen 保存的）
- 有无疑似的宏按键节奏——针对哪组按键、用了多少次、偏差多少
- 游戏启动时系统后台运行的所有进程名 / 路径 / SHA2
本页的设计逻辑
公开层让人「看到能力和方法」→ 产生信任 → 需要完整版的人主动联系 → 形成转化。
版本与时效性（务必先读）
MOSS 更新频率较高，Logfile 的字段组成、名称与排版格式都可能随版本变化——某些「异常信号」可能在新版本被修复，也会新增字段。因此：
- 本页（含《技术分析篇》《故障排查》）只保证撰写时的版本，不保证后续版本仍然一致。
- 判读任何一份 Logfile 前，先确认 MOSS 版本号；本页描述的字段若找不到，第一反应应是「版本差异」，而不是「文件被改」。
- 本页的「故障 / BUG」均与版本强相关，各条目已尽量标注出现版本（如「5.8.0.0 之后」），请以当时版本为准。
- 遇到与本页不符的情况欢迎反馈，作者会随版本更新校订本页。
技术分析篇 · 怎么判断一份 MOSS 有没有问题
这里讲方法，不讲全文手册。学会「怎么看」，比背下每条日志更重要。
一、第一步：校验文件完整性
收到 MOSS 文件后的第一步，是校验其完整性。MOSS 程序 Help 菜单下有两个校验项：
- Check a Moss Log integrity —— 检测一个 MOSS 保存文件是否被修改过
- Check a single file SHA2 —— 检测单个文件的 SHA2 校验码
选择 Check a Moss Log integrity 导入文件后，一般会出现以下几种结果：
二、看懂 Zip 里有什么
以彩六为例，Zip 解压后一般包含：
- 一系列截图，编号从
001开始（多屏会按显示器位置与比例拼成一张大图） - 一个或数个
GameSettings.ini（按.00X顺序编号）——用于检测小号 - 一个或数个设置文件（罗技 G HUB 为
Settings，海盗船 iCUE 为.cueprofile文件） - 一个
Logfile.log—— 最重要的 MOSS 工作记录日志
.0xx 编号代表捕获顺序。MOSS 会在游戏启动前和启动中不定时捕获配置，故编号可能不连续，需以最终扩展名编号判断顺序。网吧因 Steam 目录结构特殊、系统盘不在 C 盘等情况，可能无法正常检索 GameSettings.ini，属已知现象。三、关键日志字段怎么看
Logfile.log，可直接用顶部「Log 解析」标签页里的本地解析工具，一键把这些字段提取成清单（文件不会上传，编码自动识别）。Net: <内网> Public: <公网>（本样本公网段可见、后段被遮蔽）。可一定程度检测网吧五排——网吧机器公网 IP 相同、内网 IP 连号；公网 IP 可识别实际区域。Dxgi / DX11）、API 耗时、(Mon n) 显示器编号、截图精确时间、文件名与截图的 Zip CRC（不是 SHA2）。.0xx 与 Zip CRC）。696 keystroke, 1 Patterns found）。命中不等于判罚，须结合手速、热身等合理成因（见下方异常信号）。CPU Load 为运行期不定时抽样（如 34 / 95 / 100），可反映录制期间的机器负载。at tml xml:lang="en-EN），属显示问题，不影响判读。四、一份真实 Logfile 长什么样（脱敏示例）
下面是作者实测样本（MOSS 7.2.2.0，Rainbow Six）的脱敏结构，<…> 内为已隐去的真实内容。不同版本字段必有出入，以实际 Logfile 为准。
SHAS2 mode started at … for Rainbow Six on x64 ping:646ms update 6 DirectX version is 12.0( ) OS is 11.0 64 bit build <build> Real OS Windows 10 or 11 PCI: 10DE-22E9 ← 每块 PCI 设备一行，共 7 块 memory: 65457 MB version: MOSS 7,2,2,0 Physical: <主板厂商><主板型号> Sign ID1: <SIGN-ID> User: <用户名>@<主机名> Drive: <硬盘型号> serial: <序列号> ← 每块硬盘一行 Net: <内网IP> Public: <公网IP> Video: <显卡名> driver : <驱动版本> ← 含虚拟显示器（如有） Monitor: <显示器名> serial: <序列号> Usb: <设备名> (<序列号>) (0x<VID>-0x<PID>) processor BIOS details <基频> MHz by <倍频> <CPU 型号> Monitor Started at <时间> Windows Defender: enabled SteamId: <Steam数字ID> SecureBoot ? YES Virtualization ? YES Hypervisor ? YES IOMMU/VT ? YES ping:238ms SHAS2: <SHA2> Author: <签名作者> process: <程序路径> ← 启动时后台进程，逐条列出 captured: <路径>\<GUID>\GameSettings.ini file: GameSettings.ini.001- Zip CRC: <CRC> FileCheck start for <游戏目录> at <时间>: in GAME SHAS2: <SHA2> process: <游戏内模块路径> ← 游戏运行时加载的 DLL Dxgi …(301)(Mon 1) DX11(780) : Each 60 at <时间> file: 011.JPG- Zip CRC: <CRC> CPU Load 95 <N> keystroke, <M> Patterns found ← 宏节奏命中数量 Mouse down moves ( no recoil search ) ← 压枪检测直方图 PID Running Time Kernel Time User Time Name ← 进程统计表 <PID> <运行时长> <内核态> <用户态> <进程名> Monitor stopped at <时间> Global log CRC: <CRC>
五、常见异常信号（判断思路）
- LOG Corrupted / Invalid File —— 选手修改了 MOSS 文件内容，可依规则判负
- Zip 内无截图文件，仅有 Logfile / 配置 —— 采集方式副作用导致的捕获失败，需按黑屏故障处理，不代表选手作弊
- 外网 IP 相同、内网 IP 连号 + 硬件序列号相近 —— 网吧五排 / 同机多开的排查方向
- 硬件 Sign ID 与往届封禁记录重复 —— 小号 / 规避禁赛的排查方向
- Author 签名指向可疑封包方 / 异常 DLL 注入游戏进程 —— 注入挂的排查方向
- Video 行出现虚拟显示器 —— 形如
… Virtual Display Adapter（模拟器、远程控制、投屏软件常见）。属排查方向，须先确认用途，不可直接判罚 - CPU / 芯片组 / 板载设备「对不上」 —— 如 CPU 与主板平台物理上不可能共存，或板载网卡型号年代与平台严重脱节，指向硬件信息被伪造 / 篡改。⚠️ 但一台机器出现多个南桥、甚至 AMD 南桥 + Intel 平台可能是合法的「南桥卡」，不可单独判罚（详见「判例篇」反例说明）
- 宏按键节奏提示 —— 注意：判定「宏」的依据是是否以接近的操作模式连续完成两个或更多操作；但手速快不一定是宏（如打音游），鼠标宏提示也不一定是真宏（典型案例：赛前打了一把音游热身）。相关 Mouse Event 数据在本版本仍处于数据收集阶段，不可单独作为直接或间接判罚依据。
Log 配置清单 · 本地解析
拖入 MOSS 产出的 Logfile.log（或整个 .zip），自动把其中的机器配置部分提取出来、整理成清单，便于核对硬件自洽性、比对两台机器的差异。
Logfile.log / .txt，以及 MOSS 产出的 .zip（会自动解出里面的 Logfile.log）
本工具的 4 个已知限制（核对前请先读）
- PCI 清单是「部分设备」，不完整。MOSS 只列出它认为需要记录的若干条 PCI 设备，筛选规则从未公开（作者也未搞清）。实测：7.2.2.0 仅列出 7 条、且只有 VID-DID 没有设备名；6.7.1.0 曾列出 21 条并带设备名。因此不能据「列表里没有某设备」就断定它不存在，也不能用条数推断机器规模。
- 「未命名」的硬盘是 MOSS 老 BUG。个别控制器 / 虚拟盘不返回设备名，日志里会留成空名（形如
Drive: serial:）。这不代表设备异常，核对时忽略该条即可——作者已确认，是遗留很久的老问题。 - 显示器「物理 / 疑似虚拟」是按名称关键词推测。远程控制、模拟器、投屏软件会安装虚拟显示器（ToDesk、向日葵、MuMu、GameViewer、DisplayLink 等）。标为「物理」只表示未命中虚拟关键词，不等于 100% 确认为真机；虚拟显示器本身也不构成违规，属排查方向。
- USB 类型标签为推测。Logfile 里不含 USB 类别字段，标签由「设备名 + 厂商 ID」推断，仅供快速辨认，不能作为判罚依据；有疑问时以设备实际用途为准。
选手指南 · 各游戏极简流程
每个游戏一页：启动顺序 → 录制 → 保存 → 提交 → 常见错误。流程大同小异，差异在于勾选项目、游戏进程名与提交 ID 类型。
本赛事对 MOSS 的提交要求（请务必看清）：
- 报名阶段：随报名一并提交每位选手的 MOSS 归档 —— 即 MOSS 是报名材料的一部分。
- 每场比赛结束后：同样需要提交本场的 MOSS 记录。
- 若出现硬件变化或 IP 变化：须一并提交行程或对应购买记录作为佐证（正常变化本身不违规，但需能解释清楚）。
因此录制前若环境不对（例如下面「通用赛前检查」里的 UTF-8 设置未关闭），交上去的这份就会作废，需要在截止前重录重交。所以「通用赛前检查」请务必先做。
我们的推荐做法是：始终保持该设置为「关闭」（从一开始就不要开启）。⚠️ 如果你的系统原本是「开启」状态、现在才关闭，请留意：部分软件可能因安装目录编码不一致而无法正确启动；万一出现这种情况，反复开关通常无法修复，建议重装系统。机制、实测对照与正确处理见「故障排查 4.8」。
RainbowSix.exe / RainbowSix_Vulkan.exe- 启动 MOSS运行
MossX64.exe，授权 UAC。若提示版本过低则先更新（更新后目录会多出OldExecutable.bak，可删）。更新后文件名保持不变。 - 初次配置点击左上角
File → Parameters，勾选 Rainbow Six 后确定退出。 - 打开录制点击
Capture → Start，MOSS 短暂卡死后开始等待游戏进程。请确保此时任务管理器内没有RainbowSix.exe在运行（退出不干净、后台假死也不行）。 - 正常比赛MOSS 开始采集后即可正常比赛。启动游戏后如未自动最小化，可手动最小化 MOSS 窗口（常见于无边框游戏）。
- 结束后保存比赛结束后不要急着 Alt+F4。回到主菜单，调出 MOSS，点击
Capture → Stop保存（此阶段 MOSS 可能假死无响应，属正常现象），保存完成后才退出游戏与 MOSS。 - 改名提交在桌面（或指定位置）的 MOSS 文件夹找到最新压缩包，把文件名改成自己的 Uplay ID，发送给当值 OB / 工作人员确认。
提交要求（缺一不可）
- 未人为修改 Zip 内文件——任何文件、哪怕文件内一个字符都不行
- 至少包含比赛全程不定时截图（一长串
XXX.JPG，且非全黑屏）与Logfile.log - 不可自行重新封装 Zip——哪怕只是「解压后重新打个包」也视为无效，并可能按人为修改判罚
常见错误速查
RainbowSix.exe 或重启电脑，改为先录制、后开游戏。Discovery.exe- 启动 MOSS运行
MossX64.exe，授权 UAC，必要时先完成版本更新。 - 初次配置
File → Parameters，勾选 THE FINALS（最后一列从下往上第三个），确定退出。 - 打开录制
Capture → Start，确保任务管理器内没有Discovery.exe在运行。 - 正常比赛开始采集后正常比赛；必要时最小化 MOSS 窗口。
- 结束后保存不要急着关闭游戏；回主菜单点击
Capture → Stop保存，保存完成后退出。 - 改名提交把压缩包文件名改为自己的 Embark ID，发送给当值 OB / 工作人员确认。
提交要求
- 未人为修改 Zip 内文件
- 至少包含比赛全程不定时截图（
XXX.JPG，非全黑屏）与Logfile.log - 不可自行重新封装——否则可能视为人为修改 MOSS 而导致判罚
常见错误速查
Discovery.exe 进程，先录制后开游戏。r5apex.exe- 启动 MOSS运行
MossX64.exe，授权 UAC，必要时先完成版本更新。 - 初次配置
File → Parameters，勾选 APEX Legends，确定退出。 - 打开录制
Capture → Start（可能短暂无响应属正常），确保任务管理器内没有r5apex.exe在运行。 - 正常比赛开始采集后正常比赛；必要时最小化 MOSS 窗口。
- 结束后保存不要急着 Alt+F4；回主菜单点击
Capture → Stop保存，保存完成后退出。 - 改名提交把压缩包文件名改为 选手 ID + 场次信息，发送给当值 OB / 工作人员确认。
提交要求
- 未人为修改 Zip 内文件
- 至少包含比赛全程不定时截图（
XXX.JPG，非全黑屏）与Logfile.log - 不可自行重新封装
常见错误速查
r5apex.exe 进程，先录制后开游戏。- 启动 MOSS运行
MossX64.exe，授权 UAC，必要时先完成版本更新。 - 初次配置
File → Parameters，勾选 COD MWII，确定退出。 - 打开录制
Capture → Start，确保任务管理器内没有 COD 游戏进程在运行（退出不干净、Steam 仍显示运行也不行）。 - 正常比赛开始采集后正常比赛；必要时最小化 MOSS 窗口。
- 结束后保存不要急着 Alt+F4；回主菜单点击
Capture → Stop保存，保存完成后退出。 - 改名提交把压缩包文件名改为 选手动视 ID，发送给当值 OB / 工作人员确认。
提交要求
- 未人为修改 Zip 内文件
- 至少包含比赛全程不定时截图（
XXX.JPG，非全黑屏）与Logfile.log - 不可自行重新封装
常见错误速查
故障排查 · Q&A
MOSS 稳定性有目共睹地「是个谜」。以下为历史上出现过的典型故障与处理方式，供赛前自检与赛后取证参考。
启动 MOSS 后点击窗口，突然发现 MOSS 崩溃（突发消失、不提示）。官方无完整触发原理，极少数确认与反病毒软件掐进程有关，可尝试禁用杀软规避。
- 只要触发此 BUG，除非 MOSS 更新或系统重装，否则会持续存在。
- 处理：向赛事组提交「从启动到崩溃的全程视频」作为证据，赛事组以此参考。
与 4.0.1 不同：不是直接闪退，而是提示「程序没有响应」后报错等待退出。触发时会在 MOSS 根目录生成 MOSS.dmp 以及 crashdmp.log。
- 进行文件完整性校验时也会触发此 BUG，机制不明。
- 处理：立刻上报 OB / 赛事组，将
MOSS.dmp、Crashdmp.log等打包提交，作为 MOSS 文件的临时代替。
仅出现在极少数使用软件 G-SYNC 的选手上：游戏中每隔约 30–120 秒黑屏一次，可能与 NVIDIA 底层驱动及 MOSS 捕获方式有关。
- 关闭显示器的 G-SYNC 模式
- 关闭显示器的硬件超频模式
- 关闭显示器设置中的 ULMB（Ultra Low Motion Blur）
集中爆发于 5.8.0.0 之后版本。开始录制时报错，保存目录虽生成了一个 .zip，但不含 Logfile，仅含当前配置与一张截图。
成因是没有遵循标准启动流程。解决：确保游戏未启动时先打开 MOSS 录制，再启动游戏——「未启动」定义为当前进程中没有游戏进程；后台假死的游戏进程也要强制结束或重启电脑。
此情况下导致无法正常提交 / 保存 MOSS，按无法提交 MOSS 判罚。
先解压确认是「仅游戏内界面黑屏」，还是「录制全程黑屏」。
仅游戏内黑（Win7）：一旦切入游戏即黑屏，系统录屏不受影响。成因是 MOSS 在 Win7 下对 DirectX 11 特性的支持问题。临时方案：游戏内「显示设置」改为无边框（可能带来性能下降）；网吧选手建议从 Windows 10 启动。
全程黑屏（多显卡 / 核显+独显笔记本）：核心原因是 MOSS 运行的显卡与游戏不在同一块显卡上。
- 老版本 Win10（1809 之前）：在 NVIDIA 控制面板中，把 MOSS 设为与游戏相同的显卡。
- Win10 1809 或之后：从「Windows 设置 → 搜索『图形设置』」，添加 MOSS 程序并设图形首选项为高性能（不要只迷信 NVIDIA 控制面板）。
自 2020.12 起有汇报，多见于部分笔记本选手。表现为压缩包正常，但里面只有配置文件与 Logfile.log，无任何截图，MOSS 检查却显示文件完整。
实为 4.2 黑屏症状的升级版。另一判断方式：其 Logfile.log 中会出现复数条 DX9/11 VIDEO Locked…… 报错，且没有截图相关 log。
解决：与 4.2.2 相同路径，但这次不是设「高性能」，而是把 MOSS 设为在节能（集成）显卡运行。注意 Windows 设置有强针对性——应用的文件名或目录一旦改变，设置即失效，因此请固定 MOSS 所在目录与文件名，避免紧急更新导致录制失效。
机制不明，任何电脑都可能触发，可能与某些国产「安全管家」或杀毒软件有关，强烈建议赛前测试。
可能原因：某软件限制了 MOSS 写注册表 / 往桌面写文件（Defender 背锅），或系统安装目录错误导致 MOSS 无法定位桌面。
方案一（Defender 误杀）：「病毒和威胁防护 → 病毒和威胁防护设置 → 管理设置 → 文件夹限制访问」，可选择关闭该功能，或「通过文件夹限制访问允许某个应用」放行 MOSS，并把 Desktop 从受保护文件夹中移除。
方案二（改保存目录）：打开 regedit，定位到 HKEY_CURRENT_USER\SOFTWARE\Nohope92\Moss，新建字符串值（REG_SZ）命名为 PATH，数据填目标目录。注意：该文件夹必须已存在（MOSS 不会创建文件夹）；且若想让文件落在 C:/MOSS，变量应填 C:/（实际会生成 C:/MOSS/MOSS）。
准确地说，这不是「无法保存」，而是「无法启动」。现版本 MOSS 必须一次保存后退出才能启动第二次保存。
典型场景：赛前测试了一下 MOSS 忘了重启；或保存时手快点完 Stop 又点了一次 Start。前者没救、下次注意；后者可检查当前 MOSS 文件是否只是手快造成的误判。
AMD 显卡用户可能因驱动原因在运行 MOSS 时严重掉帧。解决方法：不使用物理第二显示器（系统启动即断开 / 拔掉外接副屏）；更新显卡驱动。
启动 MOSS 时弹出标题为「MOSS」的对话框，内容是一整段未渲染的网页源码（<html>…</html>），其中标题为 Your request has been blocked - OVHcloud，提示 Request blocked due to suspicious activity，并附带规则号（如 74035 Site access）、IP 与 Request ID。
- 原因：MOSS 启动时会发起联网请求，其站点托管在 OVHcloud；该请求被 OVHcloud 的 WAF 判为可疑而主动返回拦截页。MOSS 未对 HTTP 错误做处理，把响应体原文直接弹窗——所以看着像「乱码报错」，其实是一张别人的网页。
- 与文件无关：本质是「服务端临时拦截 + 客户端容错不足」，不代表 MOSS 文件被修改，也不代表选手有违规行为。
- 处理：关闭 MOSS 重新启动（实测有效）；仍不行则稍等再试，或更换网络出口（手机热点 / 换线路）。不建议用 hosts 屏蔽该域名——可能连带影响 MOSS 的在线校验。
现象：用记事本或另一台电脑打开 Logfile.log 时出现乱码；也可能表现为 MOSS 提示「文件无法校验完整性」。关键：这不是「偶尔出错」，而是必然失败。只要录制端开了该设置，产出的日志编码就固定为 UTF-8，与以 936 / GBK 为基准的校验环境永远对不上——重试多少次、换谁来核对都无法正确校验。
正确 ：哔哩哔哩.exe 按错的编码读 ：鍝斿摡鍝斿摡.exe
- 原因：MOSS 写日志时使用的是系统 ANSI 代码页（中文 Windows 默认
936 / GBK）。一旦勾选「Beta 版：使用 Unicode UTF-8 提供全球语言支持」，系统 ANSI 代码页就变成65001 / UTF-8，日志随之以 UTF-8 写出。 - 日志里为什么会有中文：MOSS 会记录一批系统本地化的字符串——PCI 设备名（由系统接口取回，如「PCI Express 根端口」）、杀毒软件名称、进程文件的公司名 / 文件描述、以及含中文的安装路径。这些才是日志里「非 ASCII 字节」的来源，与选手操作无关。
- 为什么会「必然报错」：写的一方与读的一方代码页不一致时——用 GBK 去读 UTF-8（反之亦然）——轻则满屏乱码，严格解析时直接解码失败。所以这不是日志被篡改，而是两侧环境不同。
实测对照（两份真实样本，同为 R6S + 中文 Windows）：
- 样本 A（开了 UTF-8 支持）：MOSS
6.7.1.0，日志为 UTF-8（无 BOM、CRLF），非 ASCII 字节 860 个；用 GBK 打开直接解码失败，用 UTF-8 打开正常。 - 样本 B（未开）：MOSS
7.2.2.0，日志为 GBK / ANSI，非 ASCII 字节 49 个；用 UTF-8 打开直接解码失败，用 GBK 打开正常。 - → 两份日志互为乱码。可见只要双方该设置不同，就必然对不上——与 MOSS 版本高低无关。
对赛事流程的影响（关键，请务必重视）：本赛事要求报名时提交每位选手的 MOSS 归档、且每场比赛结束后也需提交。因此该设置的影响不只是「核对方看不清」——它让你每一次提交的 MOSS 从源头就无法校验、直接作废，报名材料与赛后提交随之不合格。等录完才发现，就只能关闭该设置、重启、重新录制并重新提交。请在录制前就先确认此项为「关闭」。
- 处理一（选手端，每次录制前必做）：把该设置关闭并重启后再录制。见「选手指南 → 通用赛前检查」。推荐做法是始终关闭（从头不开启）。
- ⚠️ 处理一补充 ——「原本开着、现在才关」有残留风险：该设置会改变系统对非 Unicode 程序的路径 / 文件名解释方式。若某些软件是在「开启」状态下安装 / 配置的，关闭后可能因安装目录编码不一致而无法正确启动。因此关闭后请先逐一验证常用软件（尤其游戏、驱动）能否正常打开；一旦出现这类问题，反复开关通常无法修复，最稳妥的做法是重装系统，再从「关闭」状态重新部署环境后录制。这类情况不算常见，但确实存在——所以更好的做法是一开始就不开启。
- 处理二（核对端 —— 同样是硬性要求）：本赛事要求负责检查 MOSS 的工作人员把该设置也保持为「关闭」（所有比赛都会强调此项）。这样核对端与选手端编码一致，可正常打开校验；若核对端自己开着该设置，即便选手端是规范的，读到的也一样是乱码。临时处理可明确指定编码（UTF-8 / GBK）打开，不要靠编辑器自动猜测。
- 不要转码：不要用记事本「另存为」换编码——那会改写文件字节。日志末尾带有
Global log CRC总校验，字节一变就可能对不上，而且已不是选手的原始产出。转交时请给原始 Zip，不要单独转存Logfile.log。 - 结论：属环境差异导致的伪异常，不代表选手违规、也不代表 MOSS 文件被修改（本身不构成判罚依据）。但它会直接导致 MOSS 记录不可校验——在本赛事「报名需交 MOSS 归档、每场结束也需提交」的流程里，开着该设置等于每次交的都是废件。故请在录制前就确认此项为「关闭」。
判例篇 · 怎么查出来的
只讲方法链路，不含队伍名、姓名、账号等隐私信息。以下为分析框架，以及两类已脱敏的真实判例。
证据链分析方法
- 设备异常类：硬件 Sign ID / 硬盘与 USB 序列号 / MAC 与外网 IP → 关联小号、网吧同机、规避禁赛
- 程序异常类：进程 SHA2 与签名作者（Author）→ 定位可疑注入程序；游戏进程被加载的 DLL → 注入挂排查
- 输入异常类：按键节奏与偏差 → 宏使用的排查方向（结合手速、热身等合理成因综合判断）
- 文件异常类：Zip 完整性校验结果 → 判断选手是否修改过 MOSS 文件内容
- 硬件自洽类：CPU 型号 / 芯片组 / 板载设备型号的年代与平台是否自洽 → 识别伪造、篡改的硬件信息（魔改 BIOS、改写 DMI 表、虚拟化环境）
典型案例
现象：日志记录的 CPU 是 AMD 7800X3D，而主板 / 芯片组信息却指向第 9 代 Intel 平台（LGA1151 时代的 300 系芯片组）。
判据：两者物理上不可能共存——CPU 插座、平台总线与芯片组归属是硬约束，不是「搭配得奇怪」这种主观判断。AM5 的 CPU 插不进 LGA1151 的主板。
结论：被记录的硬件信息是伪造或篡改的结果（魔改 BIOS、改写 DMI / SMBIOS 主板信息、或虚拟化环境），属人为规避。这类「对不上」通常成组出现：CPU 一个平台、主板另一个平台，其余周边信息也对不齐——这正是交叉印证的价值。
现象：平台是现代 CPU，但日志里记录到的板载千兆网卡却是 2008 年前后的老型号。「一颗新 U 配十几年前的板载网卡」，这个组合本身就不成立。
判据：板载设备的型号由主板 / 芯片组决定，年代应与平台大致自洽。出现严重脱节，指向主板信息被改写。
版本提示：早年 MOSS 会单独记录网卡型号；现版本（实测 7.2.2.0）Net: 行已不含网卡型号，但仍在 PCI: 行列出网卡设备（如 Realtek PCIe GbE Family Controller），核对时看这里。
- 市面上已有把整颗 AMD 芯片组（如 B650 / B550）焊到 PCIe 卡上的「南桥扩展卡 / 南桥卡」，用于给任意主机扩出 SATA、USB、M.2 接口。2025 年底起出现开源方案与量产产品，价格已到几百元级。
- 为什么能跨平台用：AMD 芯片组的上行链路走的是标准 PCIe 协议（B650 为 PCIe 4.0 x4），而 Intel 芯片组走的是私有 DMI 协议。因此 AMD 南桥可以脱离 AMD 主板、插到任何有 PCIe 插槽的机器上（包括 Intel 平台）；反过来 Intel 南桥做不到。
- 另有主板厂商曾把芯片组做在 M.2 子板上的先例（如 X670 子板），同样属合法设计。
所以「多南桥 / IA 混合」只能作为排查方向，不能作为判罚依据。判定必须回到硬约束本身：CPU 插座与芯片组平台能否共存、板载设备是否与主板自洽。
硬件自洽性 · 交叉核对清单
- CPU 型号 ↔ 插座 / 平台 ↔ 主板芯片组：是否物理可共存（硬约束，不是「看着不搭」）
- 设备年代 ↔ 平台年代：网卡、存储控制器、USB 控制器是否出现时间线穿越
- 是否出现虚拟 / 模拟设备（虚拟显示适配器等）
- 异常是否成组出现——单点异常多为环境或硬件差异，成组矛盾才指向伪造
- 硬件 / IP 变化是否有佐证：本赛事要求选手在出现硬件变化或 IP 变化时提交行程或对应购买记录。佐证齐全、且与日志中记录到的变化自洽的，按正常变化处理；未提交或无法自洽的，才作为进一步核查的依据
- 落判前先排除合法解释：南桥卡、自行加装的老网卡 / 采集卡、外接扩展坞、游戏反作弊强制开启的虚拟化 / 安全启动开关（详见技术分析篇字段解读）
完整版 MOSS 指南
完整版面向赛事主办方与裁判，含更细的版本差异、样本说明与完整 Q&A。仅展示目录结构，正文不公开。
完整版目录
- 更新说明
- 一、为什么需要用 MOSS 反作弊
- 二、MOSS 选手使用教程
使用前提示 / 使用说明举例 / 启动 / 初次配置 / 打开录制 / 正常比赛 / 保存与提交格式 - 三、MOSS Zip 内文件的理解
Zip 文件校验 / Zip 文件结构 / MOSS Log 文件理解示范 - 四、Q&A
BUG 判定 / 无法录制 / 黑屏 / 无截图 / 找不到文件 / 无法保存 / 掉帧
防抄袭与授权机制
- 全站署名：每页页脚固定署名与出处
- 版权声明：注明「转载请注明出处」
- 授权版带水印：对外发放的完整版标注授权对象与编号
- 官网为原始发布源：保留首次发布时间戳
- 完整内容不公开：官网只露目录，正文需授权
关于作者
如果你有赛事反作弊、判罚支持或技术支持需求，欢迎联系。
背景
自 2019 年起为国内 R6S 社区赛建立技术标准体系，包括 Overlay UI 坐标规范、MOSS 反作弊使用规范、比赛规则书、OB / 导播流程；主导多起赛事违规案件（代打、鼠标宏等）的证据链分析，形成判例。