75 lines
6.6 KiB
Markdown
75 lines
6.6 KiB
Markdown
# 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`). |