← 返回总索引CE 分析报告：对象数组与邀请封包 2026-09-16-13-19-49\CE分析报告_对象数组与邀请封包.md
分类：内存逆向与基址定位来源会话：2026-09-16原件：2026-09-16-13-19-49\CE分析报告_对象数组与邀请封包.md

CE 分析报告：对象数组结构 & 邀请封包定位

分析时间：2026-09-16 15:47
目标进程：YGOnline.exe（PID 14064，32 位）
模块基址：0x00400000，模块大小 92,463,104 字节（约 88.2 MB）
游戏目录：D:\rxjh2025\client\

一、基址 62799464 的身份

项 值
十进制 62799464
十六进制 0x03BE3E68
所属模块 YGOnline.exe（模块范围 0x00400000 ~ 0x05C28A00）
模块内偏移 YGOnline.exe + 0x37E3E68

结论：它是主模块 .data 里的静态地址，每次启动游戏都在同一位置，不需要做指针扫描，也不会随重登改变。

二、数组结构（已实地验证）

数组基址            = 0x03BE3E68
槽位 k 的地址        = 0x03BE3E68 + k * 4     ← 每个槽位 4 字节，存对象指针
对象 (obj) 结构      :
    +0x08  = 对象类型   0x31=人物  0x18=物品  0x20=?  0x22=怪物
    +0x0C  = 对象ID
    +0x18  = 名字（BIG5 编码，内联字符串）

你工程里的写法 (8000 + i) * 4 + 62799464 等价于 槽位号 k = 8000 + i，即你的扫描是从下标 8001 开始的。

★ 核心规律：对象ID == 槽位下标

实测当前在线的 34 个人物，34/34 全部满足 对象.0xC == 槽位号 k：

slot k= 9157  obj=674B8008  +C=9157  沒有男朋友
slot k= 9278  obj=6BA6E030  +C=9278  嬌小小
slot k= 9346  obj=68A10F48  +C=9346  小春
slot k= 9423  obj=68B14A88  +C=9423  一至尊一美美一   ← 你的测试角色
slot k= 9426  obj=70C664B0  +C=9426  一至尊霸王花一   ← 你的测试角色
...

也就是说：对象的 +0xC 字段 = 它在数组里的下标 = 游戏内部使用的对象ID。
你代码里的 取玩家索引 返回 i，那么 对象ID = i + 8000，而 +0xC 读出来的就是这个值，两者等价。

三、在线人物表（当前会话，34 人）

槽位/ID 名字 槽位/ID 名字
9157 沒有男朋友 9439 紫小妮
9278 嬌小小 9444 蝶皇
9281 天逆槍 9449 紫湘璦妮
9284 蝶霏 9453 瑀晨
9289 一橘色一 9456 無殤補
9293 昱辰 9459 晨昱
9296 楊董 9462 澄曉
9300 眾裡尋 9465 功夫2
9303 星空密碼 9468 JINSHEN
9346 小春 9471 功夫1
9382 盧龍吟 9474 四川麻辣燙
9423 一至尊一美美一 9477 華佗本人
9426 一至尊霸王花一 9483 半月鐮刀2
9431 青皮豆 9484 妶之樂
9433 星蝶 9487 星晴密碼
9490 功夫3 9519 花之影
9526 刀的記憶 9535 龍寶兒

四、★ 重大发现：你抓的 0x30 包不是组队邀请

把你提供的 7 个抓包值逐个丢回数组里查，结果全部指向非人物对象：

抓包值 槽位里的对象类型 说明
24 0x18 不是人物
50 0x22 不是人物
566 0x22 不是人物
730 0x20 不是人物
1302 0x22 不是人物
1343 0x22 不是人物
1424 0x22 不是人物

而人物类型是 0x31 —— 邀请一个玩家，包里却填着"物品/怪物/NPC"的槽位号，逻辑上不成立。

判断：这 7 条 0x30 包极可能是你挂机程序自己发的「打怪 / 拾取」包（目标 = 怪物或地面物品的槽位）。
因为封包拦截 hook 的是游戏统一的发包函数，你自己程序发出去的包同样会被拦到——挂机一直开着，拦截框里绝大部分是挂机自己的包，很容易误抓。

补充佐证：000000003400060001000100000000000823B1D4 里那个 0823B1D4 现在已不可读（0xFFFFFFFF，上个会话的堆已释放），无法证明它是对象指针。

五、另一个重要现象：对象ID 会变

同一角色在不同时刻 ID 不同：

原因：槽位会被回收复用，玩家换图/重新进入视野会拿到新槽位。
所以对象ID 必须每次实时读取，任何缓存都会失效——这一点你的代码写法（每次现查现发）是对的。

六、下一步：干净地抓一次真正的邀请包

  1. 先停掉挂机（停止打怪/拾取/所有自动发包），清空拦截框；
  2. 游戏里走到美美旁边，手动右键 → 邀请组队，只做这一个动作；
  3. 把新出现的那条（可能不止一条）包发我；
  4. 判断标准：
    - 若包尾 4 字节 = 9423（美美当前对象ID）→ 说明邀请包确实带对象ID，直接套现成代码；
    - 若包尾是指向对象的指针（形如 0x68B14A88 这种 6 开头大数）→ 用 取玩家对象 实时读指针填包；
    - 若命令字还是 3000 → 说明 0x30 既能打怪也能邀请（靠第 8~11 字节的固定标志区分），我们再按新包字节结构对齐。

备选方案（需要你同意）：CE 断点直接截包

我已反汇编确认 0x0076C080 就是游戏的封包发送函数（它会读 buf+4 作为长度字、长度上限 0x90）。
在它入口下断点，你手动邀请一次就能拿到最原始的邀请包字节，比拦截框更可靠。
⚠️ 但该进程加载了 XIGNCODE 反作弊（XIGNCODE\x3.xem），启用 CE 调试器有被检测的风险，要不要做由你决定。

⚠️ 风险提醒