38 lines
2.4 KiB
Markdown
38 lines
2.4 KiB
Markdown
# 当前客户端网络长度来源：第一轮核对
|
||
|
||
客户端：2026.09.15.0000.0000。2026-10-11 继续开发时，只读检查本机 ffxiv_dx11.exe；没有访问游戏进程，也未改动 0.1.7 的采集 Hook。
|
||
|
||
## 上行已发现长度来源
|
||
|
||
现有 ZoneUp 签名唯一匹配 RVA 0x1D718C0。参数：rcx 为连接，rdx 为发送对象（保存到 rsi），r8 为附加参数指针，r9b 为标志。
|
||
|
||
正常状态分支在 RVA 0x1D7198C 附近：
|
||
|
||
```text
|
||
mov r8,[rsi+8]
|
||
lea rdx,[rsi+20h]
|
||
sub r8,10h
|
||
add rcx,10h
|
||
call 0x141DA6CB0
|
||
```
|
||
|
||
另一发送分支 0x1D71A84 使用相同的源指针及长度运算。这支持当前版本发送对象的实际复制范围为 `[data+0x20, data+0x20+(u64[data+8]-0x10))`，与旧事件给出的载荷起点 data+0x20 一致；长度不是按 Opcode 历史结构大小推算。
|
||
|
||
此前 0x1D71942 也把 `[rsi+8]` 传给 0x20F6200 的消息构造流程。唯一直接调用者位于 0x1D03040（ZoneClient.SendPacket 包装），0x1D03065 调用该发送函数。
|
||
|
||
下一步仍需核实复制辅助函数 0x1DA6CB0 的语义、发送对象创建时的长度契约，并为下限 0x10、最大采集量、版本门控、异常长度回退设计有界读取。此处记录原生证据，不等同于完整采集功能已完成或实测。
|
||
|
||
## 下行仍缺边界契约
|
||
|
||
PacketDispatcher 构造签名唯一匹配 0x18D9466，第一虚表为 RVA 0x23129E8，slot 1 指向 OnReceivePacket RVA 0x18D9500。函数开头读取 r8+2 的 ushort Opcode，r8 为现有下行 data，edx 为目标 ID。
|
||
|
||
ECommons 兼容代码使用载荷起点 data+0x10，并曾取 data-0x10 作为外层头部。这里尚未核实外层对象长度的来源和可读边界，不能仅凭历史包头布局在 data 前反向读取并复制。
|
||
|
||
下一步从 Application PacketReceiver 回调向下行分派调用追踪外层消息对象的长度，优先寻找明确携带长度的入口。
|
||
|
||
## 8 状态处理线索
|
||
|
||
本地 FFXIVClientStructs 的 IDA 标识表提供 HandleStatusEffectListPlayerPacket、HandleStatusEffectListPlayerDoublePacket、HandleStatusEffectListPacket、Eureka、Bozja、Double 等分类入口。这些源码地址不是本机已验证地址，不能直接挂接。现有 StatusManager 则是 60 个 16 字节的客户端状态项，与旧网络列表不是同一结构。
|
||
|
||
8 仍未启用；后续结合当前 dispatcher 分支、完整下行长度和动作表核对各状态列表入口，不能把某一类 30 项布局套到所有列表。
|