Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Wed May 12, 2021 9:41 pm

All times are UTC

Post new topic  Reply to topic  [ 1 post ] 
Author Message
PostPosted: Thu Apr 29, 2021 12:38 pm 

Joined: Thu Apr 29, 2021 11:42 am
Posts: 1
Jumpgate is an old MMO from the early 2000s that died in 2012 and got a lucky break in 2013-2015 when a russian fanserver popped up to take the place of the original game.

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.

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:

a replay of the original 20-byte from the previous packet.
32 bytes of random data.

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.

Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 1 post ] 

All times are UTC

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited