Моя борьба с шифрованием

[Warstar]

Привет всем. Под новый год не сидится на месте, решил углубится и разгадать тайну алгоритма шифрования некого сервера. Данное желание возникло после прочтения темы VORONа, за что ему отдельное спасибо. И так, упуская название сервера, хотел бы начать...
После запуска l2phx v.3.5.34.176 и подключения к серверу (использовал LSP-перехват соединения) убегаю в отдаленное место, усаживаюсь, и начинаю юзать Wind Strike (id 1177, насколько я знаю). После усиленного спама мышко-кликов по скиллу, вижу следующий результат...


047A457BD53B27E4400D007FC7C4719E9D4CBCE247F8 <<<
0368AB7ED53B27E4400B00C0B5588BE36B83728A
039FB17ED53B27E44003005D
045DBF87D53B27E4400D00F57AC4CCC808799B825361
038FF88BD53B27E4400B00194FF33175962FDE04
038FF88BD53B27E44003007E
04E94693D53B27E4400D001DCCA4889E7F045222856B
033D1598D53B27E4400B0091F504CCC85BAF35D5
033D1598D53B27E44003004C
04816D9CD53B27E4400D00A3B19125E36BC84289F8B0
035710A1D53B27E4400B002508D87048D1048F45
038D16A1D53B27E44003006D
042C2EA2D53B27E4400D00672EECEC1D35AE4B88AED0
03F15AA6D53B27E4400B0080F5588BE36BC372E2
03F15AA6D53B27E44003005D
04B9ABA6D53B27E4400D00413A75742B244C79AB13D0
040156AAD53B27E4400D0005EC9DD5C8962CCFA0A5B0
030F23ABD53B27E4400B00194FF33175962FDE5C
030F23ABD53B27E44003007E
044757AED53B27E4400D001773A4C79E2B2C72EB5885
037F8BB1D53B27E4400B0091F5C4CCC89BAF35FD
037F8BB1D53B27E44003004C
045752B2D53B27E4400D007FC7C4719E9D4CBC8A47F8 <<<
038F86B5D53B27E4400B002508D87048D1048F6D
038F86B5D53B27E440030035
04E721B6D53B27E4400D00F57AC4CCC808799BFA5361
03E94FB9D53B27E4400B00C0B5588BE36B83723A
03E94FB9D53B27E44003005D
04083CBAD53B27E4400D001DCCA4889E7F04524A856B
03D363BDD53B27E4400B00194FF33115962FBEB4
030A6ABDD53B27E44003007E
04839ABED53B27E4400D00A3B19125E36BC84221F8B0
0317BCC1D53B27E4400B0091F564CCC83BAF3505
034EC2C1D53B27E44003004C
0449C7C2D53B27E4400D00672EECEC1D35AE4B30AED0
0313EFC5D53B27E4400B006508D83048D1048FF5
0313EFC5D53B27E44003003D
049F3EC7D53B27E4400D00413A75742B244C797313D0
03D772CAD53B27E4400B00C0B5588BE36B837212
030E79CAD53B27E44003005D
041F98CAD53B27E4400D0005EC9DD5C8962CCF48A5B0
0321C6CDD53B27E4400B00194FF331D5962F7E8C
0321C6CDD53B27E44003007E
049AF6CED53B27E4400D001773A4C79E2B2C72135885
03D32AD2D53B27E4400B0091F564CCC83BAF352D
03D32AD2D53B27E44003004C
04028DD3D53B27E4400D007FC7C4719E9D4CBC5247F8 <<<
03DFD3D6D53B27E4400B002508D87048D1048FDD
03DFD3D6D53B27E440030045
044A37D7D53B27E4400D00F57AC4CCC808799B525361
03F077DAD53B27E4400B00C0B5588BE36B83726A
03F077DAD53B27E44003005D
04EA7CDBD53B27E4400D001DCCA4889E7F0452F2856B
0359B7DED53B27E4400B00194FF33175962FDEE4
0359B7DED53B27E44003007E
04317EDFD53B27E4400D00A3B19125E36BC84279F8B0
03D6BEE2D53B27E4400B0091F544CCC81BAF3575
03D6BEE2D53B27E44003004C
04BFA4E3D53B27E4400D00672EECEC1D35AE4B58AED0
039CEBE6D53B27E4400B002508D87048D1048FE5
039CEBE6D53B27E44003008D
0485D1E7D53B27E4400D00413A75742B244C791B13D0
03BD05EBD53B27E4400B000075588BE36B437242
03BD05EBD53B27E44003005D
042869EBD53B27E4400D0005EC9DD5C8962CCF10A5B0
03619DEED53B27E4400B00194FF33175962FDE3C
03619DEED53B27E44003007E
048232EFD53B27E4400D001773A4C79E2B2C72BB5785
038460F2D53B27E4400B0091F504CCC85BAF359D
038460F2D53B27E44003004C
04597EF3D53B27E4400D007FC7C4719E9D4CBCFA48F8 <<<
035BACF6D53B27E4400B002508D87048D1048F0D
035BACF6D53B27E440030055
048CB7F7D53B27E4400D00F57AC4CCC808799B8A5C61
03C4EBFAD53B27E4400B00C0B5588BE36B83729A
03C4EBFAD53B27E44003005D
0488EAFBD53B27E4400D001DCCA4889E7F04521A8A6B
036431FFD53B27E4400B00194FF33155962FFE14
036431FFD53B27E44003007E
04F12900D63B27E4400D00A3B19125E36BC84291F7B0
03F35703D63B27E4400B0091F564CCC83BAF35A5
03F35703D63B27E44003004C
045B6904D63B27E4400D00672EECEC1D35AE4B80A1D0
03939D07D63B27E4400B00E508D8B048D1048F95
03939D07D63B27E44003005D
0432B508D63B27E4400D00413A75742B244C79A31CD0
03A1EF0BD63B27E4400B00C0B5588BE36B8372F2
03A1EF0BD63B27E44003005D
04C0DB0CD63B27E4400D0005EC9DD5C8962CCFB8AAB0
039D2210D63B27E4400B00194FF33115962FBE6C
039D2210D63B27E44003007E
04CE2D11D63B27E4400D001773A4C79E2B2C72E35785
03066214D63B27E4400B0091F564CCC83BAF35CD
03066214D63B27E44003004C
04B94115D63B27E4400D007FC7C4719E9D4CBC8248F8 <<<
03399B18D63B27E4400B002508D87048D1048F7D
03399B18D63B27E440030065
04D8B219D63B27E4400D00F57AC4CCC808799BE25C61
0347ED1CD63B27E4400B00C0B5588BE36B8372CA
0347ED1CD63B27E44003005D
041EB41DD63B27E4400D001DCCA4889E7F0452428A6B
0356E820D63B27E4400B00194FF33175962FDE44
0356E820D63B27E44003007E
044F4422D63B27E4400D00A3B19125E36BC84229F7B0
03877825D63B27E4400B0091F584CCC8DBAF3515
03877825D63B27E44003004C
04F13226D63B27E4400D00672EECEC1D35AE4B28A1D0
03977329D63B27E4400B002508D87048D1048F85
03977329D63B27E44003002D
04B8082AD63B27E4400D00413A75742B244C794B1CD0
035E492DD63B27E4400B0080F5588BE36BC37222
035E492DD63B27E44003005D
04472F2ED63B27E4400D0005EC9DD5C8962CCF40AAB0
03237631D63B27E4400B00194FF33175962FDE9C
035A7C31D63B27E44003007E
04C43632D63B27E4400D001773A4C79E2B2C720B5785
03337135D63B27E4400B0091F544CCC81BAF353D
03337135D63B27E44003004C
041C5736D63B27E4400D007FC7C4719E9D4CBC2A48F8 <<<
038B9139D63B27E4400B002508D87048D1048FAD
038B9139D63B27E440030075
0404C23AD63B27E4400D00F57AC4CCC808799B5A5C61
03AA023ED63B27E4400B00C0B5588BE36B83727A
03E1083ED63B27E44003005D
0493E83ED63B27E4400D001DCCA4889E7F0452EA8A6B
03392942D63B27E4400B00194FF33195962F3EF4
03392942D63B27E44003007E

