5.0 KiB
permalink, title, categories, tags, layout, is_draft
| permalink | title | categories | tags | layout | is_draft | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| /posts/writeups/4 | Implementing a CK3 Private Peer-to-Peer Multiplayer Server - Part 2 - Preliminary Analysis of Client/Server Exchanges |
|
|
default.liquid | true |
Implementing a CK3 Private Peer-to-Peer Multiplayer Server - Part 2 - Preliminary Analysis of Client/Server Exchanges
To investigate the exchange, we set up two MITM proxies and clients to listen to both their communications, as explained in our previous post Part 1 as follows:
We run a MITM proxy for the CK3 game client, hosting the game while running a SOCKS proxy on port 7070 and the web interface on port 7171:
$ mitmweb --mode socks5 --listen-port 7070 --set web_port=7171
[08:51:23.883] Loading script local-redirect.py
Loaded redirect addon
[08:51:23.883] SOCKS v5 proxy listening at *:7070.
[08:51:23.884] Web server listening at http://127.0.0.1:7171/
We run a MITM for the CK3 game client, not hosting the game while running a SOCKS proxy on port 6060 and the web interface on port 6161:
$ mitmweb --mode socks5 --listen-port 6060 --set web_port=6161
[08:51:49.697] Loading script local-redirect.py
Loaded redirect addon
[08:51:49.698] SOCKS v5 proxy listening at *:6060.
[08:51:49.699] Web server listening at http://127.0.0.1:6161/
We now run two instances of CK3 through their respective proxies. Then, we can play on two different accounts, run a multiplayer game, and study the communications between the clients (host of the game, non-host) and the server as follows.
Starting the game client for the game host:
$ nsproxy -s 127.0.0.1 -p 7070 ./ck3:
Starting the client for the game non-host:
nsproxy -s 127.0.0.1 -p 6060 ./ck3
Investigation the Messages Exchgenfs
Starting a game host (proxy port 7070) and joining by the game non-host (proxy port 6060) on each respective web UI shows the following.
For instance, the host game flow looks like this:
We can see on the right the path endpoints that serve the communication.
From this, we learn that the communication for the multiplayer game uses a websocket at ck3-new.online.paradox-interactive.com
Looking at the right panel for the communications path, we can see messages exchanged related to creating a game.
We can then start investigating specific messages to better understand the protocol.
For instance, we focus on the Hex Dump of a message at the creation of the game, which looks related to the creation of a game ID:
0000000000 7a 38 0a 2d 35 30 33 36 32 35 30 30 2d 38 33 65 z8.-50362500-83e
0000000010 33 2d 34 64 37 38 2d 39 37 65 34 2d 36 35 30 32 3-4d78-97e4-6502
0000000020 65 34 39 38 30 39 35 33 2e 6e 61 6b 61 6d 61 2d e4980953.nakama-
0000000030 31 10 08 1a 05 6c 6f 62 62 79 1....lobby
After some investigation using CyberChef we find we can decode it using the following recipe: From Hexdump > ```Protobuf Decode``
{
"1": "1",
"16": {
"1": "50362500-83e3-4d78-97e4-6502e4980953.nakama-1"
}
}
As a result, we now understand that the game uses websockets with protobuf to communicate.
At this point, we notice nakama in the game ID, and we ask ourselves if it's relevant.
After investigating further, we discover that nakama is an open-source multiplayer game server.
Leveraging Nakama Documentation
This is helpful as it gives us a bigger idea of their server architecture.
For instance, we look at the Nakama documentation for different types of servers.
Returning to the message flows, it seems that the servers send messages every few milliseconds, meaning a tick update from the server.
Given the documentation, it seems we are looking at a Nakama authorative server
This means we have a clearer understanding of the server architecture and protocol.
However, we still need to understand the server implementation logic done by the CK3 developers.
Conclusion
We now have a general idea of the server architecture and protocol used, but still need to reverse-engineer the server's internal logic.
One way to implement our own multiplayer would be to directly implement a Nakama server, as it is open-source.
However, this solution would require setting up the Nakama server somewhere in order to play, which is not easy to run and set up, and doesn't align with our target (a simple, easy-to-run local peer-to-peer server).
Therefore, having to run a Nakama server will not work, and as a result, we chose to implement our local Nakama authoritative server emulator for CK3. This is what we will do in the following part of this series.