Я посмотрел код. Предположение было неверным.
Опкод это ровно 2 байта. Дальше данные пакета. Класс пакета - 3 виртуальных метода. Из нулевого я достал подтипы, но так и не увидел чтоб они использовались. Скорее всего для какой то внутренней организации по очередям или может приоритеты. Первый метод у всех пакетов одинаковый. Запись двух байтов опкода.
Второй метод идёт сразу за первым - данные пакета.
Например 0x116 CSRestrictCheck при входе в мир.
Пишет в первом метода 2 байта опкода. Затем во втором методе пишет сразу 4 байта, помеченые как ни странно тоже как "type". После чего пишет 1 байт "restrictCode".
Код:
Stack[00001544]:0017E052 db 16h
Stack[00001544]:0017E053 db 1
Stack[00001544]:0017E054 db 1
Stack[00001544]:0017E055 db 0
Stack[00001544]:0017E056 db 0
Stack[00001544]:0017E057 db 0
Stack[00001544]:0017E058 db 1
Вызовы идут просто подряд. Неоткуда там ещё двум байтам опкода взяться.
Код:
crynetwork.dll:063EB10D lea ecx, [ebp-10h]
crynetwork.dll:063EB110 push ecx
crynetwork.dll:063EB111 mov ecx, esi
crynetwork.dll:063EB113 call dword ptr [eax+4] ;первый виртуальный метод - запись опкода
crynetwork.dll:063EB116 mov eax, [esi]
crynetwork.dll:063EB118 lea ecx, [ebp-10h]
crynetwork.dll:063EB11B push ecx
crynetwork.dll:063EB11C mov ecx, esi
crynetwork.dll:063EB11E call dword ptr [eax+8] ;второй виртуальный метод - запись данных пакета.
Перед этим пакетом пролетают пару игровых пакетов с пустым вторым методом. Так что разница во втором и третьем байте должна встречаться достаточно часто. По крайней мере для C2S пакетов.
Но я не думаю что S2C пакеты сделаны по другому принципу. Потому что вот так хендлятся клиенские пакеты:
Код:
.text:391B071C cmp esi, 1F6h ;Проверка опкода на верхний диапазон
.text:391B0722 jge short loc_391B0785
.text:391B0724 mov ecx, [edi+esi*4+4] ;Вытаскивает пакет из таблицы
.text:391B0728 test ecx, ecx ;Проверяет на существование (в таблице встречаются нули)
.text:391B072A jz short loc_391B0785
Фрагмент таблицы:
Код:
.rdata:397D7630 off_397D7630 dd offset const PacketHandler<ClientPlayer,ServerToClientPacketType,502>::`vftable'
.rdata:397D7634 off_397D7634 dd 0 ;Ссылки на функторы
.rdata:397D7638 dd offset off_39840968
.rdata:397D763C dd offset off_39841928
.rdata:397D7640 dd offset off_398428E8
.rdata:397D7644 dd offset off_398438A8
.rdata:397D7648 dd offset off_39844868
.rdata:397D764C dd offset off_39845828
.rdata:397D7650 dd offset off_39850518
.rdata:397D7654 dd 0
.rdata:397D7658 dd offset off_398467F8
.rdata:397D765C dd offset off_398477B8
Код:
.rdata:39840968 off_39840968 dd offset const PacketFunctor<ClientPlayer,ServerToClientPacketType,SCReconnectAuthPacket>::`vftable'
.rdata:3984096C off_3984096C dd offset sub_3915B450 ; вот это хз что за метод.
За каждым функтором закреплён метод в таблице, но что делает непонятно и вроде мы в него вообще не попадаем. Разбор пакетов в виртуальных методах функтора.
Вобщем не знаю. Надо трафик посмотреть. Но не похоже, чтоб что-то сильно менялось в дальнейших вызовах.
UPD... Сейчас смотрю на порядок байт на стеке. Физически в сетевом пакете неизвестные байты до опкода или после? То, что я запостил выше это уже сырой байтовый буфер. По идее при отправке его в сеть байты уже не должны меняться местами... Тогда получается, что что-то пишется до опкода и это уже интереснее.