NewXor. изменения в 3.5.25.145+.

[nezabudkin]

данный топик - вырезка с темы Модификация L2phx 3.2.0 (Официальное продолжение программы) (http://coderx.ru/showthread.php?t=618).
этот кусок темы содержит обсуждения изменений/нововведений в newxor'е включенных в релиз 3.5.25.145
Если читать эту тему внимательно, то уверен что 100% вопросов касаемо изменений отпадут сами собой.
и 99% вопросов касаемых того где взять пример, и что необходимо для того чтобы пример скомпилировать.


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

[alexteam]

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

[nezabudkin]

самая важная часть вынесена. (newxor)
в енкдеке без него остаеться только определение имени персонажа и прочие мелочи

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

[alexteam]

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

работоспособность невксора на протоколе где первые 2 байта пакета = длинне пакета только что проверена (http://i.piccy.info/i4/1d/22/b6a77e6978009ccf6bc0b95617d9.png)

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

Добавлено через 9 минут
в общем идея неоднократно обмозговывалась, руки вот до реализации не доходили, суть идеи довольно проста как в реализации так и в использовании.
требуется помимо этих вот функций
procedure DecryptGP(var Data; const Size: Word);override;
procedure EncryptGP(var Data; const Size: Word);override;
добавить еще 2 функции
procedure DecryptTRAFFICK(var Data; const Size: Word);override;
procedure EncryptTRAFFICK(var Data; const Size: Word);override;
непосредственно вызываемые в сокетном енджине при приходе пакета до обработки их.
(кстати, равлоги текущие это глубокое эхо этой самой идеи... )
DecryptTRAFFICK должен будет приводить траффик в порядок (в вид первые 2 байта = длинне пакета)
и по аналогии EncryptTRAFFICK вызываемый непосредственно перед отправкой, с обратым DecryptTRAFFICKу действием.

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

[nezabudkin]

добавить еще 2 функции
procedure DecryptTRAFFICK(var Data; const Size: Word);override;
procedure EncryptTRAFFICK(var Data; const Size: Word);override;
непосредственно вызываемые в сокетном енджине при приходе пакета до обработки их.

если не сложно, давай поробуй,
может отдельную dll-ку для этого организовать?
кроме первых 2-х байт будут ли еще различия в пакетах?

[alexteam]

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

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

Добавлено через 1 минуту
кстати, рабочий невксор с дефолтной обработкой всунул в плагинкоддинг, обновлю его вместе с пх как только закончу с этой идеей.

[nezabudkin]

кстати, рабочий невксор с дефолтной обработкой всунул в плагинкоддинг

Проверь newxor на тест-сервере MKSа. Я как подключаю эту dll-ку, так глюки с расшифровкой начинаются и, вообще, потом клиент зависает, хотя ничего там не менял. Хотя на старых версиях пакетхака я newxor успешно переделывал.
Может это потому что я использую coding.pas старый?

[alexteam]

Проверь newxor на тест-сервере MKSа
скрина мало ? %)

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

Добавлено через 1 час 8 минут

По просьбам трудящихся. релиз 3.5.25.145.

[-] некритичная бага с WM_ProcessPacket при вызове его с плагина при условии что тунель уже умер, приводящая к спаму ошибкой

[+] в TCodingClass добавленны:
procedure PreDecrypt(var Data; var Size: Word);
procedure PostEncrypt(var Data; var Size: Word);

схема выполнения:
обычный "сниффинг"
Client/Server>>PreDecrypt>аккумулятор сокетного движка>DecryptGP>(PH. плагины и скрипты)>EncryptGP>PostEncrypt>>Server/Client

для произвольной отправки пакета (плагинами, скриптами)
плагин/скрипт>EncryptGP>PostEncrypt>>Server/Client

в PreDecrypt поступают необработанные данные только что вытянутые из тцп стека. после обработки в PreDecrypt данные должны принять вид - "первые 2 байта = длинне пакета"
дабы сокетный движек обрабатывал это данные без помех.

в PostEncrypt должны поступают данные в формате "первые 2 байта = длинна", на выходе - данные понятные серверу/клиенту.

если нужды в PreDecrypt/PostEncrypt нет то оставить эти функции пустыми.
[+] в PluginCodding добавлен невксор с стандартным ксорингом для серверов без шифрации. с учетом этих изменений.
newxor сможет менять длинну пакета.

релиз 3.5.25.145 перезалит

[nezabudkin]

procedure PreDecrypt(var Data; const Size: Word);
procedure PostEncrypt(var Data; const Size: Word);


alexteam, теперь эти функции будут вызываться начиная с самого первого пакета? причем неважно, чтобы там не пришло?

[nezabudkin]

ХМ, слил с svn последнюю версию, при компиляции newxor получаю ошибку.

[alexteam]

newxor сможет менять длинну пакета.

Ктрл+клик на tcoddingclass
там явно видно что const стал var

Добавлено через 4 минуты

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

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

[nezabudkin]

сокетный движек получает часть данных с стека
отправляет эту часть в DecryptTRAFFICK (при чем следует учесть что частью траффика может быть и полпакета такие случаи очень редки но исключать их нельзя, у меня за это аккумулятор в пх отвечает, а тут прийдеться без него)
а можно чуть по подробнее, в каких таких случаях может прийти только часть пакета, и как это определить что пакет не полный?

[alexteam]

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

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

[xkor]

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

[nezabudkin]

alexteam, а что за бонус в версии 3.5.25.145 под названием Xorruoff.dll ?

[alexteam]

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


nezabudkin, а, не обращай внимания, убрал с билда, дабы не пугались -)

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

