Information on what the game was can be found here: https://en.wikipedia.org/wiki/Jumpgate: ... Initiative
In the interest of preserving the game in the event the new server disappears, I've been attempting to reverse engineer the server-client exchange so that I can start scraping packets and (hopefully) start documenting the foundation for proper private servers.
Based on my analysis using Ghidra & signsrch, I figured out that the game uses Rijndael/AES encryption. The effort at this point has been determining how the game client performs secure exchange and sets up the encryption channel. I was able to get the client to send unencrypted datagrams by NOPing a Rijndeal-related function.
The game sets up it's encryption after a small acknowledgement chain.
The server starts by sending a 62-byte datagram containing (presumably) a header, 20 bytes of seemingly random data (presumably a SHA-1 hash?), 4 bytes of padding(?), then 32 bytes of static data.
Here is some extract from Wireshark:
Note: The 20-byte block is currently hardcoded. Normally, the data is seemingly random.
Code: Select all
0000 00 00 03 20 04 06 00 01 02 03 04 05 06 07 08 09 ... ............
0010 0a 0b 0c 0d 0e 0f 10 11 12 13 01 00 01 00 c3 98 ................
0020 29 10 5c 83 bf cd ba 03 16 17 21 a6 95 c5 49 ca ).\.......!...I.
0030 4d 3c d0 b7 03 b9 fd 33 fd c9 3f f1 78 b3 M<.....3..?.x.
The client will respond with a 58-byte datagram, consisting of:
Header.
a replay of the original 20-byte from the previous packet.
32 bytes of random data.
Code: Select all
0000 00 80 02 a0 04 07 00 01 02 03 04 05 06 07 08 09 ................
0010 0a 0b 0c 0d 0e 0f 10 11 12 13 3a db bd 9e 95 e1 ..........:.....
0020 a0 01 d4 01 9a 59 f9 96 d8 25 b8 05 bf b4 c2 b0 .....Y...%......
0030 ff f8 1d 47 4c dc 20 ff a6 63 ...GL. ..c..c
The server then sends a final 13 byte packet to complete the exchange. Afterwards, any communication henceforth is encrypted.
My current guesses as to how this is working are that the game is either performing a PBKDF1 exchange, or a Diffie-Hellmann key exchange.
Does anyone have any ideas on how the client may be using this information to set up its handshake?
Edit: Corrected a small detail.