Показать сообщение отдельно
Старый 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 нажился спасибкой от: