75 lines
4.1 KiB
Markdown
75 lines
4.1 KiB
Markdown
# BS-Dec-Key: Client Analysis and Implementation
|
||
|
||
This document provides a detailed technical breakdown of the connection process for a modified Project Colette V53 server that uses the cryptographic scheme from **BSL-V53**. It dissects the final, working version of the handshake, packet structure, and message exchange logic.
|
||
|
||
## [*] Core Concepts
|
||
|
||
The data exchange protocol is a custom protocol over TCP. The encryption is built on the **NaCl** library and uses a mixed, non-standard scheme.
|
||
|
||
- **Asymmetric Encryption**: `Curve25519` for computing a shared secret via Elliptic-curve Diffie–Hellman (ECDH).
|
||
- **Symmetric Encryption**: `XSalsa20-Poly1305` for encrypting messages after the shared secret is computed.
|
||
- **Packet Order**: Unlike many protocols, the order here is not `ClientHello` -> `ServerHello` -> `LoginMessage`, but rather `ClientHello` -> `LoginMessage` -> `ServerHello` -> `LoginOk`.
|
||
|
||
## [!] Step-by-Step Breakdown of the Connection Process
|
||
|
||
The process from initiation to a fully established encrypted session involves the exchange of four key packets in a specific order.
|
||
|
||
---
|
||
|
||
### **Step 1: `ClientHello` (ID: 10100)**
|
||
|
||
- **Direction**: Client -> Server
|
||
- **Encryption**: None
|
||
|
||
This is the very first packet the client sends after establishing a TCP connection. Its structure is critically important and must exactly match the server's expectations (six integer fields and an empty string), otherwise the server will simply drop the connection.
|
||
|
||
---
|
||
|
||
### **Step 2: `LoginMessage` (ID: 10101)**
|
||
|
||
- **Direction**: Client -> Server
|
||
- **Encryption**: **Symmetric** (`SecretBox`), but with a key derived asymmetrically.
|
||
|
||
This is the key and most complex packet, which is sent **before** receiving `ServerHello`.
|
||
|
||
#### **Client-Side Preparation (Before Sending):**
|
||
1. **Key Exchange and Secret Calculation**:
|
||
- The client uses the server's static `server_public_key`, known from the Frida script analysis.
|
||
- The client generates its own temporary key pair (`client_public_key` and `client_private_key`).
|
||
- The client computes a **shared secret (`s`)** via ECDH. This `s` is used **only for encrypting/decrypting `LoginMessage` and `LoginOk`**.
|
||
2. **Payload Formation**:
|
||
- The client generates its own **`RNonce`** (24 bytes).
|
||
- The inner data (`LoginData`) is constructed into a `ByteStream`. It includes the account ID (0-1 for new), the client version (`47.365.2`), and numerous device information fields, including validly formatted identifiers (UUIDs, HEX strings).
|
||
- The payload to be encrypted is assembled as `RNonce` + `LoginData`.
|
||
3. **Encryption**:
|
||
- **Key**: The shared secret `s` calculated in step 1 is used.
|
||
- **Nonce**: Calculated as `hash(client_pk + server_pk)`.
|
||
- **Process**: `(RNonce + LoginData)` is encrypted using `SecretBox(s).encrypt(...)`.
|
||
|
||
#### **Packet Structure and Transmission:**
|
||
The final `10101` packet consists of:
|
||
- **Client's Public Key** (32 bytes, in cleartext).
|
||
- **Encrypted Payload**.
|
||
|
||
---
|
||
|
||
### **Step 3: `ServerHello` (ID: 20100)**
|
||
|
||
- **Direction**: Server -> Client
|
||
- **Encryption**: None
|
||
|
||
After receiving and successfully decrypting `LoginMessage`, the server sends this packet in cleartext. It contains the **Server Nonce (`SNonce`)**, which will be used for further communication.
|
||
|
||
---
|
||
|
||
### **Step 4: `LoginOk` (ID: 20104)**
|
||
|
||
- **Direction**: Server -> Client
|
||
- **Encryption**: Symmetric (`SecretBox`)
|
||
|
||
This is the final confirmation from the server.
|
||
- **Key**: The server uses the same shared secret `s` that it calculated earlier.
|
||
- **Nonce**: The server calculates the nonce as `hash(RNonce + client_pk + server_pk)`.
|
||
- **Contents**: Inside the decrypted payload is the **second, true session key (`session_key`)**, which will be used to encrypt all subsequent messages (after the handshake).
|
||
|
||
Successfully decrypting this packet means the account is created and the session is fully established. A connection drop by the server immediately after sending `LoginOk` is **normal behavior** for a simple test client that does not continue the conversation (e.g., by sending `KeepAlive` packets). |