洱海月 v0-07-0300 封包解析：ID 1101 CGCheckMessage（旧版消息校验请求）

CGCheckMessage 是当前 Game.exe 中仍保留的一条固定长请求包。现有证据能直接确认它在线上包体里只包含一个 uint32 参数和一段固定 100 字节文本，但当前 /home/ubuntu/Game2 未发现同名协议定义、请求入口或场景处理，因此它更接近旧版消息校验/文本检查相关请求，而不是现役 Lua 主链正在使用的有效封包。

包信息

项目	内容
封包 ID	1101
包名	CGCheckMessage
方向	CG 客户端 -> 服务端
包长	固定 104 字节
专用回包	无专用回包
当前 Lua 协议定义	未发现 packet.CGCheckMessage
当前 Lua 请求入口	未发现 request:CGCheckMessage()
当前 Lua 场景落点	未发现同名场景处理
当前用途	旧版消息校验/文本检查相关请求；现役 Lua 主链未接入

当前 Game.exe 可直接确认：

GetPacketID()   = 1101;
GetPacketSize() = 104;
Read()          = read_u32_check_type + read_char_100_message;
Write()         = write_u32_check_type + write_char_100_message;
Execute()       = 2;

包体结构

按当前 Game.exe 的读写函数，这条包是固定 104 字节：

偏移	长度	字段	类型	含义
0x00	0x04	check_type	uint32	消息校验类型或业务子类型；当前现役链路未接入，具体枚举含义无法确认
0x04	0x64	message	char[100]	待校验文本或消息内容；固定 100 字节文本槽位

长度规则：

packet_size = 104

字段命名说明：

• Game.exe 只给出了裸偏移和字节长度，没有直接暴露成员名。
• 本文把首字段记为 check_type，是基于包名 CheckMessage 做出的保守命名；由于当前现役 Lua 未接入，这个字段不适合继续强行细分为更具体的枚举名。
• 构造函数会把对象里偏移 0x1C 开始的 0x65 字节缓冲区清零，说明包内的 100 字节文本槽位在本地对象中还预留了额外的结尾零字节；但线上协议本身仍只传输 100 字节。

当前实际行为

• 当前 Game.exe 明确保留了 CGCheckMessage 的 RTTI、虚表、工厂和固定长读写结构。
• 当前 Game.exe 的 Execute() 仅是空壳返回 2，请求包类本身没有体现出额外客户端业务逻辑。
• 当前 /home/ubuntu/Game2 未发现：
  • packet.CGCheckMessage
  • request:CGCheckMessage()
  • 同名 msgagent 入口
  • 同名场景处理函数
• 当前 Game.exe 里也未检出 GCCheckMessage、CheckMessageResult 一类明显对应的专用回包类名。
• 因此，按当前证据，这条包更适合归类为客户端残留的旧版消息校验/文本检查请求包，而不是现役服务端已接通的业务协议。
• “消息校验/文本检查”这一用途判断主要来自包名 CheckMessage 和固定 100 字节文本结构，属于基于命名和结构的推断，不是现役 Lua 主链已经验证的结论。

服务端落点

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

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

因此，CGCheckMessage 在当前版本里没有现役 Lua 服务端处理链可供继续追踪。

关键代码

当前 Game.exe 读包结构

__int64 __fastcall CGCheckMessage_Read(__int64 pkt, __int64 stream)
{
    Read(stream, (char *)(pkt + 24), 4);    // check_type
    Read(stream, (char *)(pkt + 28), 100);  // message[100]
    return 1;
}

当前 Game.exe 写包结构

__int64 __fastcall CGCheckMessage_Write(__int64 pkt, __int64 stream)
{
    Write(stream, pkt + 24, 4);
    Write(stream, pkt + 28, 100);
    return 1;
}

当前 Game.exe 构造与关键返回值

Packets::CGCheckMessage *CreatePacket()
{
    auto *pkt = (Packets::CGCheckMessage *)operator new(0x88);
    if (!pkt)
        return nullptr;
    PacketBaseCtor(pkt);
    pkt->vftable = &Packets::CGCheckMessage::`vftable';
    pkt->check_type = 0;
    memset(&pkt->message, 0, 0x65);
    return pkt;
}

__int64 CGCheckMessage_GetPacketID()   { return 1101; }
__int64 CGCheckMessage_GetPacketSize() { return 104; }
__int64 CGCheckMessage_Execute()       { return 2; }

结论

1. CGCheckMessage 的封包 ID 是 1101，当前 Game.exe 中固定长度为 104 字节。
2. 这条包的结构已经可以确认是 uint32 check_type + char[100] message。
3. 当前 Temp_Release_v0-07-0300 的 Lua 服务端没有接入这条协议，也未发现明显对应的专用回包。
4. 因此，它应归类为“客户端保留的旧版消息校验/文本检查请求包”，不是当前 Lua 主链正在使用的有效封包。
5. 由于现行服务端没有落点，check_type 的具体枚举含义当前不宜继续强行细化。