[nezabudkin]

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

alexteam, xkor, может вы тогда это реализуете в newxor, вы ведь уже на этом "собаку съели", или хотя бы пример выложите как реализовать сборку пакета в единое целое. А то мне придется такой лес там городить...

[alexteam]

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


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

сразу определюсь. чтобы не путаться
линеевский пакет - часть данных с длинной равной первым 2м байтам этих данных.
грубый пример (на который конечно же ругнеться компилятор)
record
size:dword;
data:array[0..size-2] of byte;
end;

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

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

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

запутано ? - перечитай.

в таком случае ничего учитывать не прийдеться, все будет учтено в сокетном енджине в котором "склейка" и "разбивка" пакетов идет после вызова PreDecrypt

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

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

зы. только сейчас заметил что не закомитил последний невксор.дпр на свн.. пардон.. исправил -)

[nezabudkin]

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

alexteam, чтобы тебе были более понятны эти проблемы, я кратенько опишу с какими защитами я сталкивался, и где пакетхак пасовал.

Неразу мне не попадалось, чтобы на ЛС-сервере были какие-то навороты, и чтобы они потом влияли на ГС. А вот в шифровании ГС встречалось следующее:
1. Измененный пакет ProtocolVersion от клиента, где вместо статического набора цифр, идет начальный ключ, да еще в нестандартном понимании, например какая-нибудь здоровенная таблица.
2. Измененный пакет KeyPacket от сервера, все тоже что и в п.1 + он уже бывает зашифрован.
3. Измененный пакет AuthLogin от клиента, содержаший доплнительные ключи шифрования, после прихода которого, включался дополнительный криптер, и алгоритм шифрования менялся напроч.
4. Наложение большой статической маски на весь трафик между сервером и клиентом, например генератором псевдослучайных чисел, либо просто из массива-константы.
5. Что характерно, нигде не видел чтобы шифровались байты длинны пакета, но исключать такую возможность нельзя.
6. Были еще вообще нестандартные пакеты в самом начале соединения с ГС.

Вот как-то так. К примеру в wpf ВЕСЬ трафик пропускается через скрипт шифрации-дешифрации который легко можно корректировать, вот только скрипты там медленные.

[alexteam]

пх с лс и не работает...

Причина, почему не получалось на пакетхаке - костлявость newxor и вызывающих ее процедур.

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

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

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

[alexteam]

TXorCodingOut. TXorCoding ТОЧНО такой же.
объявление

TXorCodingOut = class(TCodingClass)
private
DecAccumulatorSize, EncAccumulatorSize : integer;
DecAccumulator, EncAccumulator : array [0..$ffff] of byte;
public
constructor Create;
procedure InitKey(const XorKey; Interlude: Boolean = False);override;
procedure DecryptGP(var Data; var Size: Word); override;
procedure EncryptGP(var Data; var Size: Word); override;
procedure PreDecrypt(var Data; var Size: Word); override;
procedure PostEncrypt(var Data; var Size: Word); override;
end;

реализация:

constructor TXorCodingOut.Create;
begin
EncAccumulatorSize := 0;
DecAccumulatorSize := 0;
end;

procedure TXorCodingOut.DecryptGP(var Data; var Size: Word);
begin
//EncryptGP, если он не реализован в YourEncryptFuncton.
end;

procedure TXorCodingOut.EncryptGP(var Data; var Size: Word);
begin
//EncryptGP, если он не реализован в YourDecryptFuncton.
end;

