Вернуться   CoderX :: Forums > Lineage II > L2PacketHack > Скриптинг > Шифрации серверов
Войти через OpenID

Шифрации серверов Здесь разбираемся с алгоритмами шифрации различных серверов

Чат (Новых сообщений с момента вашего последнего визита нет)
Загрузка...
Задавайте ваши вопросы на форуме. Чат предназначен для небольших разговоров.
 
Ответ
 
Опции темы Опции просмотра
Старый 05.10.2009, 22:16   #11
Рыцарь
 
Аватар для alexteam
 
Регистрация: 07.03.2009
Сообщений: 9,139
Сказал Спасибо: 70
Имеет 2,820 спасибок в 1,735 сообщенях
alexteam на пути к лучшему
По умолчанию

Цитата:
[*] newxor сможет менять длинну пакета.
Ктрл+клик на tcoddingclass
там явно видно что const стал var

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

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

Последний раз редактировалось alexteam, 05.10.2009 в 22:16. Причина: Добавлено сообщение
alexteam вне форума   Ответить с цитированием
За это сообщение alexteam нажился 2 спасибками от:
Старый 06.10.2009, 00:16   #12
Местный
 
Аватар для nezabudkin
 
Регистрация: 06.03.2008
Сообщений: 154
Сказал Спасибо: 46
Имеет 130 спасибок в 38 сообщенях
nezabudkin
По умолчанию

Цитата:
Сообщение от alexteam Посмотреть сообщение
сокетный движек получает часть данных с стека
отправляет эту часть в DecryptTRAFFICK (при чем следует учесть что частью траффика может быть и полпакета такие случаи очень редки но исключать их нельзя, у меня за это аккумулятор в пх отвечает, а тут прийдеться без него)
а можно чуть по подробнее, в каких таких случаях может прийти только часть пакета, и как это определить что пакет не полный?
nezabudkin вне форума   Ответить с цитированием
Старый 06.10.2009, 00:28   #13
Рыцарь
 
Аватар для alexteam
 
Регистрация: 07.03.2009
Сообщений: 9,139
Сказал Спасибо: 70
Имеет 2,820 спасибок в 1,735 сообщенях
alexteam на пути к лучшему
По умолчанию

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

в принципе определить полный пакет пришел или нет ты сможешь по мере его (пакета) декриптовке, ориентируясь на полученную длинну пакета идущую первыми 2мя байтами.
если данных будет недостаточно - просто декриптованую часть сунуть в акумулятор, обнулить пакет и ждать оставшуюся часть пакета идущую в следующем PreDecrypt.
__________________
L2Ext - project closed.
alexteam вне форума   Ответить с цитированием
Старый 06.10.2009, 00:29   #14
Admin!
 
Аватар для xkor
 
Регистрация: 04.08.2007
Сообщений: 2,360
Сказал Спасибо: 113
Имеет 1,566 спасибок в 651 сообщенях
xkor на пути к лучшему
По умолчанию

nezabudkin, в случаях большой нагрузки на серв или канал или ещё чего ибо протокол TCP потоковый и заботится только о том чтобы данные приходили полностью, в правильном порядке, но разбивать их на порции может как угодно при необходимости, а определять что пакет пришел в одной порции не полный смысла нет ибо работать надо с потоком извлекая из него пакеты по мере поступления исходя из их размера в первых двух байтах...
__________________
Я здесь практически не появляюсь!, Skype - ikskor
xkor вне форума   Ответить с цитированием
Старый 06.10.2009, 01:16   #15
Местный
 
Аватар для nezabudkin
 
Регистрация: 06.03.2008
Сообщений: 154
Сказал Спасибо: 46
Имеет 130 спасибок в 38 сообщенях
nezabudkin
По умолчанию

alexteam, а что за бонус в версии 3.5.25.145 под названием Xorruoff.dll ?
nezabudkin вне форума   Ответить с цитированием
Старый 06.10.2009, 12:01   #16
Рыцарь
 
Аватар для alexteam
 
Регистрация: 07.03.2009
Сообщений: 9,139
Сказал Спасибо: 70
Имеет 2,820 спасибок в 1,735 сообщенях
alexteam на пути к лучшему
По умолчанию

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


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

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

Последний раз редактировалось alexteam, 06.10.2009 в 12:02. Причина: Добавлено сообщение
alexteam вне форума   Ответить с цитированием
Старый 06.10.2009, 12:12   #17
Местный
 
Аватар для nezabudkin
 
Регистрация: 06.03.2008
Сообщений: 154
Сказал Спасибо: 46
Имеет 130 спасибок в 38 сообщенях
nezabudkin
По умолчанию

Цитата:
Сообщение от alexteam Посмотреть сообщение
кстати, довольно просто это и в ньюксор предусмотреть, тот же временный буфер, в который суеться все что приходит в PreDecrypt
alexteam, xkor, может вы тогда это реализуете в newxor, вы ведь уже на этом "собаку съели", или хотя бы пример выложите как реализовать сборку пакета в единое целое. А то мне придется такой лес там городить...
nezabudkin вне форума   Ответить с цитированием
Старый 06.10.2009, 12:39   #18
Рыцарь
 
Аватар для alexteam
 
Регистрация: 07.03.2009
Сообщений: 9,139
Сказал Спасибо: 70
Имеет 2,820 спасибок в 1,735 сообщенях
alexteam на пути к лучшему
По умолчанию

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


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

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

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

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

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

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

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

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

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

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

Последний раз редактировалось alexteam, 06.10.2009 в 19:52.
alexteam вне форума   Ответить с цитированием
За это сообщение alexteam нажился 2 спасибками от:
Старый 06.10.2009, 20:14   #19
Местный
 
Аватар для nezabudkin
 
Регистрация: 06.03.2008
Сообщений: 154
Сказал Спасибо: 46
Имеет 130 спасибок в 38 сообщенях
nezabudkin
По умолчанию

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

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

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

Вот как-то так. К примеру в wpf ВЕСЬ трафик пропускается через скрипт шифрации-дешифрации который легко можно корректировать, вот только скрипты там медленные.
nezabudkin вне форума   Ответить с цитированием
За это сообщение nezabudkin нажился спасибкой от:
Старый 06.10.2009, 20:27   #20
Рыцарь
 
Аватар для alexteam
 
Регистрация: 07.03.2009
Сообщений: 9,139
Сказал Спасибо: 70
Имеет 2,820 спасибок в 1,735 сообщенях
alexteam на пути к лучшему
По умолчанию

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

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

Цитата:
5. Что характерно, нигде не видел чтобы шифровались байты длинны пакета, но исключать такую возможность нельзя.
если первые 2 байта не затрагиваються - все вообще просто как в сказке.
щас нарисую простенький пример, думаю сам поймешь что нужно сделать в случае если 1е 2 байта шифруються
__________________
L2Ext - project closed.

Последний раз редактировалось alexteam, 06.10.2009 в 21:04.
alexteam вне форума   Ответить с цитированием
Ответ

  CoderX :: Forums > Lineage II > L2PacketHack > Скриптинг > Шифрации серверов



Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 21:59.

vBulletin style designed by MSC Team.
Powered by vBulletin® Version 3.6.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Locations of visitors to this page
Rambler's Top100

Вы хотите чувствовать себя в безопасности? чоп Белган обеспечит её!