Search this site


Metadata

Articles

Projects

Presentations

xbox system link - description of the protocol

Table of Contents

  1. System link protocol

System link protocol

My xbox proxy doesn't know anything about anything above layer 3 with respect to xbox system link. This means you don't need to know anything either, if you want to write a proxy.

All traffic from the xbox comes from IP 0.0.0.1. The general idea is that I take the entire layer2 (ethernet) packet and send it in an UDP packet to another proxy. That proxy receives it and dumps it, unchanged, on the remote network. That's it. That's the whole deal.

Let me reiterate. It doesn't matter what happens above the UDP layer. You don't care. The proxy just forwards the raw packets, and your xbox gets them unchanged. Works like a charm and is game agnostic.

This works through the magic of switches learning mac addresses. Your local network starts to learn that all of the remote xboxes are coming from your machine. The xboxproxy itself also tries to be a bit smarter. It learns which mac addresses (xboxes) are coming from what proxies and only sends unicast packets to the correct proxy housing that xbox.

That's pretty much all of the proxy. It could be done in much fewer lines in Java or Python (Scapy for example) becuase 70% of the code is just setting up and managing the list of known proxies and xboxes as well as fancy packet checking. I'm reasonably certain that if you were to implement my xboxproxy in scapy, it would be around 20 lines of code if not less.

xboxproxy - an xbox system link proxy

Background

In an effort to be able to play Halo 2 with some out of state friends, I wrote an xbox system link proxy that would essentially bridge only xbox network traffic across across layer 3 networks using UDP. Written in C and uses libpcap and libnet. A later update added multicast support so Apple's Rendezvous (mdns) protocol could span subnets and networks.

It's a very simple program that simple takes certain packets and forwards them to other known xbox proxies. The xbox system link bridge will let you essentially bridge the broadcast and multicast traffic across multiple networks using these proxy bridge-points.

How does it work?

The xbox system link uses ethernet addresses (Layer 2) to indicate destination address and UDP (Layer 4) to send data. If you aren't familiar with the OSI model, then the layer information won't help you here. Basically, the 3 layers we care about for this system link proxy are ethernet (layer 2) and udp (layer 4). There's a special mention for the ip layer (layer 3) but that will be explained shortly.

System link packets come in two flavors: broadcast and unicast. In Halo 2, when you go to look for system link games, your xbox will send ethernet broadcast packets probing for available games. Broadcast packets are received by every network device on your layer 2 segment, this usually means your subnet or immediate network. Other xbox systems who are hosting games will respond directly to your xbox using your xbox's ethernet address (MAC address) as the destination. This process is called "discovery." After the discovery process completes and your xbox knows about other xboxes hosting games on the network, it begins direct communication to the known xboxes. When you try to join a game, your xbox sends packets directly to the other xbox you are connecting to. Direct communication continues until you quit the game.

A special note needs to be made, becuase you can't simple skip over layer 3 (the ip layer). We know now that addressed communication uses ethernet addresses, and we also know that the payloads are inside UDP packets, but what about the IP layer? The IP layer has addresses of its own, among other kinds of flags. Xboxes use the IP of 0.0.0.1 to communicate. This is nothing *too* special, but if you want to sniff only your xbox's traffic, then you can simply filter for that ip and you'll get it.

The proxy works by listening for broadcast packets from any xboxes on the immediate network. Any broadcast packets are forwarded to any known proxies over UDP. The proxy also keeps track of ethernet addresses by proxy. So if a packet from "my" xbox wants to talk to another xbox, the proxy will know which proxy that target xbox is on, and only forward the packet to that proxy.

This is a very simple system, and I don't have to know anything about the system link protocol beyond what the underlying layers are used for communication.

I later did some investigating into iTunes music shares. iTunes uses mdns (Apple calls it Rendezvous) for "discovery" of other iTunes music shares. The discovery is done over a protocol called multicast. Adding mdns support to the proxy/bridge program was quite trivial, and I have tested that it does in-fact work. You can use it to listen to iTunes music shares which are not on your immediate network.

Where can I download it?

download xboxproxy

What OS's are known to work?

  • FreeBSD 4.x/5.x/-current
  • Fedora 3 Linux 64bit
  • RH9 (Requires Fedora 4 binaries of libpcap and libnet)
  • Solaris 10 SPARC

How do I use it?

Requirements:
  • libpcap
  • libnet 1.0 or 1.1.x (both are supported)
Build instructions:
  • Unpack it with tar -zxf proxy-2.1.tar.gz
  • cd proxy-2.1
  • ./configure
  • make
  • make install
Use instructions:
Usage: ./proxy [-bxm] [-u] [-s <server>] [-i <dev>] [-d <debuglevel>] [-p <port>] [-h]
-x              forward xbox system link packets
-b              forward broadcast traffic
-m              forward multicast packets
-u              use udp encapsulation instead of tcp (default)
-s <server>     specify another proxy to send packets to
-i <dev>        ethernet device to sniff packets on
-d <level>      specify debug level, (0-1000)
-p <port>       which port to send data on when talkin to other proxies
-f <bpf filter> an additional bpf filter string you wish to use
-h              this message!