Шифрование данных и протокол C3/C4: как это работает в MU онлайн

Автор STINGER, 2015 Апр. 24, 19:46

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

Ключевые слова [SEO] mu онлайншифрование данныхпротокол c3/c4

STINGER

Всем привет.

Вот уже какой день изучаю сетевой уровень и не могу не как понять как же происходит шифрование,
а следовательно и дешифрование данных, которые ходят в пакетах (C3/C4) по сети в направлении от
клиента к серверу. Также не совсем понятен и сам протокол. Судя по тому, что я смог нарыть - 1й байт
отвечает за тип(C1,C2,C3,C4), второй за размер пакета (в случае C2 и C4, как я понял ещё и 3й),
а следующие два отвечают за опкод, по которому можно определить какой именно это пакет.
Вопрос - откуда начинаются шифрованные данные, ну и почему опкод байты приходят всегда разные,
хотя пакет всегда один и тот же (C3. пакет авторизации с данными о логине и пароле),
а в случае с пакетами на получение списка серверов и информации о конкретном (C1) такого нет.

Собственно, нужна помощь с этим. Может кто подскажет информацию? Спасибо.

P.S Клиент s6ep3

DoS.Ninja

#1
Помоему что 6с, что 4с один и тот же формат шифрования и пакетов. Ты можешь открыть любой эмулятор да посмотреть всё что надо, правда зачастую сам алгоритм шифрования в исходниках идёт в качестве импортируемой библиотеки .lib, но есть и исходник. Что касается шифрования то там используется калечный самопальный алгоритм ассиметричного шифра который уже похакан давно. Я уже точно не помню, но вроде в шифрованном пакете под шифр не попадают только тип и размер, следовательно разные байты "опкода" обьясняются тем что они пошифрованы.

У меня в репозитории есть кое какие старые работы с пакетами и шифрованием, если интересно можешь глянуть (ссылка в подписи)

STINGER

Цитата: DoS.Ninja от 2015 Апр. 25, 14:28  Я уже точно не помню, но вроде в шифрованном пакете под шифр не попадают только тип и размер, следовательно разные байты "опкода" обьясняются тем что они пошифрованы.

Дело в том, что если я ввожу один и тот же логин, то и байты опкода прежние.
Стоит вводить другие данные, то и байты меняются. Вот чего я и не могу понять.
Быть может опкод в данном пакете это совсем другие байты?

Цитата: DoS.Ninja от 2015 Апр. 25, 14:28  Ты можешь открыть любой эмулятор да посмотреть всё что надо...

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

Да вот как раз сейчас нашел в исходниках, но что-то всё как-то очень грустно...
Может он и калечный, но понять ту ерунду, которая написана в исходниках этих эмуляторов очень сложно <_<
Наверное, надеяться на то, что кто-то расжует алгоритм будет слишком наивно?  :rolleyes:

DoS.Ninja

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

STINGER

for (int i = start; i != end; i += inc)
buf[i] ^= _auth_key[i % 32] ^ buf[i - 1];

Также нашел в zClient.dll (либа от zTeam) подобный алгоритм:
for( int i = StartPos; i < Size; i++ )
{
Data[i] ^= Data[i - 1] ^ gCheatGuard.XOR[i%32];
}
Так то вроде всё понятно, но в их серверной части, а также серверной части других найденных мною эмуляторов
слишком много кода для такой простой шифрации. Если я не ошибаюсь, то алгоритм расшифровки XOR такой же как
и шифровки? Т.е повторная операция ^ на тот же байт и мы получаем исходное значение.
Быть может я что-то упускаю?

То как это понял я:
Берём массив байт, который пришел нам по сети от самого начала и до конца (размер указан во 2м байте).
Далее бежим по нему вышеописанным циклом начиная с конца заголовка, т.е начиная с 3 байта в массиве.
Но вот что-то, на выходе у меня получается ерунда... 3 и 4 байты не как не равны 0xF1 и 0x01
Массив байт для шифрования, по идее, соответствует клиентскому (брал с рабочего сервера), также пробовал
и байты от zTeam(они подменяют в клиенте на свои и их я же и указывал на сервере)

DoS.Ninja

Нет обычным ксором нельзя расшифровать такой пакет. Я же сказал что пакет авторизации накрыт 3мя шифрами. Берётся первоначально пакет содержаший логин и пароль, затем логин и пароль шифруются каждый сам по себе ксором (см. bux_convert). Затем весь пакет кроме 3х байт заголовка шифруются другим ксором (см. auth_encrypt). А потом уже всё это шифруется основным ассиметричным шифром, вот статья в которой я когда-то немного описал на каком матане это работает. Другие пакеты C3C4 шифруются только ассиметричным шифром.

STINGER

Во. Спасибо большое, теперь хоть что-то становится на свои места и понятно почему там так много кода)
Будем изучать  

STINGER

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

SmallHabit

Можно, и легко. Но смотри - просто так не обойдёшь. И даже шифрование которое обошли, задержит 98% маленьких читеров.

Похожие темы (5)