procedure TXorCodingOut.InitKey(const XorKey; Interlude: Boolean);
begin
//иниткей, стандартный если нужен
end;

procedure TXorCodingOut.PreDecrypt(var Data; var Size: Word);
procedure YourDecryptFuncton(var Packet:TPacket);
begin
//сюда поступает пакетик который необходимо декриптовать.
//если ты захочешь сразу преобразовать его в декриптованный линейковский пакет
//то decryptgp оставляй пустым
//если же это поверхносный навесок на криптовку - рекомендую "раздельное питание"
end;

var
L2Packet : TPacket; //обьявлен в шаредструктуре
OutBuffer : array[0..$ffff] of byte;
begin
//client>>[PreDecrypt]>DecryptGP>(PH)>EncryptGP>PostEncrypt>>server
//выходящий буффер - пуст.
fillchar(OutBuffer, $ffff, 0);

//Суем в аккумулятор то что пришло.
move(data,DecAccumulator,size);
inc(DecAccumulatorSize, Size);

Size := 0; //выход обнуляем не давая пакетхаку эту поцию обработать если на следующей проверке
//мы вылетим с этой функции либо не попадем в цикл (это и есть склейка пакетов. когда длина линейковского пакета
//меньше фактически полученных данных. мы будем ждать копя данные в аккумуляторе)

if DecAccumulatorSize < 2 then exit; //в аккумуляторе нет даже длинны.


//в акумуляторе есть чтото по длинне превышающей либо равной 2м байтам. читаем их как размер пакета
move(DecAccumulator[0], L2Packet.Size, 2);

//!если криптуеться весь траффик включая ДЛИННУ пакетов - в этом месте декриптовать L2Packet.Size!

while (L2Packet.Size <= DecAccumulatorSize) do
//Резка пакетов в этом вайле
//будем крутиться тут пока нам будет хватать фактических данных для обслуживания длинн линейковских пакетов.
begin
//подчистим дату пакета, дабы не мусор не смущал при отладке.
fillchar(l2packet.data[0], $FFFD, 0);
//вытягиваем с акумулятора данные пакета.
move(DecAccumulator[0], L2Packet.data[0], L2Packet.Size-2);
//сдвигаем батики в акумуляторе на эту же длинну, затирая считаный с аккумулятора пакет
move(DecAccumulator[L2Packet.Size], DecAccumulator[0], DecAccumulatorSize-L2Packet.Size);
//и умельшаем длинну акумулятора
dec(DecAccumulatorSize, L2Packet.Size);
//Декриптуем
YourDecryptFuncton(L2Packet);
//декриптованный пакет суем в временный выходящий буффер (он нужен только потому что нельзя мовнуть в data[xxx])
move(L2Packet, OutBuffer[Size], L2Packet.Size);
//и увеличиваем колво байт в выходящем буфере
inc(Size, L2Packet.Size);
//Режем следующий пакет
if DecAccumulatorSize >= 2 then
begin
move(DecAccumulator[0], L2Packet.Size, 2);
//декрипт длинны ?
end
else
break;
end;

//сливаем данные с временного буфера в выход буффер
move(OutBuffer[0], data, $ffff);

end;



procedure TXorCodingOut.PostEncrypt(var Data; var Size: Word);
//в общем точная копия декрипта, только екрипт. а так все на тех же местах.

procedure YourEncryptFuncton(var Packet:TPacket);
begin
//аналоично YourDeacryptFuncton но наоборот.

end;

var
L2Packet : TPacket;
OutBuffer : array[0..$ffff] of byte;
begin
fillchar(OutBuffer, $ffff, 0);
move(data,EncAccumulator,size);
inc(EncAccumulatorSize, Size);
Size := 0;
if EncAccumulatorSize < 2 then exit;
move(EncAccumulator[0], L2Packet.Size, 2);
while (L2Packet.Size <= EncAccumulatorSize) do
begin
fillchar(l2packet.data[0], $FFFD, 0);
move(EncAccumulator[0], L2Packet.data[0], L2Packet.Size-2);
move(EncAccumulator[L2Packet.Size], EncAccumulator[0], EncAccumulatorSize-L2Packet.Size);
dec(EncAccumulatorSize, L2Packet.Size);
YourEncryptFuncton(L2Packet);
move(L2Packet, OutBuffer[Size], L2Packet.Size);
inc(Size, L2Packet.Size);
if EncAccumulatorSize >= 2 then
begin
move(EncAccumulator[0], L2Packet.Size, 2);
end
else
break;
end;
move(OutBuffer[0], data, $ffff);
end;

