miyakejima/xigncode3-blackdesert

## 概述 本档案重构并记录了在三个加密容器中交付，并随当前 Black Desert 客户端部署的客户端 XIGNCODE3 文件。该流水线追踪了从原始容器记录到解包、原生反编译、语义建模、行为文档化、专门的 `xhunter1` 内核驱动修复、被动运行时核对，以及针对特定目标的形式化安全属性保证的每一个产出物。 **目标：** 深入理解 XIGNCODE3 本身 —— 包括其文件格式、模块、配置和策略数据、用户态架构、内核驱动、IPC 和报告关系、检测家族，以及可观察的启动和关闭行为。 ## XIGNCODE3 的真实面貌 分析表明，XIGNCODE3 是一个**模块化、数据驱动的反作弊平台** —— 而非单一的整体二进制文件。客户端在加密容器中交付，在运行时由私有加载器解包，并通过分层架构进行编排，将频繁更新的策略数据与原生检查器代码分离开来。 该系统将其职责划分为三个概念层： **1. 引导与更新 (`xup`)** —— 验证已安装状态，检查更新，并在激活任何保护之前准备好环境。 **2. 用户态运行时** —— 私有加载并由 `xclio_egg` 编排的专用插件家族集合： - `xst` 作为广泛的核心运行时，提供扫描器、解析器、加载器服务、Lua 脚本支持、系统信息收集器和共享报告基础设施。 - `xclio` / `x3_egg` / `xclio_egg` 负责私有加载、探针协调、数据包缓存、特征码分发以及报告作业管理。 - `xez` / `xkaga` / `xobserver` 将环境、进程、模块、窗口、显示、输入、叠加层、文件和外设检查划分为独立的插件家族。 - `xsg` 提供通往内核驱动的显式用户态桥接。 - `xspirit` 是一个遗留的 UDP/TDI 挂载与过滤家族，存在于容器中，但在观察到的会话中未被加载。 **3. 内核驱动 (`xhunter1.sys`)** —— 特权监控层。在游戏启动时被写入 `C:\Windows\xhunter1.sys`，作为服务加载，并在游戏退出前卸载。负责进程和镜像加载通知、对象和注册表监控、内存和服务检查、访问过滤，以及通过 IPC 向用户态结构化地交付报告。 **数据资产** —— XdNa 记录、JSON 策略、SPO/TARA 特征码、Lua 表和 XIP 数据与原生检查器代码保持独立，可以独立更新：486,299 条 IP 地理边界，288,541 行 REAL/SPO 哈希和标签记录，涵盖 9 个分组的 207 个 TARA v3 原生特征码，以及 194 个控制驱动、进程、窗口、证书、模块、虚拟机和图形子系统的允许/拒绝/排除规则的配置类别。 ## 快速导航 | 需求 | 前往位置 | |---|---| | 🗺️ 一目了然地了解整个项目 | [**项目地图**](PROJECT_MAP.md) | | 📖 当前架构、状态和发现 | [**Layer 8 — 手册**](8_maximum_client_reconstruction/README.md) | | 🔬 形式化安全属性证明结果 | [**Layer 9 — 保证包**](9_target_specific_assurance/README.md) | | 🪲 内核驱动深度剖析 | [**xhunter1 深度重构**](xhunter1_008A5000_deep_reconstruction/README.md) | | 📊 xhunter1 六大领域上限指标 | [**xhunter1 上限通过**](xhunter1_008A5000_deep_reconstruction/CEILING_PASS.md) | | 🔩 所有伪代码和调用图 | [**Layer 5 — 去保护 / 反编译**](5_deprotected_decompiled/README.md) | | 🏷️ 模块身份、角色、RTTI、相似度 | [**Layer 6 — 语义模型**](6_semantic_model/README.md) | | 🧠 静态行为模型 | [**Layer 7 — 行为文档**](7_behavior_documentation/README.md) | | ⚠️ 架构弱点和暴露面 | [**XIGNCODE3 的弱点**](WEAKNESSES_OF_XIGNCODE3.md) | | 🧾 运行时证据目录 | [**Layer 8 证据目录**](8_maximum_client_reconstruction/docs/reference/EVIDENCE_CATALOG.md) | | 🔍 架构和组件指南 | [**Layer 8 架构**](8_maximum_client_reconstruction/docs/01-overview/ARCHITECTURE.md) | | 📡 检测家族和子系统模型 | [**检测子系统**](8_maximum_client_reconstruction/docs/04-data-and-protocols/DETECTION_SUBSYSTEMS.md) | | ⚙️ 配置和策略行为 | [**配置行为**](8_maximum_client_reconstruction/docs/04-data-and-protocols/CONFIGURATION_BEHAVIOR.md) | | 🔗 IPC 通道和报告流水线 | [**IPC 通道**](8_maximum_client_reconstruction/evidence/ipc_channels.csv) · [**报告流水线**](8_maximum_client_reconstruction/evidence/reporting_pipeline.csv) | ## xhunter1 内核驱动 内核驱动是最重要的分析目标，并在主流水线之外进行了专门的深度重构。 `xhunter1.sys` 被写入磁盘，作为 Windows 服务加载，并在游戏退出前卸载。它是 XIGNCODE3 技术栈的特权监控层，负责： - **进程和镜像加载通知** —— 激活时接收内核中加载的每个新进程和镜像的回调。 - **对象管理器和注册表监控** —— 监控与受保护进程相关的句柄操作和注册表更改。 - **内存和服务检查** —— 按需检查内存区域和服务状态。 - **访问过滤** —— 可以过滤受保护对象的访问操作或对其采取行动。 - **报告交付** —— 将观察结果打包成结构化报告，并通过命名设备 (`xhunter1`) 和命名事件 (`XcoreNotifyReportEvent`) 交付给用户态，由 `xsg` 使用。 该驱动在分析前进行了独立的 4 趟函数边界修复。最初的 Ghidra 解析产生了 630 个碎片化的边界条目；修复后，剩下 520 个，其中 467 个被确认为真正的语义例程。 | 指标 | 数值 | |---|---:| | 加载时的模块大小 | **194,448 字节** | | 与静态重构的 SHA-256 匹配 | ✅ 完全一致 | | 原始函数条目（修复后） | 519 / 520 包含伪代码 | | 确认的真正语义例程 | **467 / 467** | | 上限通过审查为干净 | **397 / 467** | | 已命名的函数 | **78** | | 已映射的写入协议操作 | **44 / 44** | | 修复的虚假边界拆分 | **110** (跨越 4 趟) | | 驱动活动持续时间（观察到的会话） | **254.8 秒** | | IPC 路径 | `\Device\xhunter1` + `XcoreNotifyReportEvent` | → [**完整的内核驱动分析 →**](xhunter1_008A5000_deep_reconstruction/README.md) ## 检测架构 从静态语料库和配置数据中恢复并建模了 11 个检测家族。该家族模型涵盖： - **基于哈希的识别** —— 来自 REAL/SPO 数据集的 288,541 行哈希和标签记录，通过精确的二进制哈希识别已知目标。 - **原生字节模式匹配** —— 涵盖 9 个分组的 207 个 TARA v3 特征码，用于扫描已知的字节序列。 - **进程和模块枚举** —— 通过 `xez` / `xkaga` 家族进行环境和进程检查。 - **窗口、显示和输入监控** —— 通过 `xobserver` 和 `xkaga` 检查叠加层、外设和输入设备。 - **驱动和证书策略** —— 来自 JSON 策略的内核模块和签名身份的允许/拒绝规则。 - **虚拟机和图形检测** —— 控制虚拟机环境和图形子系统状态的配置类别。 - **名称和描述符匹配** —— 通过多个策略类别进行字面路径、名称和元数据检查。 - **内核回调覆盖** —— 来自 `xhunter1` 的进程、镜像、对象管理器和注册表通知。 - **内存检查** —— 来自内核层的目标内存读取和完整性检查。 - **基于地理位置的策略** —— 包含 **486,299** 条记录的 XIP IPv4 边界数据，提供特定区域的规则变体。 - **报告编排** —— `xclio_egg` 将探针结果协调到 8 阶段的检测到交付流水线中。 → [**检测子系统模型 →**](8_maximum_client_reconstruction/docs/04-data-and-protocols/DETECTION_SUBSYSTEMS.md) ## 运行时佐证 一次被动的 Windows ETW 会话捕获了完整的生命周期：签名启动器 → 游戏菜单空闲 → 正常关闭。内核记录器报告 **零丢失事件或缓冲区**。未使用任何调试器、补丁、注入或强制终止。 | 观察 | 细节 | |---|---| | 访问的源容器 | 与提供的 `xmag_x64.xem` 和 `xnina_x64.xem` 完全一致 ✅ | | `xhunter1.sys` 身份 | 与静态重构的 SHA-256 完全匹配 ✅ | | `xhunter1.sys` 大小 | 194,448 字节 — 与静态模型匹配 ✅ | | 驱动加载时间 | 游戏进程创建后 **+21.654771秒** | | 驱动卸载时间 | **+276.482228秒** — 游戏退出前 3.239886秒 | | 驱动活动持续时间 | **254.8 秒** | | 游戏进程运行时间 | **263.9 秒** | | 隐藏的 NTFS 流 GUID 相关性 | 2 个 GUID 与 3 个 `xclio_egg` 静态函数匹配 ✅ | | 远程 IP/端口联系 | 13 对；2 个 IP 与配置的 XIGNCODE 候选者匹配 | | 内核记录器完整性 | 零丢失事件或缓冲区 ✅ | | 确认的生命周期阶段 | 15/15 生命周期声明，具有独立的静态和运行时状态 | → [**完整的运行时发现 →**](8_maximum_client_reconstruction/docs/02-runtime/RUNTIME_FINDINGS.md) ## 弱点和暴露面 [XIGNCODE3 的弱点](WEAKNESSES_OF_XIGNCODE3.md) 文档是对本次会话中恢复的架构限制和具体暴露面的 659 行形式化分析。它严格区分了直接确定的弱点、合理的假设以及固有的客户端信任限制。**它不包含任何补救措施部分。** ### 已验证的弱点（运行时确认） | ID | 发现 | 可利用性 | |---|---|---| | **V01** | 内核监控在受保护游戏进程启动 **5.864 秒后** 才开始 | 有条件 | | **V02** | 内核监控在进程退出 **3.240 秒前** 结束 | 有条件 | | **V03** | 驱动激活状态会产生稳定的、本地可观察的痕迹 —— 使得 V01/V02 的时间点可区分 | 实际可行 | | **V04** | 精确匹配规则（哈希、字节模式、名称、描述符）只能识别表示形式，而非行为 —— 一种新的表示形式就能击败特定规则 | 在单一层面上实际可行 | ### 合理的弱点假设 | ID | 假设 | |---|---| | **H01** | 计划内的检查可能会错过足够短暂的状态 | | **H02** | 私有可执行映射会丢失正常的镜像身份，检测只能退回到启发式方法 | | **H03** | 允许列表和排除项可能会将信任转移给不安全的行为 | | **H04** | 已签名或被允许的内核组件可能会代理特权操作 | | **H05** | 内核发现依赖于多阶段的用户态交付路径，该路径可能会产生偏差 | | **H06** | 依赖于 OS 布局的检查在不支持的配置上可能会降级 | ### 架构限制（客户端反作弊固有） | ID | 限制 | |---|---| | **A01** | 同等权限的内核代码可以更改监控器及其证据 | | **A02** |底层的 hypervisor 可以控制客户机可见的现实 | | **A03** | DMA 可以在正常的 OS 事件路径之外访问内存 | | **A04** | 机外自动化仅在本地留下普通的显示和输入证据 | | **A05** | 仅客户端的监控无法检查完全在客户端之外的状态 | → [**完整的弱点分析 →**](WEAKNESSES_OF_XIGNCODE3.md) ## 形式化安全属性保证 (Layer 9) Layer 9 针对哈希识别的产出物（即本次部署中的精确容器和模块），形式化了 31 项安全属性证明义务。义务涵盖五个类别：有效性、超属性、可用性、机密性和未指定的行为属性。 该分析使用通过 Ghidra Sleigh p-code、angr VEX 和 Unicorn 仿真进行的有界 IR 提升。合成状态机场景提供了独立的验证。在最终输出中未保留任何具体的求解器赋值。 | 结果 | 数量 | 含义 | |---|:---:|---| | ✅ **PROVED** | **15** | 属性对于产出物的有界模型成立 | | ❌ **REFUTED** | **1** | 属性不成立 —— 存在反例 | | 🟡 **SAT_REACHABLE** | **8** | 找到了通向属性边界的满足路径；尚未证明或反驳 | | ⚪ **UNKNOWN** | **7** | 求解器超时或有界模型不足 | | **已解决总计** | **24 / 31** | PROVED + REFUTED + SAT_REACHABLE | | 独立佐证 | **22** | 由 Layer 9 之外的证据支持的义务 | | 合成场景 | **8 / 8** | 通过了所有合成状态机保证场景 | | 保留的求解器赋值 | **0** | 未保留任何具体的漏洞利用数据 | → [**完整的保证包 →**](9_target_specific_assurance/README.md) ## 研究流水线 每个编号目录都是一个**转换阶段** —— 是分析的进展，而不是项目的独立副本。Layer 0 和 4 仅为文档。 | 阶段 | 目录 | 产出 | |:---:|---|---| | **0** | [0_source_inputs](0_source_inputs/README.md) | 三个源容器的确切身份和哈希 | | **1** | [1_unwrapped](1_unwrapped/README.md) | 将容器记录切割为 XdNa、Lomx、TARA、PI5z、镜像和资产记录 | | **2** | [2_unpacked](2_unpacked/README.md) | 可用的 PE、Lua 字节码、特征码、JSON、镜像和 XIP 数据 | | **3** | [3_decompiled](3_decompiled/README.md) | 初步 Lua 反编译和代表性的静态工具筛选 | | **4** | [4_intermediate_analysis](4_intermediate_analysis/README.md) | 记录向完整静态语料库的过渡；无重复的产出物 | | **5** | [5_deprotected_decompiled](5_deprotected_decompiled/README.md) | 完整的 Ghidra 原生语料库、可读的 Lua 和解码后的数据表 | | **6** | [6_semantic_model](6_semantic_model/README.md) | 模块身份、角色、RTTI、导入/导出、结构和相似度 | | **7** | [7_behavior_documentation](7_behavior_documentation/README.md) | 静态架构、工作流、证据和限制 | | **↳** | [xhunter1 深度重构](xhunter1_008A5000_deep_reconstruction/README.md) | 4 趟边界修复；修正了语义、结构和上限覆盖 | | **8** | [8_maximum_client_reconstruction](8_maximum_client_reconstruction/README.md) | 手册、运行时核对、函数索引、证据目录和验证 | | **9** | [9_target_specific_assurance](9_target_specific_assurance/README.md) | 基于哈希绑定的证明义务、有界 IR、合成验证和结果 | ## 定量结果 | 测量项 | 数值 | |---|---:| | 根据提供的哈希验证的容器 | **3 / 3** | | 重构的原生模块 | **17** | | 修复后的函数条目 | **32,768** | | 包含 Ghidra 伪代码的条目 | **32,761** | | 失败的条目 | 7 | | 唯一的 RTTI 类/接口 | **530** | | 索引的配置类别 | 194 | | 建模的检测家族 | **11** | | 解码的 XIP IPv4 地理边界 | **486,299** | | 解析的 REAL / SPO 哈希-标签记录 | **288,541** | | 解析的 TARA v3 原生特征码 | **207** (9 个分组) | | 恢复的 JSON 策略类别 | 多个（驱动、进程、证书、模块、VM、图形、输入） | | xhunter1 真正的语义例程 | **467 / 467** | | xhunter1 已命名的函数 | **78** | | xhunter1 已映射的写入协议操作 | **44 / 44** | | xhunter1 修复的虚假边界拆分 | 110 | | 导入的被动运行时会话 | 1 | | 确认的运行时生命周期阶段 | **15 / 15** | | 与静态模型相关的 NTFS 流 GUID | 2 | | 形式化的 Layer 9 义务 | **31 / 31** | | Layer 9 PROVED | 15 | | Layer 9 REFUTED | 1 | | Layer 9 SAT_REACHABLE | 8 | | Layer 9 UNKNOWN | 7 | | **Layer 9 已解决** | **24 / 31** | | 独立佐证的义务 | 22 | | 合成保证场景 | **8 / 8** 通过 | | 保留的具体求解器赋值 | **0** | ## 证据标准 本档案严格区分了六类证据。没有相应层级的支持，任何发现都不会被提升。 | 类别 | 含义 | |---|---| | ✅ 已确认的静态事实 | 直接从恢复的二进制结构、字符串或元数据中确立 | | 🔵 强有力的推断 | 结构性证据强烈支持该声明；但未直接观察到过渡 | | 🟢 运行时确认的事件 | 在观察到的会话期间由被动的 Windows ETW 逐字捕获 | | 🟡 精确的运行时关联 | 特定的静态产出物与实时观察结果一一对应匹配 | | ⚪ 进程级别的观察 | 在进程粒度上可见；未识别出私有模块所有者 | | ❌ 未知 | 明确未解决 —— 绝不假定其干净或存在缺陷 | 成功的反编译**并不**意味着完全的语义理解。进程级别的事件**并不**能自动识别出负责的私有模块。仅凭此语料库无法恢复精确的私有符号、所有可能的执行路径、服务器内部结构以及原始源代码。 → 术语、方法、证据规则和剩余差距：[**Layer 8 文档地图**](8_maximum_client_reconstruction/docs/README.md) · [**证据模型**](8_maximum_client_reconstruction/docs/05-methodology/EVIDENCE_MODEL.md)

标签：Homebrew安装, rizin, 云安全监控, 云资产清单, 内核驱动, 反作弊, 客户端加密, 无线安全, 漏洞分析, 网络协议, 路径探测, 逆向工程, 静态分析