Придется посмотреть всё самой ^
В ргварде в dsetup идет хук на
Engine.dll вот такой офсет hEngine + 0x51F658
и такую функцию ?AddNetworkQueue@UNetworkHandler@@UAEHPAUNetworkPacket@@@Z
А в 273 Engine.dll так же на функцию ?AddNetworkQueue@UNetworkHandler@@UAEHPAUNetworkPacket@@@Z но у неё другой офсет
по сути одно и тоже просто разница в офсете ! )
Посмотреть вложение 21042 Посмотреть вложение 21043 Посмотреть вложение 21044
Для сравнения
267 : 68 75 23 43 20
273 : 68 FF 3F 43 20
разница есть , ему нужно заменить хук офсет в его либе хех
Не особо понятно) То, что ты указала, на сколько я вижу, всего лишь адреса
SEH обработчиков, и причем тут они, не совсем понятно.
С самим адресом функции AddNetworkQueue проблем как раз нет, он его получает динамически:
Код:
unsigned int AddNetworkQueue = (unsigned int) GetProcAddress(hEngine, "?AddNetworkQueue@UNetworkHandler@@UAEHPAUNetworkPacket@@@Z");
Так что это будет работать везде, другое дело, что он делает потом. Вот два потенциально кривых момента:
Код:
unsigned int startVMT = (unsigned int) hEngine + 0x51F658; // 1
//...
//...
while (true)
{
if (*(unsigned int*) currVMT == AddNetworkQueue)
return *(unsigned int*) (currVMT - 0xA4); //2
}
Во первых, никто совсем не гарантирует, что
VMT будет находиться по этому смещению.
И второе, положение указателей на функции в
VMT не определено, оно может быть
0xA4, а может и не быть.
В общем, это очень кривые способы поиска, так не надо делать.
Имелось ввиду положение функций в
VMT относительно друг друга не регламентировано. Сейчас нет под рукой engine.dll, но, вероятно, для
HF любых протоколов, указатели в
VMT на
AddNetworkQueue и SendGsPacket отличаются на
0xA4, хотя это требует проверки.
А вот на счет
VMT = hEngine + 0x51F658 я совсем не уверен.