[nezabudkin]

Ух ты, прикольно получилось. Долго бы я парился все это выдумывать. Спасибо! Надо будет затестить!
После теста это нужно будет выложить в отдельную тему, а то здесь оно потеряется :)

[alexteam]

главное чтобы идею понял -) и понял куда ему чего прикручивать..
к стати.. ничего выдумывать не надо. Точно такое же в сокетном енджине крутиться.... ну практически -)

Добавлено через 8 минут
блин, глянул еще раз, разрезку пакетов забыл добавить. поправил.

[nezabudkin]

блин, глянул еще раз, разрезку пакетов забыл добавить. поправил.

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

[alexteam]

пардон, исправил... к стати.. мог бы и сам...
я просто вчера чуть чуть подумал, и убрал необходимость декодировать длинну пакета повторно (если декодирование требуется) -))


move(EncAccumulator[2], L2Packet.data[0], L2Packet.Size-2);
move(DecAccumulator[2], L2Packet.data[0], L2Packet.Size-2);

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

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

Добавлено через 18 минут
кстати, возми на заметку.
если у тебя кодируються и первые 2 байта пакета, при чем от их декодирования зависит и ключ(чи по чем оно там криптоваться будет) то следует:

после вот такого
move(DecAccumulator[0], L2Packet.Size, 2);
декриптовать длинну лежащую в L2Packet.Size НО НЕ изменять ключ (если он меняеться)
при чем учти что только в PreDecrypt это требуеться. в постенкрипт поступающие от пх данные идут в фармате 2 первых байта = длинна.

такие вот места
move(ХХХAccumulator[2], L2Packet.data[0], L2Packet.Size-2);

заменить на
move(ХХХAccumulator[0], L2Packet, L2Packet.Size);

а в процедурах YourDecryptFuncton/YourEncryptFuncton
ПОВТОРНО декритовать/криптовать кусок данных вместе с L2Packet.Size при чем уже с изменением ключа.

[nezabudkin]

Еще ошибка. При обработке пакетов от сервера. Доходит до определенного места и заклинивает, но только в одну сторону. От клиента все обрабатывается нормально. Дважды проверял, зависает при приходе UserInfo. Прикладываю log, rawlog пакетов и исходник newxor. Все тесты провожу на сервере mks.

[alexteam]

да, есть проблема, щас попытаюсь обнаружить.

Добавлено через 13 минут
move(data,ХХХAccumulator[ХХХAccumulatorSize],size);
было
move(data,ХХХAccumulator,size);
что равносильно
move(data,ХХХAccumulator[0],size);

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

Добавлено через 2 минуты
кстати, закомитил его на свн.

[nezabudkin]

alexteam, где-то есть еще баг, всеравно рано или поздно newxor виснет :( Такое ощущение, что при приходе большого пакета от сервера.

А где в пакетхаке такой же алгоритм реализован, в каком модуле?

[alexteam]

alexteam, где-то есть еще баг, всеравно рано или поздно newxor виснет Такое ощущение, что при приходе большого пакета от сервера.
да нет, в ньюксор сейчас, именно сейчас код нормальный.
скорей всего из за пх. перекачай.

зы. usocketengine.pas

[alexteam]

nezabudkin,
там, эта, в енк/декГп
вот такое обявленнице
pck:array[0..$4FFF] of Byte absolute Data;
на воттакое
pck:array[0..$FFFD] of Byte absolute Data;
поменяй ?...

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

[nezabudkin]

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

[alexteam]

мм, если подумать

//Сколько еще в буфере ?!
ioctlsocket(thisTunel.serversocket, FIONREAD, Longint(BytesInStack));
if BytesInStack = 0 then
BytesInStack := 1;

presize := recv(thisTunel.serversocket, PreAccumulator[0], BytesInStack, 0);//Читаем 1 байт или весь буффер сразу
LastResult := PreSize;

if lastresult > 0 then
begin
ioctlsocket(thisTunel.serversocket, FIONREAD, Longint(BytesInStack));
if BytesInStack > 0 then //Дочитываем
LastResult := LastResult + recv(thisTunel.serversocket, PreAccumulator[presize], BytesInStack, 0);
end;

если подряд приходит 2 порции данных суммарным объемом БОЛЕЕ чем 63кб. кусок данных после 63кб отсекается, и как следствие - клиент просто обязан "повиснуть", да и в сокетном движке будет происходить чертешо.
щас попытаюсь такую ситуацию учесть.

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