MxO Client - Server communication "protocol"

[HD_Morpheus]

Note: cryptography theory meanings are subjective from wikipedia and websites readings. In no way means that it shall be read as a full truth(hope it was! ) as Morpheus got no cryptography knowledge to asure 100% similarity on RL

Initial packets

If we peek some of the packets send by the in the communication between the client and the login/auth servers we see a pattern.

First packet always have some numbers in a structure, apparently randoms.

Second packet (server response) got same numbers plus another ones added.

Why?

That's called a "cryptographic nonce" (number used once) and is used specially to prevent packet sniffing and resending the packet by a third person in the communication, someone called eavesdropper (in this case, it's you, cause you saw the packets).

To asure some randomness, timestamps are added to this packets.

Client creates a randon number and server answers with another sequence to initiate a communication and hash using response.
For example, hashing password using the random response, so it isnt sent as plain text.

Identification protocol

MxO Uses the challenge-response system, which is a "enterprise-standard" to simplify the comunication.

How it works in real life:

- Crypto shall work with 4 keys for a communication:
Client public/private key
Server public/private key

Communication goes through:

- Client uses its public key to cipher the message (we wont specify algorithm here) and sends it to server.
- Server decyphers the message using its private key, and cipher a response with its public key
- Client receives ciphered packet and deciphers it with its private key.

This system gots its ups and its downs, but the main problem, applicated to game servers if that client may not know its private key and/or server keys. Another problem may be the time spent on ciphering/deciphering packets in both sides (specially on the server).

That's solved using a shared secret key. Shared key is a composed key, from client public key + server private key(1) OR client private key + server public key(2). Composed Shared key is the same in cases 1 and 2.
It is distributed between parts before the communication started (its like a "shared secret" between two people).

To prevent man-in-the-middle or eavesdropping, shared secret key is not sent through the communication.

How do this works then?

- Client uses its secret to cipher some message, better a nounce, and send it to the server (challenge).
- Server receives the message and deciphers it with the secret. Server sends an answer to the client (response).
- Client receives the response and knows if server knows the secret as it does.

If succesfully responsed, both know that the other share it secret and they are the authentic communication members (because of the nounce used above).

When they got success, a sessionKey (and that means a unique per session key) is created in some way, by combining challenge(random) + shared key.

This key, called "SessionKey" will be used as the "password" in the encrypt/decrypt algorithms, in the sense of:

a.encrypt("sometext",sessionkey, resultEncryptedString)
a.decrypt(encryptedString,sessionkey, resultDecryptedString)

Test of faith: From cryptography theory to reality

Let's say that this look great, wonderful or fully crap depending of the point of view of the user but... it is real?

This is real. If you peek a editor (you can even use windows default notepad one) you will find strings referencing this:

Code:

UNKNOWN CERT_ MESSAGE
CERT_ConnectRequest
CERT_ConnectReply
CERT_Challenge
CERT_ChallengeResponse
CERT_NewSessionKey

which seems pretty obvious, so wont describe it

[HD_Neo]

Woah you are great

I dont really understand this before you posted it here ...many thanks for it.
But this means too, we have a big problem to decrypt right? Cause we have to know the secret keys .

The first packet sends a timestamp (backwards like i posted) and the 04 is a algorythm type that is used (found it here : https://www.reverse-engineering.net/view...&sk=t&sd=a ).

Quote:0x4 // Type of algorithm or parameter size
0x818102 // Bignum identifier
// RSA-1024 Modulus:
BD 79 35 AE 7B 93 7B 2E 1A 1D F2 75 20 E1 4E 6C
7F 04 2D 7B B2 D9 5B 23 5E F5 72 DF 61 8A A2 2E
EE D6 85 FF 55 E6 CB 83 86 46 6D 35 5E 43 83 3F
B5 4F 70 8D 47 5F 6A A1 3F 4C 1D 47 52 C4 17 AC
5A F3 4B FC 82 9C FF 16 7C 65 43 9B 20 4E 95 9B
8E 33 F3 4F 85 88 22 34 70 A1 F7 A3 B1 73 81 C4
1F A4 93 CE 75 A4 73 E9 A4 17 57 67 5F EA 77 23
53 6A 12 99 D3 BD 0D 88 35 34 4A 9D 21 37 C5 53

0x110102 // Bignum identifier
// Two 1024 bit numbers, or 1 2048 number:
1A 1D 0F A5 FE EE A6 F5 60 29 F3 76 DE 20 F9 D1
FC 76 4A 5C 92 A3 94 3E F8 96 72 26 A9 EA 68 AC
EB AF FD 36 6B 6D 55 26 08 A1 A8 D6 57 6F 63 CA
FB D6 A3 7C 89 52 23 15 30 91 3B 1C B6 0E 6E 85
4B 6B E0 3A B2 09 66 01 6D 99 E8 63 A5 F4 FE 72
45 9C 8A 50 5D 1C ED 34 22 8D A8 72 F1 30 07 AC
6D 17 99 45 B2 9A 65 06 14 B7 8C CF 06 47 79 41
6E 33 52 DA 1F 24 D8 ED 91 CE 53 69 47 7C D6 2B

FD 63 F7 F7 F6 E5 1E 98 81 D1 D8 32 63 E2 29 AF
D5 1B D4 4D 7C B9 0C 8E 2C E7 46 3C D5 FB 0A FA
19 BE 68 6B B1 69 33 F1 6C 1E C0 D9 7A 73 BF 43
88 7A F1 7B 8D E1 6F 15 03 D0 58 7A 6F 4E C3 CC
D2 8E 65 6D 66 86 37 3C F0 78 C9 22 4E D0 32 EA
AB C6 9B BC 7D 0B 7E 30 37 C2 8C F5 98 AD CF BE
3A 20 98 16 F7 98 23 E2 6C D7 60 32 30 06 2B DE
D3 25 63 AC F7 D7 17 5D 93 C2 A5 01 32 38 BE 75

if you edit the pubkey.dat (make it only readable), and fill the 04 with 00, you can see the changes directly in the first packet.

But thats only the one, nothing changed really -.-.