Своими проделками похвастаюсь попозже, когда руки доползут эту подделку довести до юзабилити
.Покрайней функциональный макет серверного апликейшена будет наруках и уже легче станет с проведением опытов)
CloneFort_server
Модератор: Модераторы
koi8-r, а ты действительно работы проделал много)
Своими проделками похвастаюсь попозже, когда руки доползут эту подделку довести до юзабилити.
Покрайней функциональный макет серверного апликейшена будет наруках и уже легче станет с проведением опытов)
Своими проделками похвастаюсь попозже, когда руки доползут эту подделку довести до юзабилити
.Покрайней функциональный макет серверного апликейшена будет наруках и уже легче станет с проведением опытов)
koi8-r писал(а):DWORD Reserved1; // $56723130 -> 'Vr10' <-- Это порт С КОТОРОГО данный клиент подключился к серверу ( SRC_PORT )
Странно как-то выходит, зачем использовать 4 байта если тут вполне хватило бы 2 байт... Вторые 2 байта как резерв? (хотя они не нулевые)
Добавлено спустя 4 минуты 49 секунд:
По поводу реализации, думаю, стоит вынести всю абстракцию в libcommfort.
Код: Выделить всё
T_USER_STRUCT struct
{
DWORD IP;
DWORD Reserved1; // $56723130 -> 'Vr10'
char[6] MAC;
BYTE Sex; // 0 - Male; 1 - Female
BYTE Activity; // 0 - Inactive, 1 - Active
BYTE NickLn;
char[NickLn] Nick;
// BYTE Reserved2; -> Status (;
BYTE StatusLn;
char[StatusLn] Status;
} // T_USER_STRUCT
У меня получается, что вот так:
(пакет со списком пользователей)
Код: Выделить всё
T_USER_STRUCT struct
{
DWORD src_ip;
SHORT src_port;
char[3] string; // '100'
char[6] src_mac;
BYTE sex;
BYTE activity;
BYTE nickLn;
char[nickLn] nick;
BYTE status; // На статусы не проверял, у меня здесь всегда NULL
};
Когда кто то что то пишет в каналы к которым мы подключены, сервер отправляет нам такой пакет(не помню, описывал ли ты его)
Сервер шифрует этот пакет, по моим наблюдениям, каждый раз одним и тем же ключем, тогда как при отправки НАМИ сообщений в каналы ключик меняется и похоже что там перестановки как байт внутри слов, так и целый слов(4 байта) ... Собственно реализовать ЧИТАЛКУ мейна уже можно ... (read only) так сказать =)))
Код: Выделить всё
T_ENEMY_CHANNEL_MESSAGE struct
{
SHORT M; // хз, че это, всегда == 0d 30
DWORD src_ip;
SHORT src_port;
BYTE roomNameLn;
char[roomNameLn] roomName;
char[] message; // Текст СЖАТ ! (zlib DEFAULT_COMPRESSION)
};
Когда я говорю, что ключик у этих сообщений не меняется я имею в виду, что если ВАСЯ написал в мейне N раз :kishlak:, то нам придут поочередно N T_ENEMY_CHANNEL_MESSAGE пакета от сервера, шифрованные одним и тем же ключем. У меня например ключик в одном из сеансов был
Код: Выделить всё
1) 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d
2) 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d
...
N) 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d
Что же касается МОИХ пакетов(когда я пишу в мейн) то ключик, в этом же сеансе менялся вот так:
Код: Выделить всё
2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43
2f 2e 2d 2c 33 32 31 30 37 36 35 34 3b 3a 39 38 3f 3e 3d 3c 43 42 41 43
28 29 2a 2b 34 35 36 37 30 31 32 33 3c 3d 3e 3f 38 39 3a 3b 44 45 46 43
29 28 2b 2a 35 34 37 36 31 30 33 32 3d 3c 3f 3e 39 38 3b 3a 45 44 47 43
2a 2b 28 29 36 37 34 35 32 33 30 31 3e 3f 3c 3d 3a 3b 38 39 46 47 44 43
26 27 24 25 3a 3b 38 39 3e 3f 3c 3d 32 33 30 31 36 37 34 35 4a 4b 48 43
3e 3f 3c 3d 22 23 20 21 26 27 24 25 2a 2b 28 29 2e 2f 2c 2d 52 53 50 43
43 в конце число постоянное для данной длины пакетов, думаю пока не тратить на него время.
В следующем сеансе, при том же
ИСХОДНОМ( ... 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 ...)
ключе, порядок следования байт уже при второй интерации(так же называется ?
)))) ) ,хоть и незначительно, но немного другой.Вот думайте что это ? Blowfish или какая нибудь своя разработка автора. В принципе как я говорил что касается подключиться к каналу и читать что там пишут, это реализовать уже можно. Необходимо узнать алгоритм генерации буфера ключа, точнее порядок перестановок.
Добавлено спустя 24 минуты 38 секунд:
Мне вот все та 9-11 байтовая, состоящая из цифирных ASCII символов, строка, которую клиент серверу при подключении в первом пакете передает, покоя не дает.
Все кажется, что она принимает непосредственное участие в шифровании сообщений клиента. Если удастся отловить на снифере два сеанса , в которых клиент отправит одну и ту же строку(что проблемно) и ключик будет меняться идентично, ответ очевиден -- эта строка задает порядок перестановок.
Но это все опять же предположения. Повторюсь...В дизассемблере счастье
Если попробывать это число (хранящееся в виде строки) преобразовать и пронаблюдать закономерность?!
Chief писал(а):Если попробывать это число (хранящееся в виде строки) преобразовать и пронаблюдать закономерность?!
Не получиться, так как мы не знаем как клиент шифрует сообщения, сеанс с сервером то установим, сможем читать че там пишут в каналах, а вот сами ниче не напишем.
Есть информация по 5.х версии? На оффоруме разобрали протокол, сделав клиент под Андроид. Автор чата написал, что без его помощи. Можно реверснуть этот .apk-файл, но там довольно сложно разобраться в этих сотнях .smali-файлов с непривычки.
Вверх.