175 lines
16 KiB
Markdown
175 lines
16 KiB
Markdown
# IC 收发包管理器与版本维护开发计划
|
||
|
||
日期：2026 年 10 月 13 日。基线：IC Rebuild 0.1.16，国际服客户端 `2026.10.06.0000.0000`（向后兼容 `2026.09.15.0000.0000`）。
|
||
|
||
目标是依据用户提供的原版源码、作者说明和现有重建成果，完善统一收发包管理器，并建立游戏更新后的检测、适配和验收流程。本文件是后续开发补充计划；任务勾选表示对应交付物完成，不代表已经通过游戏内验收。
|
||
|
||
执行方式遵循本目录 AGENTS.md：功能优先，避免过度防御开发、过度测试和零碎发布。
|
||
|
||
2026-10-13 / 0.1.16 客户端补丁维护进展：国际服维护更新至 `2026.10.06.0000.0000`。备份旧可执行文件后完成新二进制全量扫描，全部 23 处特征码在新二进制中 100% 匹配成功，修正 `ForcedWalkHook` 签名笔误。反汇编核实 M4 主动发送通道（`ReceiverSendPacket 0x1CFD120`、`ZoneClientSendPacket 0x1D03020`、`ZoneUp 0x1D72B00`）、模块 36 收包（`ZoneDown 0x1D72680`）、模块 8 状态屏蔽（`StatusSetter 0x8A6A30`）及模块 2 最大加速度内部偏移完全一致。完成双版本向后兼容抽象及本地 `opcodes.json` 补丁配置（PingReq 137 / PingRsp 338）。详见 `diagnostics/2026-10-13-patch-2026.10.06-adaptation.md`。
|
||
|
||
2026-10-12 / 0.1.15 阶段 3 进展：完成 M0 统一版本适配与诊断（`Core/AdaptationManifest.cs`）及 M4 主动发送与请求响应事务（`Core/ActivePacketSender.cs`、`Runtime/NetworkManager.cs`）。弃用恒返回 `1` 的旧包装 `0x4810E0`，直接绑定 `ReceiverSendPacket` → `ZoneClient.SendPacket` → `ZoneUp`，保留真实 `byte` 返回码；实现 `ActiveSendScope` 来源标注（`PluginActiveSend`）、已审计业务包编码器、主线程限速队列、会话/区域门控、网络回调重入拦截与请求响应事务状态机。详见 `diagnostics/2026-10-12-stage3-m0-m4.md`。
|
||
|
||
## 范围与当前进度
|
||
|
||
原首批范围保持为 1—11、13—20、27—29、36—37，共 24 项。12 移动咏唱独立研究；38—43 保留为网络基础之后的业务扩展；21—26、30—35 继续排除。主动发送管理单列里程碑，不把它或业务自动化隐含加入原首批 36、37 的验收条件。
|
||
|
||
以本次核对到的 0.1.11 文件为基线：
|
||
|
||
| 部分 | 已有成果 | 尚待完成 |
|
||
| --- | --- | --- |
|
||
| 首批功能 | 用户确认 1、2、3、9、10、11、13、14、15、16、17、19、27、28、29 有效 | 4、5、6、7、18、20 的效果确认及各模块组合、切图、卸载验收 |
|
||
| 8 状态屏蔽 | 已核对一种网络列表为 30 个 12 字节条目，并找到消费入口及条件性 ID 转换 | 转换后处理、本地对象门控、其他列表路径、标志更新与实测 |
|
||
| 36 完整采集 | 首轮导出 891 条：上行 534、下行 357，均有完整载荷；有过滤、暂停、缓冲、导出 | 性能、反复启停、切图及卸载验收 |
|
||
| 37 协议分析 | 该样本全部 Opcode 已具名，679 条可解析已核实字段，8 组 Ping 已配对 | 212 条已命名记录尚无解析器；已支持包也未必解释全部字段 |
|
||
| 主动发送 | 原 NetRe 提供入口和接口雏形 | 新工程尚无经过完整验证的通用发送封装与事务管理 |
|
||
| 自动维护 | 已有部分版本门控、本地与在线映射校验 | 统一适配清单、更新差异检查、模块失效报告与恢复流程 |
|
||
|
||
本份样本全部具名不代表所有协议已识别。66 项离线测试通过不替代原生调用和游戏效果验收。后续实施时先读取最新 STATUS.md、VERIFICATION.md，保留主线程在本计划之后取得的成果。
|
||
|
||
## 原始资料如何复用
|
||
|
||
| 资料 | 可复用的设计或证据 | 实施要求 |
|
||
| --- | --- | --- |
|
||
| IC/NetManager.cs | NetRe、发送入口 Hook、SendPackt、IGamePacket、PreSend/PostSend 委托声明 | 恢复接口意图，补齐实际订阅调用；逐项核对发送对象头、长度、参数和有效期 |
|
||
| IC/OnlieOpcode.cs | 按客户端版本加载在线映射，并结合本地识别 | 沿用版本隔离，补充来源、证据、冲突和失效状态 |
|
||
| IC/UpPacketStructs.cs 与 DownPacketStructs.cs | 消息名称与历史字段布局 | 以当前原生读写和样本修正，不直接按旧 Size 分配或复制 |
|
||
| IC/新建 文本文档.txt | 收发时间轴、交互流程分析、后续业务扩展；结构体和 Opcode 维护提示 | 先证明流程与结果，再实现自动化；维护成本作为模块设计约束 |
|
||
| 两份 I-Ching-GL DLL | 已可靠读取的类型、接口、依赖差异 | 受保护的方法体不作为已还原算法的依据 |
|
||
| IC.Rebuild 当前实现 | 完整采集、只读副本、过滤、解析、版本映射、离线回放与资源清理 | 在现有代码上逐步整理，保持已有功能行为和已验证直接 Hook |
|
||
|
||
原 NetManager.cs 中的发送前后委托尚未形成完整事件调用流程，泛型发送也不能证明所有上下行结构体都已具备正确发送封装。原作者列出的扩展方向需要各自的业务状态、请求响应和结果验证。
|
||
|
||
## 管理器职责与数据流
|
||
|
||
建议形成以下协作关系，具体类名可结合现有工程调整：
|
||
|
||
| 部分 | 主要职责 | 验收关注点 |
|
||
| --- | --- | --- |
|
||
| 版本适配层 | 根据客户端、API、依赖和签名证据选择适配配置 | 未匹配配置不能静默使用旧指针、偏移或 Opcode |
|
||
| 原生接入层 | 管理收发 Hook、原函数调用和资源释放 | 每条原生路径的参数、返回值、调用次数与有效期明确 |
|
||
| 消息分发层 | 向观察者发布自持有数据，管理订阅和取消 | 单个订阅异常不破坏原生调用；业务订阅不受日志筛选影响 |
|
||
| 协议层 | 按版本、方向、消息类型解析与编码 | 载荷、IPC 头、原生发送对象分开；未知字段不补猜测值 |
|
||
| 发送调度层 | 排队、过期、取消、限速、连接与场景检查 | 在核实的线程和会话中调用；切区后不发送过期请求 |
|
||
| 请求响应层 | 用有依据的标识关联响应并报告结果 | 发送入口成功不等于服务端确认；无依据时不强行关联 |
|
||
| 记录与诊断层 | 时间轴、来源、过滤、失败原因、统计及导出 | 区分游戏自身发送、插件发送、原始载荷与已还原字段 |
|
||
|
||
收包流程：原生接入取得有效数据 → 在有效期内复制 → 标注版本和处理阶段 → 分发给订阅者与记录器 → 按需解析。日志的方向与 Opcode 过滤仅控制记录和显示，业务订阅使用自己的条件。
|
||
|
||
发包流程：业务请求 → 版本与场景检查 → 对应消息编码器 → 构造原生发送对象 → 在合适线程调度 → 记录调用结果 → 在有协议依据时等待响应确认。
|
||
|
||
收包观察与收包修改分开。8 如需在状态 ID 转换后处理，应使用对应原生阶段的专用适配；不能让普通日志订阅者取得可长期保存、任意修改的原生指针。
|
||
|
||
## 实施里程碑
|
||
|
||
### M0 统一版本适配与诊断
|
||
|
||
- [x] 为现有原生模块和协议建立适配清单，列明已核对版本、依赖、签名、字段与证据。
|
||
- [x] 对接现有模块管理器，区分缺实现、版本不符、签名未匹配、多重匹配、运行失败和待验收。
|
||
- [x] 明确未知版本的行为：未证明兼容的原生模块保持不可用；配置、文件导出和离线分析尽可能保留。
|
||
- [x] 增加只读检查结果，显示哪个模块受哪项变化影响。
|
||
|
||
验收：模拟版本不符、签名缺失和多重匹配，受影响模块无法错误启用；其他独立模块不因单项失败被误标为失效。签名唯一匹配仍需函数语义核验。
|
||
|
||
### M1 整理统一收包与发送观察接口
|
||
|
||
- [x] 将 NetworkCapture 的原生接入、协议读取和日志写入职责分开，保持当前完整采集结果。
|
||
- [x] 建立可取消的收包、发送前观察和发送后观察订阅，规定顺序、线程及异常处理。
|
||
- [x] 分离日志过滤与业务订阅，避免筛选窗口记录导致后续模块漏收消息。
|
||
- [x] 为消息标注方向、客户端版本、记录来源、原始或已还原阶段、完整性及失败原因。
|
||
- [x] 初始仅开放只读观察和取消订阅。没有开放取消或替换原生包；该能力若后续需要，另行核实返回语义、有效期和重入。
|
||
|
||
实现与接口约束见 diagnostics/2026-10-11-network-manager.md。891 条离线回放逐条载荷一致，不等于新管理器已完成游戏内验收。
|
||
|
||
验收：原 891 条样本回放不回退；切换日志过滤不影响业务订阅；反复订阅、取消和卸载不残留回调；订阅异常不改变原函数应有行为。
|
||
|
||
### M2 完成状态处理依据并推进编号 8
|
||
|
||
- [x] 核对单列表、双列表、其他列表变体及录像回放的调用差异（0.1.14 进一步核实 `DOWN_StatusEffectList` 30×12B 与 `DOWN_EffectResult` 4×16B 状态项均汇入 `StatusManager.SetStatus` `0x8A6BF0`）。
|
||
- [x] 明确状态 ID 转换发生的阶段，选择转换后且仍有边界依据的处理入口。0.1.12 采用 SetStatus，槽位 0—59，不访问原始网络列表。
|
||
- [ ] 用当前有效快照确认本地角色及其 StatusManager，覆盖对象消失、切区、重登和指针复用（离线已验证，待游戏内验收）。
|
||
- [x] 核对状态条目更新与相关标志重新计算，明确屏蔽的实际效果范围。保留原 setter 的通知、返回值和批量/单次刷新；只保证经过该入口的本地后续更新，实际效果仍待下项验收。
|
||
- [ ] 从一个可复现的目标状态开始实测，再逐项扩展已审计名单。
|
||
|
||
验收：目标状态效果有记录；未选状态与其他角色不受影响；关闭后恢复正常处理；切图与卸载无残留。此模块不以主动发包能力完成为前提，也不把本地状态处理表述成服务器状态已删除。
|
||
|
||
### M3 扩展协议覆盖并收尾首批验收
|
||
|
||
- [x] 按消息类型整理 212 条尚未解析记录的清单，优先处理首批功能及后续选定业务实际需要的类型。
|
||
- [x] 补动作结果、状态和事件消息的已核实字段，注明字段来源与未解释部分（0.1.14 完成 `capture-018.jsonl` 全部 891 条解析及 27 组动作请求响应配对）。
|
||
- [x] 需要新增样本时列明缺失场景、采集动作和期待消息，避免反复要求泛化抓包。
|
||
- [ ] 完成 4、5、6、7、18、20 的效果验收，以及首批模块组合、切图、退出登录和卸载检查。
|
||
|
||
验收：支持类型对正常、截断、错误计数和版本不符有明确结果；未知包保留原始记录。建立可重现流程的证据，不以本份样本的未知数为零宣称协议全部完成。
|
||
|
||
### M4 恢复主动发送与请求响应管理
|
||
|
||
- [x] 对照原 NetRe 核实当前发送入口、真实参数及返回含义（0.1.15 弃用恒返回 1 的 `0x4810E0`，改用 `ReceiverSendPacket` `0x1CFD140` → `ZoneClient.SendPacket` `0x1D03040` → `ZoneUp` `0x1D718C0`）。
|
||
- [x] 为首个选定消息编写独立编码器，明确业务载荷、原生发送对象、长度和缓冲区所有权（`UP_ActionSend`、`UP_ClientTrigger`、`UP_EventStart`、`UP_EventFinish*` 8 档、`UP_EventAction*` 8 档）。
|
||
- [x] 优先从已核实的游戏接口调用方式接入，统一版本检查、诊断和发送来源标记（`PacketOrigin.PluginActiveSend`）。
|
||
- [x] 加入有界队列、取消、会话标识、过期时间及调度线程约束，避免从接收回调中直接递归发送。
|
||
- [x] 区分排队、已调用原生发送、原生拒绝、收到确认、超时和取消；取消排队不等于撤销已发送请求。
|
||
- [x] 仅在消息关联依据和重复操作语义明确时加入重试，不统一重放所有捕获包（当前不自动重发任何原生调用）。
|
||
|
||
验收：编码与原生对象构造有边界测试；实际场景能确认预期结果；断线、切区、重复操作、取消和卸载行为明确。发送接口不能以单个 bool 冒充整个交互流程成功。
|
||
|
||
M4 是单列的恢复里程碑。其接口设计可以与 M1 并行，但真实调用依赖 M0 和相应消息契约核实；它不阻塞原首批记录、解析和状态处理的独立交付。
|
||
|
||
### M5 进入选定业务扩展
|
||
|
||
38—43 继续作为候选，不自动全部开工。每次选定一项后，再明确业务状态、请求响应链、成功依据、超时、取消和异常恢复。作者提到过某项能力，只说明存在参考方向，不等于当前客户端与服务器已经验证可用。
|
||
|
||
## 游戏更新维护流程
|
||
|
||
目标是更新后自动发现问题、辅助定位、按模块适配。不能承诺客户端每次更新后无需核验即可恢复全部功能。
|
||
|
||
### 每版本保存的适配信息
|
||
|
||
| 信息 | 保存内容 |
|
||
| --- | --- |
|
||
| 客户端 | 区服、完整版本、核对过的可执行文件标识或哈希 |
|
||
| 运行依赖 | Dalamud API 与程序集版本、FFXIVClientStructs 版本、关键委托及字段布局 |
|
||
| 原生入口 | 签名、匹配数量、函数参数、用途、支持的模块和核对记录 |
|
||
| 协议 | 版本、方向、Opcode、名称、长度规则、字段和 ID 转换阶段 |
|
||
| 映射来源 | 远程、本地文件、原生核对或样本证据，以及冲突处理结果 |
|
||
| 验证状态 | 构建、离线回归、具体游戏场景、限制及结果日期 |
|
||
| 发布与回退 | 包版本、校验值、配置迁移说明和前一版本备份 |
|
||
|
||
现有 CurrentProtocolEvidence 中按版本补充且不覆盖显式映射的原则继续保留。发现显式映射与新证据矛盾时记录冲突，不能静默改名后伪装没有差异。
|
||
|
||
### 更新后的执行顺序
|
||
|
||
1. 记录新的游戏与依赖版本，保留上一份适配清单、发行包和必要配置备份。
|
||
2. 检查插件能否在新 API 中加载；若 API 不兼容，先由外部构建和程序集检查定位问题，不能依赖插件内面板完成诊断。
|
||
3. 只读检查签名是否缺失或多重匹配、委托及结构是否变化，生成受影响模块清单。
|
||
4. 检查新版本 Opcode 映射。没有匹配映射时不套用旧名称；采集本身也须通过对应原生布局检查后才可启用。
|
||
5. 对长度异常、计数异常、解析失败率增加及 ID 转换变化做差异分析，按需要安排少量针对性样本。
|
||
6. 修复对应模块，跑相关离线回归，并记录新的原生和协议依据。
|
||
7. 在游戏内按模块验证，再检查组合、切图和卸载；逐项恢复适配状态。
|
||
8. 构建发布并核对部署文件，保留变更说明与待验收项。
|
||
|
||
游戏版本没变但 Dalamud 或 FFXIVClientStructs 更新时，也要检查相关依赖差异。版本门控不能只看 API 主版本。
|
||
|
||
### 可自动完成与必须核验的边界
|
||
|
||
| 可自动完成 | 不能仅凭自动检查断言 |
|
||
| --- | --- |
|
||
| 版本与哈希差异、编译结果、程序集元数据差异 | 原生函数的行为仍与旧版相同 |
|
||
| 签名匹配数量和候选定位 | 匹配唯一就代表参数和语义正确 |
|
||
| 映射冲突、长度、数量和解析失败统计 | 包名称及未知字段的业务含义正确 |
|
||
| 已有脱敏样本回放、错误输入与生命周期测试 | 新客户端现场表现与服务器结果正确 |
|
||
| 打包校验、备份和变更报告 | 旧 DLL 能在新游戏上正常使用 |
|
||
|
||
发生更新不应重写已验证的所有功能。继续保留便于维护的直接 Hook；通过依赖关系只处理受到变化影响的部分。
|
||
|
||
## 开发交付与主线程衔接
|
||
|
||
- 当前按用户最新要求推进收发包管理器：M1 已交付只读实现，下一步沿 M4 核对实际发送封装与首个消息契约，按具体需求再接入主动发送。编号 8 继续待实测，M3 围绕具体功能安排解析，M5 按后续选择进入。不得为了先建成全部基础框架而阻塞可用功能交付。
|
||
- 不预设新版本号或日历工期。每个里程碑以证据、实现、相关测试和游戏验收状态作为交付依据。
|
||
- 诊断报告保存必要的长度、计数、类型和结果；共享测试使用合成或脱敏数据，不复制无关聊天、角色身份和完整会话数据。
|
||
- 每次交付更新实施状态和验证记录，明确已实现、待实测、受限及未实现内容。
|
||
- 相关改动合并发布，必要检查通过后无新问题不重复验证；现有样本够用时不要求用户重新采样。进度优先报告功能结果，详细测试数量留在验证记录。
|
||
- 该文件独立保存旁支方案；现有 IC/PLAN.md、源码、配置和部署未因创建本文件而改变。
|
||
|
||
相关依据：IC/PLAN.md、IC.Rebuild/STATUS.md、IC.Rebuild/VERIFICATION.md，以及 diagnostics 中的双 DLL 对比、完整采集、capture-018 回放、Opcode 核对和状态处理记录。
|