Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Mon Mar 27, 2017 10:26 pm

All times are UTC

Post new topic  Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Mon Aug 29, 2016 12:45 pm 

Joined: Mon Aug 29, 2016 10:29 am
Posts: 3

I saw the information on Luigi's web page about the encryption used in Halo to encrypt the peer-to-peer packets; however, I'm not quite sure how to 'use' that knowledge.

I have a game that uses the gamespy servers (or, more exact, custom-made variants of them) to connect players, and after Natneg and the connection itself is established, they start exchanging these 0xfefe encryption packets, just like Halo does.

However, the other player initiates the connection. In the Halo-related source code files from Luigi, it seems as if the player who wants to connect sends the fefe-packet with type 1, the host then replies with type 2 and then the new player replies with type 3. In the game I'm analyzing (Mario Kart Wii), it's the other way around.

The player who is currently hosting the match sends a type-1-packet to the new player, who replies with a type-2-packet, same for type 3 and 4 afterwards.
Also, the game does not seem to use this encrypted connection anywhere - all packets after that successful key exchange are unencrypted.

The problem now is: The source code by Luigi contains information about how to build type-1 and type-3 packets (because these are the ones his tools send), but not so much code about type 2.

My goal is to write a program which claims to be a new guest. So, it'll connect to our master server and get the player data, perform NATNEG, and will then, as a new guest, receive that 0xfefe-01 packet from the game host. The only thing missing would be, replying with a valid type-02 packet so the host continues the connection and starts sending actual in-game data (remember, that is not encrypted).

I tried simply resending a recorded type-02-packet, but that didn't work (which was to be expected) due to the key exchanging.

Does anyone (maybe Luigi who made the initial documentation and tools for Halo) have documentation / tool(s) / idea(s) on what / how I can talk to the other game, how I can build a type-2-message which will be accepted by the host so we (the host and my tool) can continue to talk to eachother?

Here is a hexdump of the related packets. What I'd like to do is to "emulate", so, make my own FE02 and FE04 packets.

18:52:00.256  A<a   <host-IP>:53063 ->
    39 (0x27) data bytes in 1 record, [CSUM:ok,d971,d971]
   -1.RELX.FE01, 27 ( 39/dec) bytes, offset 0x00
       0:  fefe 0100 0000 004e  7667 4268 706d 7423  :þþ.....NvgBhpmt#:
      10:  3d46 7d7b 6253 6251  7e29 3b5e 2a24 693d  :=F}{bSbQ~);^*$i=:
      20:  3556 5861 4e4f 50                         :5VXaNOP:

18:52:00.260   A>a -> <host-IP>:53063
    71 (0x47) data bytes in 1 record, [CSUM:ok,838a,838a]
   -1.RELX.FE02, 47 ( 71/dec) bytes, offset 0x00
       0:  fefe 0200 0000 012e  265d 3e2f 6235 7c2f  :þþ......&]>/b5|/:
      10:  4050 604b 6663 793b  7153 785d 3a40 2478  :@P`Kfcy;qSx]:@$x:
      20:  2a50 3e72 7739 7a60  677e 6732 7426 3c6d  :*P>rw9z`g~g2t&<m:
      30:  4367 3539 606e 2b2f  6c22 546f 6f3a 7634  :Cg59`n+/l"Too:v4:
      40:  6640 627c 3f4d 52                         :f@b|?MR:

18:52:00.315  A<a   <host-IP>:53063 ->
    49 (0x31) data bytes in 1 record, [CSUM:ok,efb6,efb6]
   -1.RELX.FE03, 31 ( 49/dec) bytes, offset 0x00
       0:  fefe 0300 0100 0159  6a34 2121 6322 7525  :þþ.....Yj4!!c"u%:
      10:  3f22 3c77 4722 7327  5134 796f 2527 742f  :?"<wG"s'Q4yo%'t/:
      20:  292c 3462 2e43 2333  3234 3037 3836 3432  :),4b.C#324078642:
      30:  00                                        :.:

18:52:00.335   A>a -> <host-IP>:53063
     7 (0x7) data bytes in 1 record, [CSUM:ok,69b7,69b7]
   -1.RELX.FE04,  7 (  7/dec) bytes, offset 0x00
       0:  fefe 0400 0100 02                         :þþ.....:


PostPosted: Mon Aug 29, 2016 2:01 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 5700
It's stuff of many years ago so I will try just to guess what it may be.

In packet 0x02 we have 2 different fields, one at offset 7 and the other one at offset 0x27 (39).
Considering that the one at offset 0x27 is used as a challenge to build the response string for packet 0x03, I suppose that the one at offset 7 is just a response to the challenge sent in packet 0x01 at offset 7.
It seems to have sense, just a 2-ways challenge-response.

And regarding how to create the challenges, use just random chars that fits the range >= 0x21 and <= 0x7d (just as visible in gssdkcr.h).
In halofp I simply used a sequence of '0's.

PostPosted: Mon Aug 29, 2016 2:10 pm 

Joined: Mon Aug 29, 2016 10:29 am
Posts: 3
Thanks a lot for your reply, I'll try the functions in gssdkcr.h and see if it works.

PostPosted: Mon Aug 29, 2016 2:33 pm 

Joined: Mon Aug 29, 2016 10:29 am
Posts: 3
I tried that function, and the resulting string is almost identical to the one in the dump - the first char and one char in the middle are different. I suspect this is because of the randomness in the gssdkcr() function and the game should still accept that string?

EDIT: I'll just try that in the future, but that'll probably take some time because we haven't written any of the other code to connect to the game yet - we've only documented every single packet they exchange and this FEFE one was the last one missing.

PostPosted: Mon Aug 29, 2016 4:30 pm 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 5700
Yeah the function uses a random number (just like the original code) and I don't know if the key used by this game is the default one.

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

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