Радар своими руками

[murc]

может тогда проще DispatchNetworkQueue хукнуть, подменив указатели на выходе ?

[destructor]

а волкер делает так: хукает на WSAAsyncSelect()... а дальше стратегическая тайна.

Добавлено через 48 секунд

Сообщение от murc

может тогда проще DispatchNetworkQueue хукнуть, подменив указатели на выходе ?

тогда теряем оригинальные пакеты?

[murc]

Причем тут WSAAsyncSelect() и AddNetworkQueue ?

Теоретически (для Интерлюдии)
call DispatchNetworkQueue@UNetworkHandler
в [edi] - адрес структуры TNetworkPacket
меняем на свое, вуаля читем что состряпали
Теоретически все должно пройти норм.

Upd Попробовал вчера подменить в тике клиента когда DispatchNetworkQueue возвращает ноль.. access violation гдето в обработчике пакета, дальше стало лень..

[Maxno]

народ... вот есть список функций в dll в оригинале.. но как мне получить список функций уже с дампа... т.е. если вот xkor приводил пример перехвата функции "UNetworkHandler::AddNetworkQueue"... она выглядит как "?AddNetworkQueue@UNetworkHandler@@UAEHPAUNetworkPa cket@@@Z".. как получить?

ЗЫ: список функций взят от Gracia Final Epilogue (Plus)

[xkor]

Maxno, список экспортируемых функций у дампа и у оригинальной длл одинаковый
UNetworkHandler::AddNetworkQueue - название функции как оно выглядит до компиляции внутри исходников
?AddNetworkQueue@UNetworkHandler@@UAEHPAUNetworkPa cket@@@Z - название функции как оно выглядит в экспорте длл, открываешь длл любым РЕ вьювером и смотришь экспорт...

[ra1n0]

чтобы перевести ?AddNetworkQueue@UNetworkHandler@@UAEHPAUNetworkPa cket@@@Z в более читабельный вид(прим. UNetworkHandler::AddNetworkQueue) ,можно воспользоваться undname.exe
поставляемой в комплексе с VS.

[murc]

Продолжая тему про AddNetworkQueue, хочу поделится своими наработками, может кому-нибуть будут полезными ...

Что бы добавить свой пакет в массив, нужно выделить память, но просто выделить мало, нужно выделить где-то внутри ла2. Для выделения памяти я юзал ф-ию "L2MemoryAlloc", ее можно легко найти, она находится рядом с AddNetworkQueue. Выглядит она следующим образом:

L2MemoryAlloc(cmd: PWideChar; Len: integer): Pointer;

В качестве параметров используются строки "NetCmd", "NetPacket" и размер. Строки указывают для чего резервируется память и выделяется в соответствующем месте. Вообще выделение памяти здесь звучит довольно не корректно, т.к выделения памяти по сути происходит не всегда и зависит от аргументов. Стоит еще отметить то, что вызывать нужно поразному для конкретного аргумента(cmd), не знаю с чем это связано, но при вызове ф-ии в регистрах должно быть то, что должно быть, иначе будет ошибка. Для выделения памяти под сам пакет и под структуру NetworkPacket, которую в дальнейшем мы будем добавлять, я юзал такие ф-ии:

function L2MemoryAllocNetCmd(len: integer): Pointer; stdcall;
asm
  push NetCmd
  push len
  mov edx, [$01E6D6A4]
  mov ecx, [edx]
  mov edx, [ecx]
  mov eax, [edx]
  call eax
end;

function L2MemoryAllocNetPacket: Pointer; stdcall;
asm
  push NetPacket
  push $0C
  mov edx, [$01E6D6A4]
  mov ecx, [edx]
  mov eax, [ecx]
  mov edx, [eax]
  call edx
end;

Вообще это копипаст из клиента и адресс 01E6D6A4 будет действителен только для конкретных хроник - ИТ, найти в другом клиенте не должно вызвать проблем.
В первом случае мы выделяем память, куда положим свой пакет без его длинны, ID и если есть то и SubID. Во втором под структуру NetworkPacket. Заполняем и вызываем примерно таким образом:

procedure AddNetworkQueue(NetworkPacket: PNetworkPacket); stdcall;
asm
  mov ecx, [$00BFF558] - UNetworkHandler
  mov edx, [ecx]
  mov eax, [edx+$84]
  push NetworkPacket
  call eax
end;

Проверялось на Интерлюдии, должно работать везде впринципе. Самое главное выделить память без ошибок.

[xkor]

murc, думаю клиенту при вызве этих функций важно лишь содержимое ecx, ибо по соглашению thiscall там должен быть указатель на объект которому принадлежит метод, а остальные регистры по идее не обязаны содержать то что содержат)

[Yegor]

Товарищи, вы получив какие то данные из процесса l2 оперируете ими прямо в рамках внедренной dll или какимто макаром шлете основной программе (через sendmessage или по сети)? Ведь на внедряемый код наложено очень много ограничений. Вот цитата из статье с WASMа:

"Компилятор Delphi обычно генерирует в процедурах короткие переходы (JMP SHORT), но при большом размере процедуры могут появиться переходы по абсолютным адресам, поэтому внедряемый код желательно писать используя короткие процедуры, используя как можно меньше условий и циклов."

Как можно быть уверенным что что все переходы делфи сделала "короткими".
Так же как отлаживать внедренную dll? Как хотябы ее выгрузить из памяти процесса что бы я ее мог перекомпилировать и внедритль наново?

[GoldFinch]

Yegor, эта цитата относится только к тем длл которые были внедрены в чужой процесс своим кривым загрузчиком. Если загружать длл через LoadLibrary или нормальным загрузчиком таких проблем нет.
Отлаживать - так же как и клиент =)
Чтобы выгрузить - пиши код который выгрузит %)