Из вышеуказанного лога я увидел, что через каждые 8 пакетов они повторяются (отмечено <<<), но повторяются с изменением - 9-й байт данных меняется!

Подумав над этим, я проанализировал, и предположил последовательность в изменении... Визуально это выглядит так:

E2(hex) 226(dec) +168 (разница)
8A 138 +200 (при условии, что граничная константа == 256)
52 82 +168
FA 250 +136 (здесь произошел инкремент 10-го байта)
82 130 +168
2A 42

Здесь явно есть некая закономерность. А с этого момента прошу помочь с разгадкой тайны + поясните, что за часть пакета вот это:
045DBF87D53B27E4400D00F57AC4CCC808799B825361
т.к. в соответствие визуальных данных в программе ее же логам еще не совсем понял.

Пока займусь логами с большим количеством циклов...

Добавлено через 1 час 26 минут
Немного поправлюсь... Была выключена галочка "Не дешифровать трафик"... Включил. Начал спамить пакеты на разрыв пати. Вроде как однобайтовый, но пакетхак перехватывает пакеты по 2 байта... Почему?

[wimax]

изначально трафик уже шифруется (стандартная шифрация )когда выключаешь галочку "Не дешифровать трафик" то дишефратор не используеца

[Warstar]

если используется шифрование, отличное от стандартного, то по сути я должен не дешифровать пакеты методами л2пнх... Дабы не коверкать показания... Верно?

