BSDecrypter-BLSxColetteBrawl/README.md

BS-Dec-Key: Анализ и Реализация Клиента

Этот документ предоставляет детальное техническое описание процесса подключения к серверу, который является модифицированной версией Project Colette V53, использующей криптографическую схему от BSL-V53. Здесь разбирается финальная, рабочая версия handshake, структура пакетов и логика обмена сообщениями.

[*] Основные Концепции

Протокол обмена данными является кастомным, поверх стандартного TCP. Шифрование построено на базе криптографической библиотеки NaCl и использует смешанную, нестандартную схему.

• Асимметричное шифрование: Curve25519 для вычисления общего секрета по алгоритму Диффи-Хеллмана (ECDH).
• Симметричное шифрование: XSalsa20-Poly1305 для шифрования сообщений после вычисления общего секрета.
• Порядок пакетов: В отличие от многих протоколов, здесь порядок не ClientHello -> ServerHello -> LoginMessage, а ClientHello -> LoginMessage -> ServerHello -> LoginOk.

[!] Пошаговый Разбор Процесса Подключения

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

---

Шаг 1: ClientHello (ID: 10100)

• Направление: Клиент -> Сервер
• Шифрование: Отсутствует

Это самый первый пакет, который клиент отправляет после установки TCP-соединения. Его структура критически важна и должна точно соответствовать ожиданиям сервера (6 целочисленных полей и пустая строка), иначе сервер просто разорвет соединение.

---

Шаг 2: LoginMessage (ID: 10101)

• Направление: Клиент -> Сервер
• Шифрование: Симметричное (SecretBox), но с ключом, полученным асимметрично.

Это ключевой и самый сложный пакет, который отправляется до получения ServerHello.

Подготовка на стороне клиента (перед отправкой):

1. Обмен ключами и вычисление секрета:
   • Клиент использует статичный публичный ключ сервера (server_public_key), заранее известный из анализа Frida-скрипта.
   • Клиент генерирует свою временную пару ключей (client_public_key и client_private_key).
   • Клиент вычисляет общий секрет (s) с помощью ECDH. Этот s используется только для шифрования/расшифровки LoginMessage и LoginOk.
2. Формирование Payload:
   • Клиент генерирует свой собственный RNonce (24 байта).
   • Внутренние данные (LoginData) формируются в ByteStream. Они включают в себя ID аккаунта (0-1 для нового), версию клиента (47.365.2) и множество полей с информацией об устройстве, включая валидные по формату идентификаторы (UUID, HEX-строки).
   • Payload для шифрования собирается как RNonce + LoginData.
3. Шифрование:
   • Ключ: Используется s, вычисленный на шаге 1.
   • Nonce: Вычисляется как hash(client_pk + server_pk).
   • Процесс: (RNonce + LoginData) шифруется с помощью SecretBox(s).encrypt(...).

Структура и отправка пакета:

Финальный пакет 10101 состоит из:

• Публичный ключ клиента (32 байта, в открытом виде).
• Зашифрованная полезная нагрузка.

---

Шаг 3: ServerHello (ID: 20100)

• Направление: Сервер -> Клиент
• Шифрование: Отсутствует

Получив и успешно расшифровав LoginMessage, сервер присылает этот пакет в открытом виде. Он содержит серверный Nonce (SNonce), который будет использоваться для дальнейшей связи.

---

Шаг 4: LoginOk (ID: 20104)

• Направление: Сервер -> Клиент
• Шифрование: Симметричное (SecretBox)

Это финальное подтверждение от сервера.

• Ключ: Сервер использует тот же самый s, который он вычислил ранее.
• Nonce: Сервер вычисляет nonce как hash(RNonce + client_pk + server_pk).
• Содержимое: Внутри расшифрованного пакета находится второй, настоящий ключ сессии (session_key), который будет использоваться для шифрования всех последующих сообщений (кроме handshake).

Успешная расшифровка этого пакета означает, что аккаунт создан и сессия полностью установлена. Разрыв соединения сервером сразу после отправки LoginOk является нормальным поведением для простого тестового клиента, который не продолжает общение (например, не шлет KeepAlive).