Jumpgate is a early-2000s spaceflight MMO originally released by Netdevil. The game was shut down in 2012, but was mysteriously brought back by Russian fans, seemingly fully intact. In the interest of preserving the game in the event that the current server disappears later down the line, I've developed an interest in reverse engineering the server that we have available right now.
What have I done so far?
I've been able to determine the initial vectors for the authentication chain. Also, as a brief note, all data seems to be in inverse byte order, so I have had to reverse each field to get appropriate values.
The server starts the exchange by sending three fields to the client:
* A seemingly random 20 byte stream
* An RSA Exponent: 0x10001
* An RSA256 Public Key
The client then:
* Mirrors the 20 byte stream back to the server
* Sends 32 bytes of encrypted data.
I've confirmed that this was encrypted using the server's public key as I was able to plug my own keys into the exchange and get a consistent, decryptable plaintext stream back.
The encrypted 32 byte exchange + the 20 byte stream seem to be used to generate the final AES key. Using an open source tool called 'aes-finder', I was also able to discern that:
* The RSA encrypted ciphertext is always the same, at least on the first connection attempt. It seems to alternate afterwards.
* Sending the same 20 byte stream + the first connection will always generate a deterministic AES128 key.
Following this exchange, another packet is sent from the server to acknowledge the exchange and enable encrypted communication.
As for the AES mode, I'm still uncertain whether or not we're using CBC or ECB at this time, or where the IV is in memory if CBC is the case.
The question from this point is determining how the game generates the final AES key to finalize the encryption process.
As a note, it is also possible to NOP the AES encryption calls and get seemingly predictable datastreams back from the client. I will yank the authentication chain + NOPed plaintext from my testbed the next time I get to run it. I have not currently gotten a chance to analyze the 'decrypted' datastreams.
This progress leaves a question: How are we generating the AES key, and what settings do we need to use (namely mode and padding!) to generate it? I'm assuming that a KDF of some sort is being used, though which one is currently unknown.
This is currently where I am at right now. If anyone wants to help, the game client is freely available from
What have I done so far?
I've been able to determine the initial vectors for the authentication chain. Also, as a brief note, all data seems to be in inverse byte order, so I have had to reverse each field to get appropriate values.
The server starts the exchange by sending three fields to the client:
* A seemingly random 20 byte stream
* An RSA Exponent: 0x10001
* An RSA256 Public Key
The client then:
* Mirrors the 20 byte stream back to the server
* Sends 32 bytes of encrypted data.
I've confirmed that this was encrypted using the server's public key as I was able to plug my own keys into the exchange and get a consistent, decryptable plaintext stream back.
The encrypted 32 byte exchange + the 20 byte stream seem to be used to generate the final AES key. Using an open source tool called 'aes-finder', I was also able to discern that:
* The RSA encrypted ciphertext is always the same, at least on the first connection attempt. It seems to alternate afterwards.
* Sending the same 20 byte stream + the first connection will always generate a deterministic AES128 key.
Following this exchange, another packet is sent from the server to acknowledge the exchange and enable encrypted communication.
As for the AES mode, I'm still uncertain whether or not we're using CBC or ECB at this time, or where the IV is in memory if CBC is the case.
The question from this point is determining how the game generates the final AES key to finalize the encryption process.
As a note, it is also possible to NOP the AES encryption calls and get seemingly predictable datastreams back from the client. I will yank the authentication chain + NOPed plaintext from my testbed the next time I get to run it. I have not currently gotten a chance to analyze the 'decrypted' datastreams.
This progress leaves a question: How are we generating the AES key, and what settings do we need to use (namely mode and padding!) to generate it? I'm assuming that a KDF of some sort is being used, though which one is currently unknown.
This is currently where I am at right now. If anyone wants to help, the game client is freely available from
You must be registered to see links
.
