Просмотр полной версии : Непонятный алгоритм смены ID исходящих пакетов
Обращаюсь к знатокам, есть сервер t\h\e\o\n\l\i\n\e на нем после недавнего времени обновили защиту, суть защиты в следующем: Все исходящие пакеты с клиента идущие на гейм сервер (за исключением первого пакета ProtocolVersion и пакета CharacterSelect) имеют ID не соответствующий им по описанию протокола. ID пакетов меняются динамически после реконекта к гейм серверу. Возникает ощущение что сервер передает какой-либо код, который складывается с настоящим ID пакета. Кто может подсказать варианты обхода данной защиты? Защита реализована в самом клиенте, без использования стороннего ПО, пакеты с гейм сервера идут как обычно со стандартными ID "внутринности" исходящих пакетов расшифровываются нормально, загадкой остается только ID. Для наглядности выкладываю один из логов пакетов, пакеты уже расшифрованы.
ProtocolVersion
0E 53 00 00 00 09 07 54 56 03 09 0B 01 07 02 54 54 56 07 00 02 55 56 00 51 00 53 57 04 07 55 08 54 01 07 01 53 00 56 55 56 01 06 05 04 51 03 08 51 08 51 56 04 54 06 55 08 02 09 51 56 01 53 06 55 04 53 00 56 56 53 01 09 02 09 01 51 54 51 09 55 56 09 03 04 07 05 55 04 06 55 04 06 09 04 51 01 08 08 06 05 52 06 04 01 07 54 03 06 52 55 06 55 55 51 01 02 04 54 03 55 54 01 57 51 55 05 52 05 54 07 51 51 55 07 02 53 53 00 52 05 52 07 01 54 00 03 05 05 08 06 05 05 06 03 00 0D 08 01 07 09 03 51 03 07 53 09 51 06 07 54 0A 50 56 02 52 04 05 55 51 02 53 00 08 54 04 52 56 06 02 09 00 08 03 53 56 01 05 00 55 06 08 56 04 0D 06 07 52 06 07 04 0A 06 01 04 54 04 00 05 02 04 54 00 09 52 53 05 04 01 04 05 05 01 52 51 52 0D 06 51 08 09 54 53 00 0D 01 02 03 54 53 01 05 03 08 56 54 07 02 54 0B 06 11 5D 1F 60
KeyPacket
2E 01 3B 15 8E 49 C9 14 9C A3 01 00 00 00 05 00 00 00 00 67 87 FA 6A
AuthLogin (тут странности начинаются, ID пакета RequestAllyInfo)
2E 4D 00 61 00 6C 00 6F 00 6A 00 53 00 6F 00 6E 00 67 00 00 00 F5 26 01 00 B2 FC 00 00 F5 26 01 00 2E 34 F5 34 08 00 00 00 00 40 06 3F EA 69 00 00
CharSelectionInfo
09 01 00 00 00 07 00 00 00 00 4A 00 75 00 6C 00 69 00 00 00 EA D3 00 00 4D 00 61 00 6C 00 6F 00 6A 00 53 00 6F 00 6E 00 67 00 00 00 F5 26 01 00 78 03 00 00 00 00 00 00 01 00 00 00 01 00 00 00 15 00 00 00 01 00 00 00 78 45 01 00 71 42 02 00 B8 F2 FF FF 0A D7 A3 70 BD 42 A6 40 71 3D 0A D7 A3 FE 8B 40 88 7A 04 00 45 FE 2C 05 00 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6F 09 00 00 94 22 00 00 A1 02 00 00 52 16 00 00 48 09 00 00 4B 09 00 00 62 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 0A D7 A3 70 BD 42 A6 40 71 3D 0A D7 A3 FE 8B 40 00 00 00 00 15 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
CharacterSelect (странно но ID пакета верный)
12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SSQInfo
73 02 01
CharacterSelect (еще 1 пакет выбора чара....)
12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CharSelected
0B 4A 00 75 00 6C 00 69 00 00 00 EA D3 00 00 00 00 F5 26 01 00 78 03 00 00 00 00 00 00 01 00 00 00 01 00 00 00 15 00 00 00 01 00 00 00 78 45 01 00 71 42 02 00 B8 F2 FF FF 0A D7 A3 70 BD 42 A6 40 71 3D 0A D7 A3 FE 8B 40 88 7A 04 00 45 FE 2C 05 00 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00 23 00 00 00 24 00 00 00 17 00 00 00 0E 00 00 00 1A 00 00 00 47 03 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 B6 AC 1D
AllyDismiss (RequestManorList) (с этого пакета и далее полная ахинея с ID в скобках указан действительный ID)
8F 0C 00
AllyDismiss (????)
8F 3F 00
Вобщем такая подмена ID продолжается в течении всей сессии, в течении сессии ID на которые подменяются стандартные ID для одинаковых пакетов идентичны.
Добавлено через 9 минут
Заметил еще одну особенность, переподключаться к гейм серверу нет необходимости, достаточно сделать релогин до окна выбора персонажа. Забыл указать, сервер грация финал.
Тоже ковыряюсь над данной защитой. Чонить придумаем. На АЧ вроде бы есть бот под новую защиту, но под хайдом 150. Говорят ломается защита максимум час. Но это видимо те, у кого есть опыт работы с протоколом линейки
Добавлено через 37 минут
Еще ключ спрятан в пакете CharSelected, в самом конце. В обычной шифрации там стоят нули. А здесь последние 4 байта постоянно меняются. Видимо защита построена на этом. НО! В пакете KeyPacket все равно есть какойто ключ и от него тоже зависит чтото.
хех, эт стандартная фишка на офах, ключ и в KeyPacket и в CharSelected вы правильно увидели, что с этим ключем делать можно увидеть в сорцах пакетхака, ну а чтоб всё норм дешифровывалось надо прост включить в пакетхаке галочку "Gracia (off server) (устарело на l2.ru)"
ЗЫ кстати почему алекс там написал что устарело на l2.ru я хз, эт всё ещё актуально для офов
Спасибо! Заглянул в исходник и испугался, там такая аццкая процедурка. Будем разбираться.
С включенной опцией оффГрация правильно стал расшифровываться пакет AuthLogin, но после пакета от сервака CharSelected шифрация опять меняется.
xkor, в двух словах не получится рассказать про этот алгоритм?
alexteam
25.04.2010, 15:44
в стандартной комплектации - неактуально )
xkor большое спасибо за то что наставил на путь истинный =) Буду ковырять. На днях выложу "фиксер" чтоб можно было запускать ботов и тому подобные фигню =)
Не смог понять алгоритма нифига там =) А на этом сервере возможно немного переделаный алгоритм. Но не понимая сути основного алгоритма, переделать будет почти невозможно.
Добавлено через 1 минуту
xkor большое спасибо за то что наставил на путь истинный =) Буду ковырять. На днях выложу "фиксер" чтоб можно было запускать ботов и тому подобные фигню =)
Фиксер - это скрипт? =) Или софтина какая то?
Хочу в отдельную софтинку вынести. Сейчас разбираюсь с алгоритмом что и как там делается. Если xkor конечно распишет с комментами будет многим проще.
Добавлено через 4 минуты
На счет переделанного алгоритма, ога, переделали, но теперь хотя пакет AuthLogin дешифровывается нормально, думаю дальше дело техники, понять что изменили.
Хочу в отдельную софтинку вынести. Сейчас разбираюсь с алгоритмом что и как там делается. Если xkor конечно распишет с комментами будет многим проще.
Добавлено через 4 минуты
На счет переделанного алгоритма, ога, переделали, но теперь хотя пакет AuthLogin дешифровывается нормально, думаю дальше дело техники, понять что изменили.
Хотелось бы в виде скрипта в лпх или впф. Да и более универсально будет это.
Я думаю поделишься алгоритмом, если получится разгадать его? ;)
Сам щас тож сижу ковыряюсь в алгоритме, поподробней бы комментарии, а то не всегда доходит почему именно так, а не по другому. Например цикл от 0 до $D0... долго ломал голову, пока не догадался заглянуть в описания пакетов, и не догнал что это ИД. Канечно, может для кого то это и очевидно:)
Случаем не понял откуда берется seed? :)
Случаем не понял откуда берется seed? :)
Входящий параметр функции:
procedure _init_tables(seed: integer; _2_byte_size: integer);.
Передается я так понял число, которое берется из пакета KeyPacket (последние 4 байта пакета) и из пакета CharSelected (размер пакета-3).
Это не 100% утверждение, может я что-то не так понял.
TCorrectorData = packed record
_seed : integer; // random generator seed for mixing id tables
_1_byte_table : string;
_2_byte_table : string;
_2_byte_table_size: integer;
_id_mix : boolean;
temp_seed : integer;
protocol: integer;
end;
Вот где это все прячется
Добавлено через 6 минут
Мне показалось или пакет CharacterSelect от клиента не шифруется вообще?
Оп пропустил, сейчас посмотрел, например если вызов идет от KeyPacket то seed является 16й байт в пакете.
CharacterSelect не шифруется вобще.
Добавлено через 1 минуту
xkor спасай нас, а то наши мосги лопнут пытаясь понять логику работы данной функции. если можно то хотяб пару строчек коментов к функции либо словестно алгоритм ее работы. Заранее спасибо.
Вот как я понял работает функция коректора:
Формируются 2 массива байтов, один для одноИДшных пакетов и второй для 2хИДешных пакетов.
Формируются массивы так:
сначала тупо заполняются байтами от 0 до $D0, а после, по ниипическому закону меняются местами байты, причем байты выбираются по какому-то псевдо рандому, по всей видимости тоже ниипическому ))
Расшифровка ИД происходит так:
Берем ИД оригинального пакета, прибавляем 1, получаем номер байта в массиве, который подставляется вместо оригинального ИД.
Это как я понял. Даже если это и так, то я не представляю что можно поменять, чтобы пакеты норм пакетхаком распознавались.
Добавлено через 12 минут
Все, на сеня хватит головоломок. Подождем ответа ксора, мб подскажет чего интересного... у него опыт в этом деле поболее будет ;)
по ниипическому закону меняются местами байты, причем байты выбираются по какому-то псевдо рандому, по всей видимости тоже ниипическому ))
Рандом не псефдо эпический всему есть объяснение, например вот глянь...
function _pseudo_rand: integer;
var
a : integer;
begin
with CorrectorData^ do begin
a := (Int64(_seed) * $343fd + $269EC3) and $FFFFFFFF;
_seed := a;
result := (_seed shr $10) and $7FFF;
end;
end;
pseudo_srand(seed);
for i := 2 to $D1 do begin
rand_pos := (_pseudo_rand mod i) + 1;
x := _1_byte_table[rand_pos];
_1_byte_table[rand_pos] := _1_byte_table[i];
_1_byte_table[i] := x;
end;
:confused:
Это я видел, я просто говорю что непонятно почему именно так и почему именно такие числа и действия.
Как вот могли разгадать такую шифрацию? Или просто ктото слил из разработчиков
Asmoday, я этот алгоритм переписал со скрипта для wpf, как ктот написал тот скрипт я хз, но на вид алгоритм должен спокойно проглядываться в дизасемблере...
ЗЫ псевдорандом кстати стандартный Сишный)
Добавлено через 1 минуту
CharacterSelect не шифруется вобще.вообще эт чтоль даж ксором?
ЗЫ без изменений клиента алгоритм поменять точно не могли...
ЗЫ без изменений клиента алгоритм поменять точно не могли...
Да, говорят было обновление клиента, появились некоторые файлы.
ПС: этот сервер очень напоминает шок, такие же лаги сосок, такие же внезапные рестарты, может быть 2 рестарта подряд...
Вот думаю там начать играть, но пока не будет бота, даже суваться туда не буду. А так сервачок веселый, не вялый
xkor, случам скриптика на wpf не осталось? Не охото изобретать велосипед...
Asmoday, гдето в инете остался наверняка, corrector он назывался вроде
xkor, случам скриптика на wpf не осталось? Не охото изобретать велосипед...
Вот, у мну он был почему то в стандартной поставке... почти копия кода в лпх.
толи таблицы формируются другим алгоритмом, толи выборка из них идет другим способом. Хз как проверить. Но нетПинг и ЧарактерСелект не меняют своего ИД.
Добавлено через 4 минуты
cur_pos := Pos(#$12, _1_byte_table);
x := GInt(_1_byte_table, $13, 1);
PInt(_1_byte_table, $12, $13, 1);
PInt(_1_byte_table, x, cur_pos, 1);
cur_pos := Pos(#$B1, _1_byte_table);
x := GInt(_1_byte_table, $B2, 1);
PInt(_1_byte_table, $B1, $B2, 1);
PInt(_1_byte_table, x, cur_pos, 1);
Вот тута ИД нетПинга ($B1) и ЧарактерСелект($12) встают на свои места.
Добавлено через 4 минуты
А может они вообще функцию псевдорандома поменяли?:confused:
Надо посмотреть и попробывать, а за архивчик спасиб =)
Спасите мой мозг, какой из байтов пакета 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 байта. Не шарю зачем он нужен, но может просто поксорить их..
if(buff[3]=#$2e)then begin
//if(Protocol = 871)or(Protocol = 12)then _init_tables(PInteger(@buff[$16])^, $58); // CT2.2
//if(Protocol = 851)or(Protocol = 19)then _init_tables(PInteger(@buff[$16])^, $55); // CT2
//if Protocol = 831 then _init_tables(PInteger(@buff[$16])^, $4E); // CT1.5+
_init_tables(PInteger(@buff[$16])^, $80);
Obfuscation Key - это сид ГСЧ для составления таблиц DES(или каких там) по которым кодируются ID пакетов. buff[$16] - это он?
Добавлено через 3 часа 43 минуты
Получается что алгоритм корректора повторён в пакхаке, использует оба сида. Что ж ему не нравится..
Писал человеку, который знает этот алгоритм. Он дал подсказку: надо что-то сделать в ключом, чтобы его использовать. С каким из двух ключей надо что-то делать не сказал. Но, с первым, тот что их КейПакета ничего делать не надо,с ним все в порядке. Надо что-то делать с ключем из ЧарактерСелект
Я так понимаю, что скорее всего для того чтоб получить тот необходимый ключ строка должна выглядеть примерно так
temp_seed:=PInteger(@buff[PWord(@buff[1])^-3])^+$XXX;
где $XXX является константой. Повторюсь, что это лишь мои домыслы.
Добавлено через 4 минуты
guplen, не помнишь де на аллчитерсе темка про этот серв? Я находил как-то, счас чет не получается. Там месага была под хайдом 150 сообщений. Думаю может попросить скинуть на мыло.
Asmoday, вот тема http://allcheats.ru/t141726/
Идея тут такая. Отключаем корректор для всех пакетов после $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 минуты
Собственно, я бы эту лабуду тут и не писал бы, если б сам мог проверить. Но столкнулся с проблемой - если в _decode_ID начинаем отфильтровывать только отдельные пакеты ($0B и $12) то отваливаемся от сервера. Почему?? Разве ПХ изменяет поток пакетов клиент->сервер?
Спасибо.
Собственно потому, что, но сколько я понял алгоритм работы корректора, срабатывать (или не срабатывать) должны процедуры декоде и инкоде соответственно.
Т.е. либо необходимо отключать и инкоде и декоде либо вобще сделать как написал выше.Сейчас к сожелению практически нет времени разбираться с шифрованием, если кинешь код своего алгоритма магу проверить =)
Добавлено через 2 минуты
Кстати можно просто сделать с 1 нормального конекта рав-лог (с выключенной процедурой корректора) и затем уже с ним работать.
А зачем вобще использовать корректор для первых двух пакетов?
если кинешь код своего алгоритма магу проверить
потому что это одна строчка =) (та что закоменченная)
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
декоде и инкоде соответственно
Да, оказалось что это так. Опасненько, надо сказать. Было бы логичней шифровать только пакеты, вносимые/изменяемые скриптами. А всё что идёт от клиента пропускать без изменений.
Про рав-лог хорошая идея.
Опасненько, надо сказать.
Ничего подобного, за то "на входе" ты имеешь чистый, раскодированный, расшифрованный трафик, и задумываться о "выходе" тож не нужно, составил пакет->отправил пакет. При любом другом варианте работы было бы слохно писать некоторые скрипты (например, те, которые контролируют наличие/отсутствие итемов в рюкзаке) приходилось бы явно указывать что пакет необходимо обработать, что вызывало бы лишние траблы.
B1 B6 09 66 - 66 09 B6 B1 - 1711912625 - keyPacket
E0 90 E3 7B - 7B E3 90 E0 - 2078511328 - charSelected
E3 75 E3 FB - FB E3 75 E3 - 4225988067 - real
KeyPaket - ключ взятый из одноименного пакета
charSelected - ключ из charSelected
real - сбрученый ключик, который использует клиент для шифрации.
Вот нужно найти зависимость между последними двумя ключами, то есть как из charSelected получить real ключ.
ПС: первый столбец копипаст из лпх, второй - байты в правильном порядке, третий - число в 10ной системе.
У кого какие идеи?
Добавлено через 2 минуты
Отвечу сразу на вопрос почему нельзя достать сразу много пар ключей:
поиск одного ключа занял около 4 часов. Сейчас начну брутить еще одну пару ключей.
Добавлено через 52 минуты
Если человек не соврал, то используются только всякие ксоры, энды, сдвиги и прочая нечисть.
guplen, ну по одной паре можно предположить только ксор 0x8000E503 (посчитал в уме так что возможно E - неверно, остальные символы очевидны)
Так и есть, переписал лпх, теперь пакеты норм распознает... осталось запустить ИГ и ОГ ботов. С ИГ фигня какая то.
Добавлено через 1 час 16 минут
Был ник длиной 5 символов, с длиной ника в 13 символов эта система не работает.
Ну теперь мы знаем что у нас для шифрования используется ксор ключика. Счас потестирую что получится.
E3 75 E3 FB - FB E3 75 E3 - 4225988067 - real
как вычислил?) функцию на брут писать лень, если не сложно кинь исходник, счас попытаюсь добить.
Добавлено через 27 минут
По поводу ботов... PH коректирует пакеты только внутри себя. то есть под ботов придется под wpf писать скрипт, но зная алгоритм это не проблема.
Добавлено через 1 час 4 минуты
Укажи длину пакета charSelected с которого брутил ключи, а лучше если не жалкой дай свой рав лог. Кажется появились некоторые домыслы.
Известен алгоритм шифрации, известен начальный пакет, известен зашифрованный этим алгоритмом пакет. Нужно найти ключ. Ключ изменяется в пределах 0-FFFFFFFF. Тупым перебором шифруем начальный пакет (его ИД) известным алгоритмом, с каждым из 4 миллиардов ключей, сравнивая и зашифрованным пакетом.
Скрипт для впф есть. Он тоже работает с длиной ника в 5 символов. Хотя там предусмотрена зависимость от длины. Скорей всего ключ ксорится на разные значения, которые зависят от длины ника, а возможно еще и титула.
Вот скрипт для впф, там 1 строка добавлена всего:
http://www.multiupload.com/WOCESJG1CQ
Добавлено через 7 часов 10 минут
Для длинны ника 13 символов, ключ нужно ксорить на 8000F9C4.
Итог:
8000E503 - длина ника 5
8000F9C4 - длина ника 13
по ходу дело не в длине ника, потому как сейчас создал там чара с ником Anumi (5 символов), пробую ксорить на $8000E503 но вываливается полная ахинея. видимо тот самый дополнительный ключ генерируется из ника персонажа. отпиши с какими никами пробывал делать, может получится найти зависимость. А лучше бы увидеть пакет charSelected возможно зависит не от ника, а допустим от ObjID чара.
Добавлено через 7 минут
Алгоритм почти раскрыт, длинна ника тут нипричом, через минут 20 будет думаю рабочий вариант)
Добавлено через 4 минуты
Алгоритм шифрования пакетов раскрыт, за тем как и что обращаемся в личку. Сделано с целью нераспространения инфы подобного характера. guplen, xkor, вам уже отправил.
xkor, вам уже отправил.что, куда и зачем?)
xkor, мб удалить темку? Будут спрашивать всегда можно отписать какой алгоритм. Просто боюсь что сменят шифрование.
Не, удалять не надо, это что-то вроде темы "ДЕШИФРУЕМ ТРАФИК", только здесь все гораздо проще. Окончательного ответа тут нет. А те кто хоть чуть разбирается, все сам поймет.
Данный метод актуален для рпг клаба?
Там вроде тоже самое с ид и пакетами... спс, вроде немного прояснилось
Данный метод актуален для рпг клаба?
Там вроде тоже самое с ид и пакетами... спс, вроде немного прояснилось с их горе "защитой"
Ага, вроде бы там такая же защита стоит. То есть сначала на рпг поставили, а уже после на онлайн.
мой мозХ перегрелся ), под хлап этот скрипт можно адаптировать? т.к. я смотрю у хлапа отсутствует ряд функций от вфп.
В скрипте участвует длина ника, но выше вы писали, что это не важно, запутался.
real - сбрученый ключик, который использует клиент для шифрации.
Не совсем понял как ты его получил, функцией коректора?
----
Файлик корректора, только для л2пнх есть у кого?
Сам нашел тут (http://l2phx.pp.ru/wsvn/filedetails.php?repname=l2phx3&path=%2F3.5.x%2Funits%2Fuencdec.pas)
Спасибо! если кому интересно, на Lua это будет выглядеть так:
function _init_tables(seed, _2byte_size)
local i = 0
local x = 0
local rand_pos = 0
local cur_pos = 0
local _1_byte_table = ''
local _2_byte_table = ''
local _2_byte_table_size = _2byte_size
for i = 0, 0xD0, 1 do
_1_byte_table = _1_byte_table..string.char(i)
end
for i = 0, _2byte_size, 1 do
_2_byte_table = _2_byte_table..string.char(i,0)
end
math.randomseed(seed)
for i = 2, 0xD1 do
rand_pos = (math.random(0, 0x7FFF) % i) + 1
x = GInt(_1_byte_table, rand_pos, 1)
_1_byte_table = PInt(_1_byte_table, GInt(_1_byte_table, i, 1), rand_pos, 1)
_1_byte_table = PInt(_1_byte_table, x, i, 1)
end
cur_pos = 3
for i = 2, _2byte_size+1 do
rand_pos = (math.random(0, 0x7FFF) % i)
x = GInt(_2_byte_table, rand_pos * 2 + 1, 2)
_2_byte_table = PInt(_2_byte_table, GInt(_2_byte_table, cur_pos, 2), rand_pos * 2 + 1, 2)
_2_byte_table = PInt(_2_byte_table, x, cur_pos, 2)
cur_pos = cur_pos + 2
end
local idx = _1_byte_table:find(string.char(0x12))
if idx == nil then
idx = 0
end
cur_pos = idx
x = GInt(_1_byte_table, 0x13, 1)
_1_byte_table = PInt(_1_byte_table, 0x12, 0x13, 1)
_1_byte_table = PInt(_1_byte_table, x, cur_pos, 1)
local idx = _1_byte_table:find(string.char(0xB1))
if idx == nil then
idx = 0
end
cur_pos = idx
x = GInt(_1_byte_table, 0xB2, 1)
_1_byte_table = PInt(_1_byte_table, 0xB1, 0xB2, 1)
_1_byte_table = PInt(_1_byte_table, x, cur_pos, 1)
end
где GInt и PInt нагло содрано из WP саурона, остальное стандартные либы.
можно и красивей конечно, но я туповат и ленив)
p.s. При использовании сишной rand (в Lua это math.rand)
складывать 0x80000000 с сами_знаете_чем не надо
(помоему это свзяано с тем, что сишная не использует int64
при генерировании рнд.числа)
p.p.s. _2byte_size передавать побольше чем 0x58 (так по скрипту)
т.к. в Т2.3 этих(0xD0 aka Ex) пакетов прибавилось... пруфлинк -
_ttp://www.l2jserver.com/svn/branches/L2_GameServer_T2.3/java/net/sf/l2j/gameserver/network/L2GamePacketHandler.java
+ флудят подключениями. ;(
(долго дуплил почему соединение ВНЕЗАПНО разрывается)
защита примерн так выглядит:
local _allow_connection = true -- Connection's flooding protection
-- ================================================== ==========================
--
function L2EstablishConnection(ID, ip, port)
-- L2.theonline.ru x13 Game server
if ip == "188.72.217.14" and port == "7777" and _allow_connection == true then
_allow_connection = false
.....................
end
return ip, port
end
--
-- ================================================== ==========================
--
function L2CloseConnection(ID)
if ID == TargetServerID and _allow_connection == false then
_allow_connection = true
.....................
end
end
--
нужна помощь по пакетнику в отношении рпг-клаб.
в их отношении нужна ли newxor.dll для обхода их шифрации ?
у них очень уж заумная защита, пакеты идут левые и постонянно новые после релогина даже через выбора через чара.
почитал форум все тоже самое что описывалось выше, флуд подключениями ключ real и т.д.
Можете объяснить что куда и зачем.
B1 B6 09 66 - 66 09 B6 B1 - 1711912625 - keyPacket
E0 90 E3 7B - 7B E3 90 E0 - 2078511328 - charSelected
E3 75 E3 FB - FB E3 75 E3 - 4225988067 - real
vBulletin® v3.6.11, Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot