洱海月 v0-07-0300 封包解析：ID 504 CGShopRepair（商店修理）

CGShopRepair 是当前 Temp_Release_v0-07-0300 中保留的商店修理请求包。当前 Game.exe 可以明确确认这条协议是固定 10 字节结构；当前 Lua 服务端未发现这条协议的接入入口，因此它在现项目里属于客户端保留但 Lua 未实现的商店修理协议。

包信息

项目	内容
封包 ID	504
包名	CGShopRepair
对应回包	无专用回包
作用	向 NPC 商店发起装备修理请求

当前 Game.exe 的虚函数结论为：

CGShopRepair
GetPacketID()   = 0x1405EC830 -> 504;
GetPacketSize() = 0x1401CD7E0 -> 10;
Read            = 0x1405C5650;
Write           = 0x1405C56C0;
Execute thunk   = 0x1405C5640 -> 0x140328B20;

包体结构

当前 Game.exe 结构固定为 10 字节。字段命名参考当前包名与旧 Server.i64 处理器日志，仅作为命名线索，最终长度与偏移以当前 Game.exe 为准。

偏移	长度	字段	类型	含义
0x00	0x04	repair_type	uint32	修理类型参数；旧 Server 日志中对应 Opt
0x04	0x01	repair_all_flag	uchar	是否整包修理标记；旧 Server 日志中对应 RepairAll
0x05	0x01	bag_index	uchar	目标物品所在格子索引；旧 Server 日志中对应 BagIndex
0x06	0x04	item_unique_id	uint32	目标物品唯一标识；旧 Server 日志中对应 UniqueID

当前实际行为

• 当前 Game.exe 明确保留了 CGShopRepair，并按 4 + 1 + 1 + 4 的固定顺序读写。
• 当前 Game.exe 的 Execute() 仍然只是空壳返回 2，业务意义主要来自协议结构本身。
• 当前 Lua 项目中未发现：
  • packet.CGShopRepair
  • request:CGShopRepair()
  • 对应消息服入口
  • 对应场景服处理逻辑
• 因此这条协议在当前 Temp_Release_v0-07-0300 的 Lua 服务端并未接入现行主链。
• 旧 Server.i64 的处理器字符串显示，这条包原始用途确实是 NPC 商店修理，并围绕以下参数工作：
  • Opt
  • RepairAll
  • BagIndex
  • UniqueID
• 旧处理器还存在商店操作时间限制、NPC 场景合法性、修理类型、修理等级、金钱不足等检查，说明它原本是完整的商店修理业务入口。
• 但这些旧检查只可作为历史用途参考，不能视为当前 Lua 已实现逻辑。

服务端落点

当前 Lua 项目未发现这条包的正式落点：

• 未发现协议定义：/home/ubuntu/Game2/services/game/packet.lua
• 未发现请求入口：/home/ubuntu/Game2/services/msgagent.lua
• 未发现场景处理：/home/ubuntu/Game2/services/scene/scenecore.lua

旧 Server.i64 提供的历史线索：

• 旧处理器名：CGShopRepairHandler::Execute
• 旧功能方向：NPC 商店修理

关键代码

当前 Game.exe 读包结构

__int64 __fastcall sub_1405C5650(char *a1, __int64 a2)
{
  sub_1403F9B00(a2, a1 + 28, 4u);
  sub_1403F9B00(a2, a1 + 32, 1u);
  sub_1403F9B00(a2, a1 + 24, 1u);
  sub_1403F9B00(a2, a1 + 36, 4u);
  return 1;
}

当前 Game.exe 写包结构

__int64 __fastcall sub_1405C56C0(__int64 a1, __int64 a2)
{
  (*(void (__fastcall **)(__int64, __int64, __int64))(*(_QWORD *)a2 + 8LL))(a2, a1 + 28, 4);
  (*(void (__fastcall **)(__int64, __int64, __int64))(*(_QWORD *)a2 + 8LL))(a2, a1 + 32, 1);
  (*(void (__fastcall **)(__int64, __int64, __int64))(*(_QWORD *)a2 + 8LL))(a2, a1 + 24, 1);
  (*(void (__fastcall **)(__int64, __int64, __int64))(*(_QWORD *)a2 + 8LL))(a2, a1 + 36, 4);
  return 1;
}

当前 Game.exe 关键返回值

__int64 sub_1405EC830()
{
  return 504;
}

__int64 sub_1401CD7E0()
{
  return 10;
}

__int64 sub_140328B20()
{
  return 2;
}

旧 Server.i64 的字段线索

CGShopRepairHandler Begin Opt=%d RepairAll=%d BagIndex=%d UniqueID=%X GUID = %X

结论

1. CGShopRepair 的封包 ID 是 504，当前 Game.exe 中固定长度为 10 字节。
2. 当前可以稳定确认这条包包含四个字段，长度顺序为 4 + 1 + 1 + 4。
3. 结合旧 Server.i64 的处理器日志，这四个字段可整理为 repair_type、repair_all_flag、bag_index、item_unique_id。
4. 当前 Temp_Release_v0-07-0300 的 Lua 服务端未接入这条协议，也未发现对应处理链。
5. 因此它在当前项目里应归类为客户端保留的商店修理协议，而不是 Lua 主链正在使用的现行业务包。