Просмотр полной версии : смена пакетов поступаемых с клиента
Столкнулся со следующей проблемой.. при каждом новом запуске игрового клиента (грация финал) меняются первые 2 бита некоторых из пакетов отправляемых на сервер. Пакеты приходящие на клиент всегда остаются стандартными. Можно ли узнать по какому алгоритму клиент выбирает эти 2бита?
Подскажите пожалуйста в каком направлении копать, что можно почитать по данному вопросу?
м.б. xor первых двух байт исходящих пакетов на какую то переменную?
В самом l2phx не ставлю галочки xor и дешифровать трафик (если их ставлю пакеты не читабельные становятся...)
м.б. xor первых двух байт исходящих пакетов на какую то переменную?
Подскажите пожалуйста, где происходит правка на xor, беглый поиск по форуму не дал результатов(
Не бейте сильна).. но что такое xor вообще?.. :)
Xor используется двумя различными способами:
1. Выполняет булево или логическое 'Исключающее - или' двух логических значений. Если они различны, то результат истинен.
2. Выполняет математическое 'Исключающее - или' двух целых чисел. Результат поразрядное 'Исключающее - или' этих двух чисел. Например:
10110001 Xor 01100110 = 11010111
ЗЫ. Если снимаешь галку дешифровать трафик, естественна будет бред отображаться.
Вообще тебе много о чем прийдется почитать.... рамками сообщения хрен ограничешся.
Немного просвятившись, собрал немного данных... пакет ProtocolVersion отправляет всегда без изменений, далее получаем KeyPacket - key и ObfuscationKey при каждом новом запуске клиента разные:
2E 01 BD 3D C4 E7 CA C7 3C 28 01 00 00 00 1F 00 00 00 00 71 CF 70 30
2E 01 08 69 52 C5 15 B8 F2 4C 01 00 00 00 1F 00 00 00 00 82 55 3E 6E
2E 01 EF 40 8D DC 3E 9B 0C 05 01 00 00 00 1F 00 00 00 00 19 98 04 2A
2E 01 FF E6 26 3C 97 CC 71 47 01 00 00 00 1F 00 00 00 00 CD B5 B5 5E
2E 01 AF 5E 02 9E CD 93 2C 2D 01 00 00 00 1F 00 00 00 00 32 92 15 3C
2E 01 B0 CF C6 75 BA C4 4D 4B 01 00 00 00 1F 00 00 00 00 29 51 D3 04
, с этого момента пакеты с клиента к серверу уже имеют измененные первые 2 бита, например юзаю кристаллизацию:
79 D1 1D 3C 40 01 00 00 00 00 00 00 00
C7 BB A6 3D 40 01 00 00 00 00 00 00 00
40 CE FF 3B 40 01 00 00 00 00 00 00 00
92 35 2F 3C 40 01 00 00 00 00 00 00 00
22 3B 5A 40 40 01 00 00 00 00 00 00 00
B0 DD B2 3A 40 01 00 00 00 00 00 00 00
, а должно быть первые 2бита - 2F ... я так понимаю, ксор должен быть связан с каким то из ключей?... поправьте пожалуйста, если я не прав)
Во первых - 1 байт а не 2 бита (255=FF=11111111 - 8 бит). а во вторых - читай внимательно про шифрование - ключ ксора меняется с каждым пакетом на длину пакета. Шо за ObfuscationKey - хз, я на яве его не видел - приходят только 0, а кей с каждой сессией разный (динамически генерится) и используется в ксоре, на форуме есть обсуждение этого.
Речь про ид пакетов? если да, то уже тема поднималась.
Собрал новый невксор.. используя стандартный алгоритм со смешением на константу :
for k:=size-1 downto 1 do
pck[k]:=pck[k] xor GKeyR[k and 15] xor pck[k-1];
if size<>0 then pck[0]:=pck[0] xor GKeyR[0];
Inc(PLongWord(@GKeyR[keyLen-7])^,size);
получил тоже самое, что было раньше без использования этой библиотеки и галочки "обхода смены xor ключа", то есть по прежнему первый байт меняется. Если менять константу от 0 до 14, меняется весь пакет, становясь нечитабельным.
О чем это может говорить? :)
Добавлено через 2 часа 24 минуты
Может я не правильно понял алгоритм? Мы получаем длину пакета и ксорим по байтово на соответствуюший кусок ключа, с прибавлением константы 15 ? Не совсем понятен инкремент Inc(PLongWord(@GKeyR[keyLen-7])^,size) , @ - это же ссылка на адрес переменной GKeyR[keyLen-7]? И мы этот адрес смешаем на длину нашего пакета...
"Собрал новый невксор.. используя стандартный алгоритм" - это ничего не даст, стандартный алгоритм (исходя из ваших слов) не подходит. Этот "стандартный алгоритм" на основе которого вы создал иновый невксор уже имеется в пакетхаке. А для вашего сервера надо нестандартный.
зы: А может все будет более банально ? Галочка "Gracia off server" решит проблему...
Забавное наблюдение, если не использовать галочку "Gracia off server" второй пакет от клиента - unknown, третий пакет CharacterSelect идет нормальный. Если использовать эту галочку то второй пакет отображается - AuthLogin, например:
2B 67 00 61 00 75 00 62 00 69 00 63 00 61 00 00 00 C7 A6 01 00 88 84 00 00 C7 A6 01 00 31 61 66 70 08 00 00 00 00 C0 08 21 CC E0 00 00
2B 67 00 61 00 75 00 62 00 69 00 63 00 61 00 00 00 C7 A6 01 00 10 84 00 00 C7 A6 01 00 6C 44 9E 0E 08 00 00 00 00 C0 2E 21 3C 1D 00 00
, CharacterSelect тоже идет стандартный ( 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ), но пакеты далее к серверу по прежнему имеют первый байт другой.
Если использовать галочку "обход ксор" - это же и будет стандартный алгоритм?... он выдает совершенно неправильные пакеты, от сюда вывод моя переделка со смешением на константу 15 (хотя я до сих пор не уверен что я смешаю ее в нужном месте) имеет схожий алгоритм с искомым... Но с каким то недочетом... Хотелось бы услышать ваши мысли.
П.С Уважаемые тыкните пожалуйста меня носом в кусок кода, где реализуется опция "Gracia off server"
Если использовать галочку "обход ксор" - это же и будет стандартный алгоритм?эта галка вообще имела смысл только на С4, начиная с интерлюда она только портит)
П.С Уважаемые тыкните пожалуйста меня носом в кусок кода, где реализуется опция "Gracia off server"поверь, этот кусок кода тебе лучше не видеть, он не для слабонервных)
supernewbie
05.07.2010, 17:49
надо просто убрать галку с Грация Финал и поставить на ХБ-Камаэль)
vBulletin® v3.6.11, Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot