Post: Fun with LAN Party and general network stuff
11-28-2013, 09:25 PM #1
(adsbygoogle = window.adsbygoogle || []).push({}); This is a completely new frontier of modding this game, and I do believe that, with enough reverse engineering, it can be used to get modifications from absolutely nothing. I know some research into modification of the network was performed before, with packet injection, but this would be a new tier. Packet injection is simply not possible in the way that people think it is. This would be more emulating a server.

Now, I'll share a few things I've found. The PlayStation 3 uses completely unencrypted sockets, at least on MW2, and on LAN Party. I believe ALL sockets are unencrypted, because just look at the extreme amount of modifications have been created involving the network (accessing PSN on firmwares that shouldn't access it, playing on retail servers on a debug firmware, etc.). What this means is basically when network connections are created, they are completely interceptable. This means we can view the data that is sent from the PS3 and back.

Now, this is good for a few reasons:

  • We can see packets that are sent/received, unencrypted (of course, compression may be an issue or a specific game may encrypt the packets)
  • We can modify said packets freely
  • We can begin to reverse engineer protocols used by games to obtain results that would otherwise be considered impossible without a jailbreak


Tools used:

  • Colasoft Capsa 7 Enterprise Demo


In this thread I'm focusing on the process of a client connecting to a LAN server, or the Quake MP protocol(considering that MW2's engine is based on Quake, regardless of what IW tries to claim).

To begin, I connected my PlayStation 3 to my PC via an ethernet cable. This is all you really need to do to examine the network protocol. After that was done, I fired up Capsa. I started a capture on my ethernet adapter, then fired up MW2. I went into the game, went to LAN Party, and then searched for a game. One interesting packet caught my eye instantly - the game was sending a UDP packet from port 3075 to port 3075, to the IP address 192.168.1.255 (to all of those unaware, this is the IP address used to send the packet to the whole network, so that all PS3s on the network can be queryed without knowing the IP address of each system) . To confirm this was MW2 and not a regular PS3 thing, I examined the packet more deeply.

This was in the data field of the aforementioned packet.
Originally posted by another user
getinfo xxx

A quick look through the Quake 3 source mentions that this is what Quake sends to the master server list so that the servers may return another thing, the infoResponse. The infoResponse is what Quake parses to show the server name, the mapname, etc. It also lets Quake know that a server is being hosted. This system exists in CoD and is exactly the same.

So this packet let me know that MW2 is indeed querying my network for LAN servers. With this information, I can now obtain the infoResponse for my own server.

I fired up Colasoft Packet Builder, crafted my getinfo packet (with, of course, the source IP and Destination IP being my PS3 and my PC, respectively), and then hosted a game on MW2. Using Colasoft Packet Player, I sent out my packet.

