lancommander-ref/MHServerEmu
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update docs

Browse source
This commit is contained in:
Crypto137 2023-07-18 23:38:57 +03:00
parent 42ce70be78
commit 7be84a6a2f
3 changed files with 25 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

8
README.md
View file

@ -10,12 +10,14 @@ If you want to ask questions about the server emulator or help with the developm
## Features
This server emulator is currently in very early stages of development.
This server emulator is currently in early stages of development.
- Network protocol implementation.
- Initial server-client communication implementation.
- Initial client-server communication implementation.
- Loading into the game via hardcoded data.
## Setup
See [Setup.md](https://github.com/Crypto137/MHServerEmu/blob/master/docs/Setup.md) for information on how to set the server up.
See [Setup.md](https://github.com/Crypto137/MHServerEmu/blob/master/docs/Setup.md) for information on how to set the server up. Please note that since MHServerEmu is still in early stages in development, the process is currently not particularly user friendly.

20
docs/Overview.md
View file

@ -2,7 +2,7 @@
Marvel Heroes uses [Protocol Buffers](https://protobuf.dev/) for network message serialization. It is possible to extract protobuf schemas (.proto) from the main client executable using [protod](https://github.com/dennwc/protod) and then use them with tools such as protogen included with [protobuf-csharp-port](https://github.com/jskeet/protobuf-csharp-port).
Protobuf payloads follow the following structure:
Most protobuf payloads have the following structure:
```
byte MessageId          // same as index in its .proto schema
@ -10,7 +10,9 @@ byte MessageSize        // in bytes
byte[] EncodedMessage
```
When a player tries to log in, the client first requests an AuthTicket protobuf message from the auth server specified in SiteConfig.xml over https. This message contains session info (id, token, AES-256 encryption key), as well as the frontend server address and port that the client proceeds to connect to.
Some payloads appear to slightly deviate from this structure (e.g. dumped NetMessageInitialTimeSync has an extra 0x01 byte between id and size). The details of this are still being investigated.
When a player tries to log in, the client communicates with the auth server specified in SiteConfig.xml over https. The end result of this communication is an AuthTicket payload that contains session info (id, token, AES-256 encryption key), as well as the frontend server address and port that the client proceeds to connect to. It's possible to bypass the authorization process entirely by responding to the initial request with an AuthTicket payload straight away.
The frontend server routes messages to various services using what is called mux. Communication with the frontend server requires a 6 byte header with the following structure:
@ -35,14 +37,18 @@ enum MuxCommand
After establishing a mux connection with the frontend server, the client sends a ClientCredentials message that contains a session id and a session token encrypted using the AES-256 key provided in the AuthTicket message along with a specified random IV.
The frontend server can respond with either a LoginQueueStatus to display a login queue screen in the client, or a SessionEncryptionChanged to proceed with authorization. It's currently unclear how SessionEncryptionChanged functions.
The frontend server can respond with either a LoginQueueStatus to display a login queue screen in the client, or a SessionEncryptionChanged to proceed with logging in. It's currently unclear how SessionEncryptionChanged functions.
The client responds to the SessionEncryptionChanged message with two messages in a row: InitialClientHandshake with PLAYERMGR_SERVER_FRONTEND followed by NetMessageReadyForGameJoin that is most likely supposed to be routed to the server specified in the handshake.
What is supposed to happen after that is currently unclear:
After that roughly the following sequence happens:
- PLAYERMGR_SERVER_FRONTEND can initiate time synchronization with a NetMessageReadyForTimeSync. The client will then send a NetMessageSyncTimeRequest that can be responded with NetMessageSyncTimeReply. The client will then periodically send NetMessagePing.
- The server responds with NetMessageReadyAndLoggedIn.
- Sending a NetMessageReadyAndLoggedIn will cause the client to start a new mux connection on a different muxId and use it to send another InitialClientHandshake message, but this one is addressed to GROUPING_MANAGER_FRONTEND. The client doesn't respond to any GroupingManager messages.
- The client connects on mux id 2 and sends InitialClientHandshake for GROUPING_MANAGER_FRONTEND. It appears mux id 2 is used for communicating with GROUPING_MANAGER_FRONTEND.
- It's is possible in some cases to make the client display either a hero selection screen or a loading screen using NetMessageSelectStartingAvatarForNewPlayer or NetMessageQueueLoadingScreen respectively. However, these messages appear to require a timestamp of some type, and it's currently unclear how it fits in the protobuf payload structure.
- The server initiates time sync with NetMessageInitialTimeSync.
- After syncing time the client starts sending NetMessagePing periodically.
- The server queues a loading screen with NetMessageQueueLoadingScreen and begins sending a lot of data required for game initialization. The specifics are under investigation.

12
docs/Setup.md
View file

@ -1,6 +1,8 @@
# Setup
First you need to get the 1.10.0.83 client. If you still have Marvel Heroes in your Steam library, you can download it like this:
First you need to get the 1.52.0.1700 client. If you still have Marvel Heroes in your Steam library, you can download it from there.
It is also possible to download older versions of the client from Steam. For example, some versions, such as 1.10.0.83, have verbose logging enabled, which can be useful for development. You can download it like this:
1. Open the Steam console: steam://open/console
@ -12,7 +14,7 @@ First you need to get the 1.10.0.83 client. If you still have Marvel Heroes in y
You can find depot and manifest ids for other builds on [SteamDB](https://steamdb.info/app/226320/depots/). Some versions of the client have also been uploaded to the [Internet Archive](https://archive.org/).
Then you need to set up a web server to serve SiteConfig.xml and redirect the https AuthTicket request to localhost:8080. You can use either set the server up yourself, or use a solution stack such as WAMP.
After getting the client you need to set up a web server to serve SiteConfig.xml and redirect the https AuthTicket request to localhost:8080. You can either set the server up yourself, or use a solution stack such as WAMP.
1. Set up your preferred web server.
@ -27,13 +29,13 @@ RewriteRule ^/marvelheroes(.*) http://%{HTTP_HOST}:8080$1
Now you can actually redirect the client to your server and connect.
1. Create a marvelheroes directory in your web server's www folder and put SiteConfig.xml provided in this repository in it.
1. Put SiteConfig.xml provided in this repository in your web server's www folder.
2. Edit your ClientConfig.xml file located in "Marvel Heroes\Data\Configs" and replace the SiteConfigLocation value with "localhost/marvelheroes/SiteConfig.xml".
2. Edit your ClientConfig.xml file located in "Marvel Heroes\Data\Configs" and replace the SiteConfigLocation value with "localhost/SiteConfig.xml".
3. Compile and run MHServerEmu.
4. Run MarvelGame.exe with the -nobitraider -nosteam arguments.
4. Launch the game. You can launch the game without Steam by running MarvelHeroesOmega.exe with the following arguments: -solidstate -nobitraider -nosteam. There will be a DownloadChunkManifest error, but the game will start anyway.
5. Log in with any email and password.