freepascal.ru

тогда пример - зачем взялись за разработку l2jserver, зачем возиться с бинарным протоколом?

не совсем корректный пример
сложность написания клиентов очень отличается

Гм... Отвечу просто - "а шоб було"(c).

остается тогда сказать - "флаг в руки и барабан на шею"

В команде 4 человека + я, т. е. всего 5.

могу только добавить, что чат легко может написать 1 человек за месяц особо не напрягаясь
а вот удастся ли 5 разобраться с протоколом да еще и с жатием и шифрованием - большой вопрос....

ev писал(а):а вот удастся ли 5 разобраться с протоколом да еще и с жатием и шифрованием - большой вопрос....

Кстати насчет сжатия, разработчиком использован класс TZLib

The TZlib class is a C++Builder wrapper for the ​"zlib" compression library. TZlib can be used to compress or decompress any of the ​descendants of TStream such as TFileStream or TBlobStream.....

Вот...
http://fgzzzy.narod.ru/vcl/compress/tzlib.zip

На счет шифрования колупаюсь...

Мертвая зона

а точнее?

ev писал(а):а точнее?

Я про тему)

Дополняю:
Оригинальный пакет (черный)
Измененный пакет (красный)

D6 1F 00 00 6C 7B 7B 03 7D 7E 7E B4 87 B3 B3 B4 85 86 87 88 89 8A 8B 8D 84 C3 FD BE B1 D1 FB FD F0 F0 97
D6 1F 00 00 6C 7B 7B 03 7D 7E 7E B4 87 00 B3 B4 00 00 00 00 00 00 8B 8D 84 C3 FD BE B1 D1 FB FD F0 F0 97

Я подозреваю что данный пакет несет в себе список пользователей (подключенных в данный момент к чату). По характеристикам CommFort, там содержится Ник, IP, MAC-адрес и пол... (Хотя не факт что еще разработчику в голову пришло туда впереть).... Так, отошел от сути данного поста. Вообщем по идеи оригинальным МАС-адресом есть значение 00-00-00-00-00-00, но забив (просто меткое попадание пару значений заметил искажения в значении. Так вот, забив данные шести позиций значением #0 получил в значении мак-адреса -> 85 86 87 88 89 8A - что уже интересно если всмотреться в оригинальный пакет.
Подозреваю что используется простейшее шифрование текста через "исключающее или" (xor), но вот по какому принципу...

Может у кого-то в голове посвежее? У кого какие мысли по этому поводу?


-----P.S.
Длина тела данного пакета = 1Fh (31 байт)
Анализируем:
В чате 1 клиент;
Информация о клиенте:
- IP: "127.0.0.1" (возможно 4 байта по двум вариантам)
- MAC: "00-00-00-00-00-00" (выяснили, что поле равно 6 байтам)
- Ник - "Mr. Chief" (8 байт длина строки + допускаем еще один байт как значение длины строки, всего 9)
- Пол - "М" (допустим 1 байт)
Не забываем про количество пользователей (значение данного поля возможно равно 2 байтам - dw, т.к. существует ограничение подключений до 4000 клиентов, да и дизассемблер показал массив пределом которого является 4000 элементов-указателей на наследника класса TCustomServerSocket).

Так что получилось? 1 + 2 + 4 + 6 + 9 = 22 байта... А всего то их 31...........

Так...

А если попробовать наложить xor-маску?
79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97

Сейчас попробуем


Добавлено

Ооооооо. Прогресс пошел .
Получил выходные данные:
15 01 00 7F 00 00 01 34 06 31 30 30 00 00 00 00 00 00 00 01 09 4D 72 2E 20 43 68 69 65 66 00
А это уже истина, в ASCII выглядит вот так (приблизительно):

Код: Выделить всё

§☺ ⌂  ☺4♠100       ☺    Mr. Chief

Ну вот в итоге получаем:
15 01 00 7F 00 00 01 34 06 31 30 30 00 00 00 00 00 00 00 01 09 4D 72 2E 20 43 68 69 65 66 00

Где: UsersCount, IP, MAC, Nick
00 01 либо 00 - предположительно пол (в первом случаем 1 или 2 соответственно М или Ж, во втором 0 или 1 соответственно.


----P.S.
Последний блок содержит данные о каналах: конструктивный подход такой же... Сейчас попробую по полученной теории раскодировать весь пакет подключения.

Так пока с этой стороны будем копать.

Теперь нужно разобраться каким образом сжимаются блоки данных в пакетах (ZLib):

Оригинальный:
D6 2A 00 00 1D 21 18 13 14 70 48 19 1C 74 7B 72 72 65 82 1E 32 21 CF DC F6 E0 F7 F5 E6 EB E4 EE 0C FC E0 E1 F1 E8 F7 FE FC F0 B7 F3 35 9D

Дешифрованный (нет гарантии что метод работает):
D6 2A 00 00 64 5B 63 6F 69 0E 37 99 9D F6 F8 F6 F7 E3 05 96 BB AB 44 50 7B 6E 78 65 77 79 77 7A 99 6A 77 79 68 72 6C 62 61 6E 28 53 94 3F

В данном сообщение содержится:
[2:30:22] Mr. Chief (10.0.0.101): ТЕСТОВОЕ СООБЩЕНИЕ
Как точно кодируется еще неизвестно.

Я про тему)

это было предсказуемо и озвучено

ev писал(а):это было предсказуемо и озвучено

Как минимум статья по анализу протоколов точно получится .

Да... Совсем забыл... Соответственно если будет известна спецификация протокола, то можно конечно задуматься о портировании клиента под различные платформы (например для платформы WinCE и MIDP 2.0[Java]).

Сабж : hxxp://www.commfort.com/rus/forum/viewtopic.php?t=1316

Чисто из любопытства : а подробности?

глупости какие-то =)
в общем в очередной раз была взболомучена вода и оппа.

ну а поставьте себя на место автора
он зарабатывает деньги на этом, поэтому как только узнал провел беседу

не уверен, что закон на стороне автора
но вот внести изменения в протокол он может легко - запаришься расшифровывать потом

ev писал(а):но вот внести изменения в протокол он может легко - запаришься расшифровывать потом

Бессмысленно ковыряться в 3 версии протокола, т. к. в скором времени выходит 4 версия.

А вообще, т. к. это никого не заинтересовало, опять же тратить свое время не собираюсь по пусту. Все любят готовое, вот и все...