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

[alexteam]

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

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

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

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

да. именно так.
то что пришло надо обработать и подсунуть пх для последующей обработки с помошью декриптгп т.е.

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

[nezabudkin]

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

сокетный движек получает часть данных с стека
отправляет эту часть в 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]

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

кстати, довольно просто это и в ньюксор предусмотреть, тот же временный буфер, в который суеться все что приходит в 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 байта шифруються