Добавлено через 3 минуты
и так, выключив программный дешифратор, задача нахождения алгоритма облегчилась - 9й байт пакета (без заголовков) не меняется после цикла в 8 пакетов. Выходит, что пакеты шифруются 8-ю ключами, принцип получения которых буду искать исходя из первичного в KeyInit

[wimax]

Warstar, верно а дальше уже ищи сам бог те в помощь)))
с нг кстатия)

[Warstar]

Спасибо! И тебя с новым годом!

Добавлено через 50 минут
Ребят интересует почему при отправке пакетов на разрыв пати, якобы однобайтовых, л2пнх показывает:
0F 6F
4B 7F
E3 63
B8 45
8A 8B
DF 9B
55 61
1F 7F

[S@nderS]

Спасибо! И тебя с новым годом!

Добавлено через 50 минут
Ребят интересует почему при отправке пакетов на разрыв пати, якобы однобайтовых, л2пнх показывает:
0F 6F
4B 7F
E3 63
B8 45
8A 8B
DF 9B
55 61
1F 7F

Дёрнул пати. Вот результат:

2B

Что не так?

[Warstar]

Дёрнул пати. Вот результат:

2B

Что не так?

Почему мой пнх показывает 2 байта?

Добавлено через 3 часа 10 минут
меня вдруг посетила идея - скорее всего используется не xor и его усложненное использование в алгоритме, так как он не меняет размер данных. А у меня размер пакета увеличен...

[wildamd]

это при просмотре чистого трафика увеличивается размер пакета?
перепроверь этот момент :) с точки зрения оптимизации это просто не рационально.. (гонять лишний трафик).
а вообще - поверх xor'а может использоваться простая архивация, всем извесно что размер упакованных данных иногда больше оригинала. (ну это как вариант, предположение :) ).

[Warstar]

и я о том же... трафик по любому первичный - не дешифрованный. Но 2 байта вместо одного удивляют... Сегодня вечером перепроверю еще раз конечно же, но это странно

Добавлено через 5 минут
а смысл использовать архивацию? доп. нагрузка на вычислители, да и вроде ж не сверхсекретные данные, чтобы так пакеты накрывать, тем более с такими последствиями. Добавление одного байта характерно для всех пакетов от клиента и от сервера - то есть не зависит от длины пакета, следственно, надеюсь, добавляет его исключительно алгоритм шифрования. Это упростит задачу.