Success! MW2 returned the infoResponse, exactly like I thought it would.
This was my infoResponse
Originally posted by another user
infoResponse
\challenge\xxx\protocol\139\checksum\-1740007858\hostname\Player\mapname\mp_terminal\clients\1\sv_maxclients\18\gametype\war\kc\1\hw\9\seckey\nulled\secid\nulled\hostaddr\nulled
(places where nulled is are my per console stuff, which I don't want to be public)

Let's dissect this:
challenge - this is the challenge that "getinfo" sent. It's a way of keying the servers, ie if you send a packet saying getinfo abc, a server with the challenge xxx won't respond with an infoResponse.
protocol - not sure what this is
checksum - presumably a checksum of the d3bsp of the map file, so that players with modded/different d3bsp files cannot connect
hostname - the username of the host
mapname - the map, terminal
clients - player count
sv_maxClients - the amount of players that can be in a game
gametype - the game type of the current game
kc - ??
hw - ??
seckey - ?? (seems to be xnkey from Xbox)
secid - ?? (seems to be xnid from Xbox)
hostaddr - presumably some sort of address (seems to be xnaddr from xbox)

I cannot go any further with this simply because of a lack of a second console, but if anyone is nice enough to let me Xlink with them so I can examine the network protocol further, send me a PM or post in this thread.

I believe that it is possible to "host" a fake server. This wouldn't really do much, but it'd be a start. There might be some exploits that could be performed with this, though.
This will work on other CoDs, too!

EDIT:
Doing a bit more digging, I can see where, in an online game, the server sent and received packets. These packets are presumably Huffman encoded, considering that Quake 3 used it to make the UDP packets smaller.

I'll explain a bit about the client/server architecture:
The client, or the player, sends "client commands", which the server parses and then updates the client's information on their side. This causes you to be able to actually move and do things. Also, for the client to know what the other players are doing, considering that no data from them ever goes to the client, the server sends what is known as a "snapshot". The snapshot is basically what all the entities and other clients are doing, as well as a few other things. For example, when a server command is sent, the client receives a snapshot with that server command in it.

Now, when you look at the packets sent and received in Capsa, you can see certain UDP packets sent between the server and the client. Presumably the packets being sent to the server are the client commands, and the packets being sent from the server are the snapshots. You can verify these are snapshots and client commands by the sequence number and type. The sequence number is how the game knows that these packets are not old, and are new information, otherwise packets could come out of order and destroy gameplay. Also, this information is not Huffman encoded, so you yourself can see this if you decide to do a sniff. The sequence number also provides extra security from people trying to falsify packets. It's impossible to guess this number, because on every server "tick" this number changes.

This could technically be intercepted by a computer, so that EVERY snapshot sent has server commands in it, so that the client can be "infected" from nothing. Theoretically what this would require is a program to wait for the snapshot to be sent, stop it before it gets to the PS3, modify it, and then send to the PS3. This is entirely feasible, it will just require some people to do some research into Huffman encoding and figure out how it's done for this game.
Last edited by ihatecompvir ; 11-29-2013 at 01:29 AM.

The following 7 users say thank you to ihatecompvir for this useful post:

ahreloco, JakeP0500, MayhemLobbiez, Obris, Vince, ROBERT_ROWL_, Uk_ViiPeR
11-29-2013, 01:39 AM #2
Could you send, instead of "infections" through the snapshots, false locations? I mean "create" the image of a player where there is no player?
11-30-2013, 07:28 PM #3
JakeP0500
Do a barrel roll!
I would recommend to post this in a more recent CoD (Ghosts for example) as I will attract more attention! If more people know, then more people will code for it!
04-19-2014, 04:17 PM #4
nay1995
The Master
Originally posted by Ihatecompvir View Post
This is a completely new frontier of modding this game, and I do believe that, with enough reverse engineering, it can be used to get modifications from absolutely nothing. I know some research into modification of the network was performed before, with packet injection, but this would be a new tier. Packet injection is simply not possible in the way that people think it is. This would be more emulating a server.

Now, I'll share a few things I've found. The PlayStation 3 uses completely unencrypted sockets, at least on MW2, and on LAN Party. I believe ALL sockets are unencrypted, because just look at the extreme amount of modifications have been created involving the network (accessing PSN on firmwares that shouldn't access it, playing on retail servers on a debug firmware, etc.). What this means is basically when network connections are created, they are completely interceptable. This means we can view the data that is sent from the PS3 and back.

Now, this is good for a few reasons:

  • We can see packets that are sent/received, unencrypted (of course, compression may be an issue or a specific game may encrypt the packets)
  • We can modify said packets freely
  • We can begin to reverse engineer protocols used by games to obtain results that would otherwise be considered impossible without a jailbreak


Tools used:

  • Colasoft Capsa 7 Enterprise Demo


In this thread I'm focusing on the process of a client connecting to a LAN server, or the Quake MP protocol(considering that MW2's engine is based on Quake, regardless of what IW tries to claim).

To begin, I connected my PlayStation 3 to my PC via an ethernet cable. This is all you really need to do to examine the network protocol. After that was done, I fired up Capsa. I started a capture on my ethernet adapter, then fired up MW2. I went into the game, went to LAN Party, and then searched for a game. One interesting packet caught my eye instantly - the game was sending a UDP packet from port 3075 to port 3075, to the IP address 192.168.1.255 (to all of those unaware, this is the IP address used to send the packet to the whole network, so that all PS3s on the network can be queryed without knowing the IP address of each system) . To confirm this was MW2 and not a regular PS3 thing, I examined the packet more deeply.

This was in the data field of the aforementioned packet.

A quick look through the Quake 3 source mentions that this is what Quake sends to the master server list so that the servers may return another thing, the infoResponse. The infoResponse is what Quake parses to show the server name, the mapname, etc. It also lets Quake know that a server is being hosted. This system exists in CoD and is exactly the same.

So this packet let me know that MW2 is indeed querying my network for LAN servers. With this information, I can now obtain the infoResponse for my own server.

I fired up Colasoft Packet Builder, crafted my getinfo packet (with, of course, the source IP and Destination IP being my PS3 and my PC, respectively), and then hosted a game on MW2. Using Colasoft Packet Player, I sent out my packet.

Success! MW2 returned the infoResponse, exactly like I thought it would.
This was my infoResponse
(places where nulled is are my per console stuff, which I don't want to be public)

Let's dissect this:
challenge - this is the challenge that "getinfo" sent. It's a way of keying the servers, ie if you send a packet saying getinfo abc, a server with the challenge xxx won't respond with an infoResponse.
protocol - not sure what this is
checksum - presumably a checksum of the d3bsp of the map file, so that players with modded/different d3bsp files cannot connect
hostname - the username of the host
mapname - the map, terminal
clients - player count
sv_maxClients - the amount of players that can be in a game
gametype - the game type of the current game
kc - ??
hw - ??
seckey - ?? (seems to be xnkey from Xbox)
secid - ?? (seems to be xnid from Xbox)
hostaddr - presumably some sort of address (seems to be xnaddr from xbox)

I cannot go any further with this simply because of a lack of a second console, but if anyone is nice enough to let me Xlink with them so I can examine the network protocol further, send me a PM or post in this thread.

I believe that it is possible to "host" a fake server. This wouldn't really do much, but it'd be a start. There might be some exploits that could be performed with this, though.
This will work on other CoDs, too!

EDIT:
Doing a bit more digging, I can see where, in an online game, the server sent and received packets. These packets are presumably Huffman encoded, considering that Quake 3 used it to make the UDP packets smaller.

I'll explain a bit about the client/server architecture:
The client, or the player, sends "client commands", which the server parses and then updates the client's information on their side. This causes you to be able to actually move and do things. Also, for the client to know what the other players are doing, considering that no data from them ever goes to the client, the server sends what is known as a "snapshot". The snapshot is basically what all the entities and other clients are doing, as well as a few other things. For example, when a server command is sent, the client receives a snapshot with that server command in it.

Now, when you look at the packets sent and received in Capsa, you can see certain UDP packets sent between the server and the client. Presumably the packets being sent to the server are the client commands, and the packets being sent from the server are the snapshots. You can verify these are snapshots and client commands by the sequence number and type. The sequence number is how the game knows that these packets are not old, and are new information, otherwise packets could come out of order and destroy gameplay. Also, this information is not Huffman encoded, so you yourself can see this if you decide to do a sniff. The sequence number also provides extra security from people trying to falsify packets. It's impossible to guess this number, because on every server "tick" this number changes.

This could technically be intercepted by a computer, so that EVERY snapshot sent has server commands in it, so that the client can be "infected" from nothing. Theoretically what this would require is a program to wait for the snapshot to be sent, stop it before it gets to the PS3, modify it, and then send to the PS3. This is entirely feasible, it will just require some people to do some research into Huffman encoding and figure out how it's done for this game.


do you use xlink kai for LAN connecting?

Copyright © 2024, NextGenUpdate.
All Rights Reserved.

Gray NextGenUpdate Logo