толи таблицы формируются другим алгоритмом, толи выборка из них идет другим способом. Хз как проверить. Но нетПинг и ЧарактерСелект не меняют своего ИД.
Спасите мой мозг, какой из байтов пакета OB использует этот код (исходник инициализации корректора из л2пх)
Код:
with CorrectorData^ do if FromServer then begin
if _id_mix and(buff[3]=#$0b)then begin
temp_seed:=PInteger(@buff[PWord(@buff[1])^-3])^;
_init_tables(temp_seed,_2_byte_table_size);
end;
//xkor: последние 4 байта)
Сходство Obfuscation Key из Key Packet и нашего мистического ключа из CharacterSelected - они оба 4 байта. Не шарю зачем он нужен, но может просто поксорить их..
Писал человеку, который знает этот алгоритм. Он дал подсказку: надо что-то сделать в ключом, чтобы его использовать. С каким из двух ключей надо что-то делать не сказал. Но, с первым, тот что их КейПакета ничего делать не надо,с ним все в порядке. Надо что-то делать с ключем из ЧарактерСелект
где $XXX является константой. Повторюсь, что это лишь мои домыслы.
Добавлено через 4 минуты guplen, не помнишь де на аллчитерсе темка про этот серв? Я находил как-то, счас чет не получается. Там месага была под хайдом 150 сообщений. Думаю может попросить скинуть на мыло.
Последний раз редактировалось Asmoday, 29.04.2010 в 10:59.
Причина: Добавлено сообщение
Идея тут такая. Отключаем корректор для всех пакетов после $0B. Из расшифрованного $0B запоминаем Key. Логинимся, тыкаем в кнопки(посылаем пакет $Х) и ждём пока придёт пакет (зашифрованный клиентом но нерасшифрованный нами) $01(movebacktolocation). Теперь смотрим в алгоритм корректора - table1[$02] = $X, т.е. при генерации таблицы в первой($02) ячейке лежит пакет $Х(мы его знаем, т.к. помним какую кнопку жали)
Итого имеем соответствие:
Код:
$X = ((Int64(_seed) * $343fd + $269EC3) and $FFFFFFFF) shr $10) and $7FFF;
то что справа это 1ая генерация псевдоГСЧ, лежащая в первой ячейке таблицы.
Дальше ищем соответствие Key и seed. Если это соответствие линейно (+$XXX), то все неизвестные найдутся на раз.
Собственно, я бы эту лабуду тут и не писал бы, если б сам мог проверить. Но столкнулся с проблемой - если в _decode_ID начинаем отфильтровывать только отдельные пакеты ($0B и $12) то отваливаемся от сервера. Почему?? Разве ПХ изменяет поток пакетов клиент->сервер?
А зачем вобще использовать корректор для первых двух пакетов? Во всех пакетах изменяется только ID, все данные остаются неизменны. Т.е. кей ты можешь и "ручками" запомнить из пакета 0B.
Добавлено через 4 минуты
Цитата:
Сообщение от aSproot
Собственно, я бы эту лабуду тут и не писал бы, если б сам мог проверить. Но столкнулся с проблемой - если в _decode_ID начинаем отфильтровывать только отдельные пакеты ($0B и $12) то отваливаемся от сервера. Почему?? Разве ПХ изменяет поток пакетов клиент->сервер?
Спасибо.
Собственно потому, что, но сколько я понял алгоритм работы корректора, срабатывать (или не срабатывать) должны процедуры декоде и инкоде соответственно.
Т.е. либо необходимо отключать и инкоде и декоде либо вобще сделать как написал выше.Сейчас к сожелению практически нет времени разбираться с шифрованием, если кинешь код своего алгоритма магу проверить =)
Добавлено через 2 минуты
Кстати можно просто сделать с 1 нормального конекта рав-лог (с выключенной процедурой корректора) и затем уже с ним работать.
Последний раз редактировалось Asmoday, 30.04.2010 в 00:41.
Причина: Добавлено сообщение
А зачем вобще использовать корректор для первых двух пакетов?
если кинешь код своего алгоритма магу проверить
потому что это одна строчка =) (та что закоменченная)
Код:
procedure _decode_ID;
begin
with CorrectorData^ do begin
//if (_1_byte_table[Byte(buff[3])+1] = #$2B) or (_1_byte_table[Byte(buff[3])+1] = #$12) then begin
buff[3]:=_1_byte_table[Byte(buff[3])+1];
if buff[3] = #$D0 then begin
Цитата:
декоде и инкоде соответственно
Да, оказалось что это так. Опасненько, надо сказать. Было бы логичней шифровать только пакеты, вносимые/изменяемые скриптами. А всё что идёт от клиента пропускать без изменений.