Добавлено через 2 минуты
хммм... А может этот байт - ключ к догадкам? Так как цикл разнообразия = 8 пакетам, потом все повторяется - можно отсверлить эти последние байты, сложить, и получить некую последовательность из 8 байт? :) Фантазия конечно, но все же ...

Добавлено через 2 часа 51 минуту
Ребят, дайте кто-то оригинальный вид пакета: надпись в белый чат: 00000000000000000000 (20 нолей).

[Mulder]

Какие хроники то хоть? )

[Warstar]

хроники ХФ п5

Добавлено через 1 час 35 минут
исследую далее... Определил, спамом say2 пакетов, что шифрование на сервере 128bit. Ключи вырисовались сами собой. Их, как и ранее 8. Осталось определить каким образом образуется лишний байт в каждом пакете, и можно приступать к алгоритму шифрования.

[Mulder]

Выложи пожалуйста лог спама однобайтовыми пакетами штук на 30.

[Warstar]

пара минут...

Добавлено через 7 минут
C7 E7
CB 63
90 45
A2 D5
8E 0F
10 30
5D 58
42 47
78 58
CB 63
90 45
A2 D5
8E 34
10 30
5D 58
42 47
78 58
CB 63
90 45
A2 D5
8E 0F
10 30
5D 58
42 47
78 58
CB 63
90 45
A2 D5
8E 34
10 30
5D 58
42 47
78 58
CB 63
90 45
A2 D5
8E 0F
10 30
5D 58
42 47
78 58
CB 63
90 45
пожалуйста.

Добавлено через 3 часа 34 минуты
проанализировав большой список пакетов 0x49 (say2) пришел к выводу, что исходящий трафик зависит от входящего. Для дальнейших рассуждений мне требуется информация - воспринимает ли клиент несколько раз присланный KeyInit? такое впечатление, что существуют циклы, началом которых обновление ключа из нового KeyInit, и так каждый раз через некоторое количество пакетов.

[Mulder]

Все доброе утро,

Может, кто подскажет сервер ХФ с онлайном 2 на котором работает л2пх без шифрации?

[Rivest]

Спасибо! И тебя с новым годом!

Добавлено через 50 минут
Ребят интересует почему при отправке пакетов на разрыв пати, якобы однобайтовых, л2пнх показывает:
0F 6F
4B 7F
E3 63
B8 45
8A 8B
DF 9B
55 61
1F 7F

Ты разобрался почему пакеты по размеру больше чем надо?

У меня та же ситуация, только пакеты больше на целых 4 байта. (Хроники Интерлюд)
Но это касается только исходящих пакетов, размер входящих корректный.

Разрыв пати, например, такой:
76 9B 14 1D 53 (Должен быть 1 байт: 2B - оригинальный вид)
Но отбивка приходит правильного размера:
AE 64 F2 29 2B (5 байт: 3B 00 00 00 - оригинальный вид)

Использование скила Power Strike:
76 81 40 8B 75 5B 5F 08 3D 8C 5B 09 F3 08 (Должно быть 10 байт: 2F 03 00 00 00 00 00 00 00 00 - оригинальный вид)
Отбивка, опять-таки, правильного размера:
Show Message:
F1 24 B2 69 6B 79 85 45 FC (9 байт: 64 1F 00 00 00 00 00 00 00 - оригинальный вид)
и
Action Fail:
CA (1 байт: 25 - оригинальный вид)

Еще заметил, что KeyInit на серваке, который ковыряю какой-то маленький. Пример:
00 01 44 A5 55 A5 45 CF 3D 47 01 00 00 00 01 00 00 00 (18 байт)

А KeyInit сервака со стандартным шифрованием, например, такой:
00 01 08 07 00 00 AB 06 00 00 C8 27 93 01 A1 6C 31 97 01 00 00 00 01 00 0 0 00 (26 байт)

Из-за чего исходящие пакеты имеют больший размер, чем должны быть?