BSDecrypter-BLSxColetteBrawl/README-en.md

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).