апихуки.

[xkor]

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

если разработчики пакетхака согласятся

если будет пахать то однозначно согласятся всеми конечностями)

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

на завтра оставил самое веселое, а именно эмуляцию отсылки произвольных данных с сервера на клиент. одним местом чую, малой кровью тут не обойдется.

если данные читаются в блокирующем режиме то впринципе крови не должно быть много, по моему надо просто сделать промежуточный буфер в который писать и то что приходит от серва и то что сам хочешь клиенту отправить, для этого в WSPsend делаем цикл проверяющий нет ли в сокете данных на чтение и нет ли "своих" пакетов на отправку, если что то из этого есть то пихает в промежуточный буфер и отправляет клиенту.
единственное надо в этой функции тогда делать и перешифровку пакетов...

[LOL]

выложи свою версию уже, может на руофе будет пахать, хочу затестить))

[xkor]

LOL, через LSP на руофе тоже отправлять не получиться)

[alexteam]

xkor, угу, приблизительно так и делаю. за исключением того что всетаки WSPRecv, и крипт/декрипт будут в основном приложение.
и кровь тут ЕСТЬ.
а именно. в

function WSPRecv(s: TSocket; lpBuffers: LPWSABUF; dwBufferCount: DWORD;
    var lpNumberOfBytesRecvd, lpFlags: DWORD; 
    lpOverlapped: LPWSAOVERLAPPED;
    lpCompletionRoutine: LPWSAOVERLAPPED_COMPLETION_ROUTINE; 
    lpThreadId: LPWSATHREADID;
    var lpErrno: Integer): Integer; stdcall;

а точнее в

lpBuffers: LPWSABUF;
LPWSABUF = ^_WSABUF;

_WSABUF = record
    len: u_long;     // the length of the buffer
    buf: PAnsiChar;      // the pointer to the buffer
  end;

понятно что при вызове этой функции ей передается указатель на уже созданный в памяти _WSABUF, изменить указатель на указатель новой структуры созданной вручную не получится. приложение его просто проигнорит продолжая читать данные со старого поинтера.
поэтому приходится работать с уже существующей в памяти структурой
как то вот так

CopyMemory(lpBuffers.buf, 
                  буффер_обработаный_приложением(возможно со своими данными впереди), 
                  длинна_нового_буфера);

узкое место тут одно:
длинна_нового_буфера должна быть <= lpBuffers.len иначе нехватит места в памяти чтобы записать данные в буфер который получит клиент.
благо при обмене с ГЕЙМСЕРВЕРОМ(не с ЛС), КЛИЕНТ (не проверял на волкере и прочих) резервирует буфер длинной 16к. далеко не всегда используя его полностью.

отсюда вывод - буфер который требуется отправить НА клиент с помощью контролирующего приложения и буфер который клиент получает от сервера по длине суммарно не должны превышать 16к.

зы.
с отправкой от клиента такой проблемы нет, ибо я могу отменить отправку и отправить данные вызвав send от имени клиента. так что если разбить модуль на части
1. перехват отправки, изменение данных на такие же подлинне либо меньше - готово.
2. перехват отправки, изменение данных на данные по длине превышающие изначально отправляемые -готово
3. самопроизвольная отправка данных от имени клиента на сервер - готово
4. перехват принимаемых клиентом данных и изменение их на данные с такой же длинной либо меньше - готово
5. перехват принимаемых клиентом данных и изменение их на данные с длинной больше - возможны проблеммы.
6. самопроизвольная отправка данных на клиент - невозможно. реализация через предыдущий пункт.

то готовность самого лсп модуля около 5/6, остается проблемный 5й пункт...
буду дальше в свободное от работы время мучать WSPRecv.

зы2.
LOL, не смеши. смотри выше скрин, они встроили кодировку пакетов при отправке, ТУТ эта криптовка не обсуждается.
да и я пока не интегрировал эту вещь в пакетхак. НИКАКОЙ разборки протокола нет.

[LOL]

кодировка пакетов онли ШК-сервер.

Клиент-ШК нету кодировки. Просто надо заставить ШК понимать, что этот пакет надо слать.)

[alexteam]

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

кодировка пакетов онли ШК-сервер.

Клиент-ШК нету кодировки. Просто надо заставить ШК понимать, что этот пакет надо слать.)

вот сразу видно Знаток истории развития ШК.

найди в перечне соединений соединение клиента с шилдконсолью сейчас. раньше было. а сейчас где ?
а если пойдеш на предыдущую страницу. увидиш что сейчас кодировка распространяется на пакеты клиент->сервер.

добавлено:
и, прошу, понять что тут, конкретно в этой теме обсуждение перехвата и модификации трафика.
то как устроена та или иная защита, имхо оффтоп.

[alexteam]

в общем, 5й пункт так и остаеться черной лошадкой вместе с 6м.
могу менять данные на такие же либо меньше по длинне, но если пихать больше чем влазит в буффер - мнгновенный терминейт приложения.
клиент резервирует под чтение 56636 байтикоф, как раз под длину максимальную пакета. таких пакетов я не видел, но мало ли. шансы хоть и небольшие но есть.
завтра, дай бог оформлю это все дело как класс и займусь дебагом -)

[fragus]

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

2. с модификацией таблицы импорта. без гг метод прекрасно работает. пока за дело не принимается гг - исправляющий фарджампы. тем не менее я все еще могу отсылать данные от клиента, хотя видеть что шлет/принимает клиент с запущенным гг - не могу -)

Если не сложно, можешь выложить код длли с таким типом перехвата?

[alexteam]

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

Если не сложно, можешь выложить код длли с таким типом перехвата?

то что ты попросил - апи перехват. тобиш не не лсп.
работает при отсутствующем гг. работающий гг снимает перехват рецв и сенд в юзермоде.
присутствуют те же проблемы при отправке пакет на клиент что и с лса модулем. (зарезервированная память под буфер).
функция перехвата данных идущих на сервер требует модификации, если ты собираешься слать буферы по длине превышающие изначально пересылаемые.

добавлено: ах да. никакого разбора траффика нет. чистые необработанные данные.

[fragus]

Спасибо, то что нужно.