ДЕШИФРУЕМ ТРАФИК

А может та часть пакета которая изменяется перевести в десятичное значение и проанализировать разницу изменения пакетной суммы в десятичном значении.
Может там идет постоянное умножение на конкретное число в десятичном значении с переводом в двоичное или вообще привязано к времени, а время синхронизируется с сервером. Ы это только предположение.

Я думаю при создании алгоритма люди все таки опираются на целые десятичные цифры тем самым получая алгоритм, мы снифя трафик между серверами и клиентами видим машинный код. Хотя формулу можно и там и тут сделать, но так больше шансов на её выуживания и сравнения.

[paraped]

Сообщение от Sugar

А может та часть пакета которая изменяется перевести в десятичное значение и проанализировать разницу изменения пакетной суммы в десятичном значении.

Мы уже делали так сто раз..))

Про два ключа я просто постарался передать, какое у меня сложилось впечатление , анализируя последовательность которую ты выложил...)))

P.S. С НОВЫМ ГОДОМ.... на самом деле я щяс не способен думать, болит голова..))

[VORON]

ДРУЗЬЯ!
я вижу что никто ничего сюда не пишет нового.. хотя многие сказали такую головоломку- интересно разгодать.. видимо зашли в тупик от обилия информации.. на самом деле видно кучу закономерностей в алгоритме изменения ключа.. просто нужно над ними одновременно думать.. не упуская мелкие факты которые мы наблюдали- из виду..
я попробую обобщить наши знания.. и наверное с вашей помощью их буду дополнять.. каждый раз перепечатывая с дополнениями... так проще думать будет..
1. для шифровки и дешифровки- используется ксор на ключ..
2. ключ имеет размерность 8 байтов..
3. ключ меняется каждый раз..
4. второй байт ключа изменяется по закону: key2:=key1 xor (X+D), где Х- второй байт в расшифровке предыдушего пакета, D длинна етого пакета..
5. пунк "4" не выполняется в момент когда ксор соседних ключей меняется с (X+D) на что то другое на 1 раз ... это происходит через каждые (25 пакетов по 10 байт), (50 пакетов по 5 байт), (255 пакетов по 1 байт)..
6. смотря логи для пакетов 1, 5, 10 байтов (четных и также нечетных) мы видим что ключ в первом байте всегда чередуется "чет-нечет"..
7. для 10-ти байтных пакетов справедливо что ключ в своем младшем (правом) разряде первого байта (в 16-тиричном представлении) через 1 изменяется на 4 (что наводит об цифре 14=А+А (10+10) длинна пакета (А- это и есть 10 байтов) (2-ве длинны пакета так как через 1 пакет) ... причем мы с етим сталкиваемся не тока для 10 байтовых пакетов.. в логе данным тут в начале топа, для 1-го байтного пакета- мы видим тоже ето очень часто.
8. для однобайтового пакета ксоры двух рядом стоящих ключей (первого байта ключа- для однобайтового пакета, а выделить 8 байтов ключа никак, поетому тока 1-й байт ключа.. впринципе он нас то и интерисует больше всего)- дают очень интересную последовательность цифер.. 1 3 7 15 31 63 127 255.. ксоры двух соседних ключей дают последовательность состоящих именно из етих цифер.. которые переведя в бинарник дают 1, 11, 111, 1111, 11111, 111111 .. .. ..
9. взяв логи для пакетов 1,5,10 байтов мы видим что второй байт ключа изменит правилу описанному в пункте 4 тока через диапазон пакетов равный 25 пакетов по 10 байтов ( ну т.д. для других длинн)... но при етом на протяжении одного цикла (25 пакетов по 10 байт), (50 пакетов по 5 байт), (255 пакетов по 1 байт) никогда первый байт ключа не повторяется... 255 пакетов однобайтовых- и ключ всегда разный.. ниодного повтора... 255 раз подряд.. но на взгляд- хаос в логе - полный...


а тепеь друзья.. давайте думать.. чтодж нам ети злые админы придумали.. и каждый раз при нахожэдении новой закономерности етот пост будет перепечатываться в конец... от вас поросьба- чтоб поправить ети пункты кторорые уже есть.. на логах проверьте сами себя на разных логах.. простой пример- увидев закономерность в логе что второй байт ключа меняется на ксор 6D... - нестоит об етом даже говорить- ето справедливо тока для кокретного лога.. и не подверждается другими.. но в тоже время для етогоже пакета для другово лога верно будет что= (пункт 4 смотрите).. пунк 4 выполняется для всех логов для любого скила...

жду идей..

Ребят может я не в тему и нах меня, но у меня вопрос: Откуда клиент получает инфу о алгоритме шифровки\дешифровки? может был апдейт и добавили какой нить ДЛЛ в котором хранятся эти функции? Если так то нелегче ли его найти и разобратьса бут легча во много раз.

[Shnaider]

Сообщение от АрхиНуб

Ребят может я не в тему и нах меня, но у меня вопрос: Откуда клиент получает инфу о алгоритме шифровки\дешифровки? может был апдейт и добавили какой нить ДЛЛ в котором хранятся эти функции? Если так то нелегче ли его найти и разобратьса бут легча во много раз.

Может я дурак,но думаю так же

В продолжение своей мысли. Почти уверен в том, что шифровка/дешифровка выполняется функцией какой нить внешней библиотеки ибо если было бы иначе то пришлось бы для смены шифрации менять L2.exe. Ворон неужели небыло никакого апдейта? Неужели шифрация сменилась сама собой? Если никаких изменений небыло значит процедура шифрации та же только изменились ключи ( если ПакетХак не может расшифровать значит изменилась сама процедура)! Вот такие мысли. :unknown:

[paraped]

Сообщение от АрхиНуб

Ребят может я не в тему и нах меня, но у меня вопрос: Откуда клиент получает инфу о алгоритме шифровки\дешифровки? может был апдейт и добавили какой нить ДЛЛ в котором хранятся эти функции? Если так то нелегче ли его найти и разобратьса бут легча во много раз.

Ребят вот вы часто тут говорите что-то типа "нада найти библиотеку и разобраться в ней"....
А вы хотя бы понимаете что значит разобраться в библиотеке? Или в каком нибудь другом файле уже откомпилированой прогрммы? это на стадии создания программа выглядит как последовательность функций и различных действий с переменными, а после компиляции это машиный код 10101000101011111111101010100010001101000010101111 1001111.... И чтоб в нем разобраться нада знать ассемблер и сидеть сутками у компа, потому что 10 обращений к функциям в дельфи, или в визуал паскаль, это 1000 а может и больше различных действий на машингном уровне.... Кароче это весьма трудоемкая затея, и помойму никто из наз не сможет этого сделать, гораздо легче угать(проследить) алгорит шифрации... Если бы у нас были сорцы этого дела тогда да, но их мы конечно же не где не достанем....

Причем зачастую вдовесок код после компиляции шифруется какимнибудь CryptorExe 2.34(к примеру :))... но даже без шифрации, и например если бы кто нить из нас знал ассемблер, код мы восстановили только частично...

[VORON]

угу.. "разобраться в ДЛЛ"= ничего не сказать-)
ваще сложненькая задача.. может каму какие логи дать? скажите какие..

Добавлено спустя 10 минут 13 секунд:
Re:

Сообщение от АрхиНуб

В продолжение своей мысли. Почти уверен в том, что шифровка/дешифровка выполняется функцией какой нить внешней библиотеки ибо если было бы иначе то пришлось бы для смены шифрации менять L2.exe. Ворон неужели небыло никакого апдейта? Неужели шифрация сменилась сама собой? Если никаких изменений небыло значит процедура шифрации та же только изменились ключи ( если ПакетХак не может расшифровать значит изменилась сама процедура)! Вот такие мысли. :unknown:

конечноже был абдейт клиента...

[ChiterEPT]

Сообщение от VORON

угу.. "разобраться в ДЛЛ"= ничего не сказать-)

Согласен ребят я говорю о том о чем мало, что знаю. И действительно тут нужен знаток. Ворон еще один вопрос какие именно файлы были добавлены(изменены).

З.Ы. Вы уж извините если я совсем уж бред несу просто реально помочь хочется челу.