HALO / Gamespy - encrypted 0xfefe packets

[Leseratte]

Hello,

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" 10.0.20.2, so, make my own FE02 and FE04 packets.

Code: Select all

18:52:00.256  A<a   <host-IP>:53063 -> 10.0.20.2:49678
    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  10.0.20.2:49678 -> <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 -> 10.0.20.2:49678
    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  10.0.20.2:49678 -> <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                         :þþ.....:

Leseratte

[aluigi]

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.

[Leseratte]

Thanks a lot for your reply, I'll try the functions in gssdkcr.h and see if it works.

[Leseratte]

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.

[aluigi]

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.