any news?
I think packet C -> ChatServer has been encrypted. Maybe? some people tell me it wrong XOR key, but i don't believe it wrong. Because i have change it. :$::$:
Any new ide?
Printable View
any news?
I think packet C -> ChatServer has been encrypted. Maybe? some people tell me it wrong XOR key, but i don't believe it wrong. Because i have change it. :$::$:
Any new ide?
That's offtopic, but I already wrote what's encrypted and how. If something is wrong, it's most likely the 32-byte XOR-Key.Quote:
Originally Posted by BladeKnight109
Anyways... poor post of someone who sells "MU Services" :D
I have a fork from the SimpleModules and made some fixes, it now produces the same original SimpleModulus.lib.
You can take a look here, if you want...
https://github.com/navossoc/SimpleModulus
Just load the keys and use it ;)
[]'s
@navossoc: SimpleModulus is not used by the ChatServer at all - everything uses C1 or C2-packets.
A little update:
After I found everything out about the communication between game client and chat server, I examined what happens in its log when I send stuff the original chat server due port 55906 and 55907. The chat server opens port 55907 and tries to connect to the ExDB-Server due port 55906.
The listener on port 55907 just seems to be some port to check if you can connect to the chat server. It processes no packet and sends nothing back, just prints some messages about "port check" to the log. It closes after connection to ExDB-Server has been established.
The ChatServer tries to connect to the ExDB-Server by Port 55906. When it connected, it sends a packet to the ExDB-Server, like this:
C1 3A 00 02 AC DA 43 68 61 74 53 65 72 76 65 72 00 CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC
3rd byte: 00 - packet type
4th byte: 02 - "ChatServer" server type value
5&6th byte: DAAC -> 55980 is the port for the chat client listener
7th bytes and following: "ChatServer" as string
This connection is responsible to receive chat room creations from ExDB-Server, and returns ticket and room ids back. I iterated every C1 packet type from 00 to FF and found reactions in the logs with A0 and A1 packet types.
A0 is used to create a chat room and registering the clients.
Example for A0:
I sent C1 16 A0 41 42 43 44 45 46 47 48 49 4A 50 51 52 53 54 55 56 57 58 59
It contains the first and second client name after A0 (each 10 bytes).
The chat server then returns two packets, one for each client with its index and ticket
In the log you see two tickets; 6822976 for ABC... and 96141313 for PQR...Code:s |rid| |-----client name-----------| |---------other client name-| |------???------| |-ticket--| |--------???----------|
C1 2C A0 01 00 00 41 42 43 44 45 46 47 48 49 4A 50 51 52 53 54 55 56 57 58 59 00 00 00 00 CC CC 00 00 11 04 CC CC CC CC 00 CC CC CC
C1 2C A0 01 00 00 50 51 52 53 54 55 56 57 58 59 41 42 43 44 45 46 47 48 49 4A 00 00 00 00 CC CC 01 00 BB 05 CC CC CC CC 01 CC CC CC
For example, to get the ticket of the second packet: 01 00 BB 05 -> 0x05BB0001 ---[hex to decimal]--> 96141313
What seems crazy is, that the ticket contains the index as well, and in the 4th last byte the index is there as well. But as you will see later, the 4th last byte is not useful.
So, the chat server creates just 2 random bytes for the tickets - not very secure ;)
Then there is only one packet type left: A1. It's used to register additional clients to an existing chat room. Not many people know that you can invite additional players to a chat room ;)
Example: C1 10 A1 00 00 00 61 62 63 64 65 66 67 68 69 6F
Index 4 and 5 is the room id, the rest behind is the client name.
The chat server answers this with the same packets as above (ticket 96862210):
C1 2C A0 01 00 00 61 62 63 64 65 66 67 68 69 6F CC CC CC CC CC CC CC CC CC CC 53 54 55 56 CC CC 02 00 C6 05 CC CC CC CC 57 CC CC CC
The main part of my chat server which speaks with the game clients is already fully working, and the part about registering clients is working internally within my other game server architecture.
As a spin-off project I could implement the listener which is responsible for the communication with the ExDB-Server, so it would be a full chat server which could replace the original one of Webzen.
I guess I will release a first version soon :)
@nevS
Sure, but as far I understand, you said you are cloning everything, right?
So.........
My ChatServer almost became useless after I made the whisper messages "cross server".
Anyway, use it if you want.
[]'s
Thanks, but well, I'm not a newb. I started my own mu server project like 7 years ago and had this already ;)Quote:
Originally Posted by navossoc
Lol, nice work, I have started to create my own chatserver but I stopped bcz too much work. I am happy to read this thread, because this feature of the game I think really really important.Quote:
Originally Posted by nevS
"Then there is only one packet type left: A1. It's used to register additional clients to an existing chat room. Not many people know that you can invite additional players to a chat room ;)"
You are right, but its bcz on the 90% of the muservers chatserver totally not or just half working.... So nobobody know this feature!
Keep going.
Found out how the chat server calculates the ticket.
First two bytes seems to be a client index over all connected clients, maximum 5000.
Next two bytes is a random number between 1000 and 1999 (lol).
I guess the ExDB-Server finds out by the order of incoming packet which client gets which index (ix) in a room. I wonder if it's relevant and required for the game client anyway.