Welcome, everybody.
Yeah, so I'm going to be talking about kind of my journey the past few years, reverse
engineering Xbox Live.
It was sort of my COVID project, for lack of a better word.
So I'm Tristan.
I also go as Mono Casa on the internet when I have hot takes of questionable veracity.
So that's what I'm using today.
So, yeah, today we're going to be going ‑‑ I'm going to kind of go over a background.
We're going to go kind of deep into what the protocols are themselves a bit.
We'll look at kind of how I took a look at reverse engineering it, kind of if somebody
wanted to repeat this work, you know, what you'd have to do to do that.
I'm going to kind of talk about ‑‑ a little bit about the replacement software.
I built up so far, where it's going, what exists at the moment.
And then I'm kind of going to go into a brain dump of discussing ‑‑ you know, as I've
gone through this, and I have very strong feelings about how to support people in a
very ‑‑ how to put this?
I don't know.
What's the ethical way to support abandoned software in an increasingly networked world?
And then we're going to go into questions.
Unfortunately, the demo gods weren't with us today.
My Xbox actually got the click of death literally last night.
So I'll put up a video tonight.
But source is up, too.
So you can go take a look at that.
So starting off.
Who am I?
I'm a developer.
My name is Tristan.
I'm an engineer.
I've got a lot of experience.
I've got ‑‑ with binary reversing, firmware development, cloud‑based device and identity
management and experience with custom tunneling of IP.
So these are all sort of a perfect storm for taking a look at Xbox live, taking it apart.
This is sort of the skill sets you would need to take a look at other video game networks.
If you want to get in touch with me.
I'm ‑‑.
My name is Tristan.
I'm from monocasa at zombie.org.
So zombie is the name of my particular replacement Xbox live infrastructure.
It was live.
Then it died for original Xboxes.
So now it's back again.
I thought it was a cute play of words.
Before we get much farther, I wanted to just kind of give a shout out to the other people
kind of working in the same space.
There's M. Borges.
Who has put in a ton of work into the emulators for Xbox.
There's also a guy by the name of Luke Usher who's working on similar replacement server
architecture called Insignia for Xbox live.
I think they both have Patreons.
I'm sure they both would love some support.
I've got nothing but love for both those people.
And interestingly, for a talk about 2000 ‑‑ early 2000s era Microsoft code, like, I am
going to rag on them a little bit.
But I was actually kind of surprised looking back on this with sort of historical context
with all of the ‑‑ or at least most of the obvious flaws.
Microsoft.
I don't know.
It actually makes sense in context.
And there's actually a pretty good protocol set.
And from what I can tell, other than ‑‑ you know, it's 20 years old.
But other than upgrading the crypto primitives, a lot of the basics are still here.
And a lot of the structure is still here.
And a lot of it still continues to make sense.
So yeah.
So like I've taught.
We're talking about Xbox live today.
My focus has really been on for the original console.
That's the only system that Microsoft so far has shut down access for.
So that was from November 2002 until April 2010.
There were some people that managed to keep their in‑game sessions going for like a
month later, which was really interesting.
Because ultimately it's kind of ‑‑ we'll see a lot of Xbox live.
It has ultimately the signaling pathway.
And then they generate ‑‑ once you have like an in‑game session, that's ‑‑ for
most games, doesn't actually communicate that much with the back‑end.
So it's kind of like Web RTC in that regard for a more modern context.
I'm also kind of trying to stay away from systems that are still online.
I'm not sure.
and give Microsoft some space where they are still making their money.
There's been in the Xbox hacking scene there was some people who didn't quite live by that
same standard and I don't think anybody won that game.
So, yeah, so kind of going back, Xbox Live is really kind of the first modern video game
network in a lot of ways.
There's a lot of other ones before it.
You know, it obviously took a lot of inspiration from Sega net, but video game networks go
really far back.
There was this really cool network called X band in the mid 90s that was like a game
genie.
And like a modem stuck on it and then they would like ROM hack more or less in real time
to add online multiplayer to like SEDS cartridges and then this was like a commercial product
that I didn't even hear of at the time.
Super cool.
But like I said, Xbox Live is sort of the first modern video game console network and
by that we mean there's a cohesive service sort of across the games.
Otherwise, these ‑‑ previously these networks have sort of been ‑‑ will provide
network services, but otherwise, you know, each game is sort of an island unto itself.
At release it sort of expected broadband to exist.
They did try to sort of support modems it looked like in development, but they didn't
actually release with that.
So it kind of set a standard of bandwidth of ‑‑ you know, you essentially have
to have been able to stream a simple Netflix, which is a nice very ‑‑ a very nice baseline
for these sorts of services we expect out of modern systems.
The Xbox shipped with a hard drive on the console, which was one of the ‑‑ might
have been the first to ship with a hard drive.
Was definitely ‑‑ yeah.
Was definitely the first to, like, expect that kind of large amount of storage.
That gives you enough local storage to be able to, like, update games, make sure everybody
is consistent.
It brought up DLC, which is ‑‑ you know, I've got mixed feelings about.
But it can be used for good and can be used for bad.
It was actually moderated for one of the first times.
So you can attempt to have a pleasant experience sort of despite the other people you're playing
with.
So these are all sort of new features and these are all sort of table stakes now for
a video game network.
So it's really interesting to ‑‑ at least in my mind, take a look at the first stab
of how these got created.
So we're going to jump right in.
The base protocol.
It uses ‑‑ it's all IPV4.
So if anyone has a slash 24 they want to give me for free, I'd appreciate that.
But probably not going to happen.
Uses DNS then to actually bootstrap up to the different services.
Ends up using Kerberos to work as sort of the off Z and off N component, which is kind
of actually really core to the security infrastructure.
And then there's always been this mysterious UDP port 3074, which is a custom VPN protocol.
And that's really the core of honestly all Xbox networking, including system link.
But is also the core of how boxes communicate to Xbox live and each other.
Is this VPN.
This is a VPN that uses the cryptographic attestations of identity from the Kerberos
to connect and communicate with each other.
So crypto primitives, this is where that historical context kind of comes in.
This is a great who's who of crypto primitives you really shouldn't really use anymore.
MD5, SHA1 for hashing, RC4 for symmetric encryption.
And DES and 3DES for symmetric encryption on the VPN.
Yeah you shouldn't use any of these anymore.
Microsoft agrees with you.
That's probably why Xbox original Xboxes aren't allowed on live anymore.
That combined with there were some of the other constraints.
And the Xboxes themselves.
All these Xbox live libraries are statically compiled into each game on original Xbox.
Something they fixed in the 360.
But they would have to go back and update release updates for literally every original
Xbox title to allow it.
So that sort of explains why they ended up cutting them off.
But still allow 360s which are pretty old.
So DNS.
Yeah.
We actually hit three different DNS targets.
There's Max which we'll get into.
AS and TGS are fairly standard Kerberos servers.
And then SG012N is the security gateway.
That is the VPN itself.
And then all other communications go through that VPN.
Other than talking to other boxes.
There's also if you get into the binary reversing you'll see hints of PartnerNet which is Microsoft's
private instances of all this stuff used for testing.
So it will be AS.part.Xbox live.
If you see that, that's what that stuff is.
That's Microsoft.
They can have that.
I don't want to touch that.
Or piss them off.
So.
Sweet.
So once you, you know, are up and talking to these servers, like we said, we're using
Kerberos for off to Z, off N. It's ‑‑ if you've played with OAuth, it's very similar
ideas from a very 1980s perspective.
We use ‑‑ it uses this thing.
It's called ASN.1.
Specifically the DER version instead of JSON for their communications.
And particularly they use tickets instead of JOTs.
Or tickets instead of tokens.
ASN.1 is this ‑‑ it's actually really interesting.
It's a sort of ‑‑ if protobuf had a ton of different possible encodings.
So DER is sort of a fairly bite‑packed encoding that kind of makes sense.
You'll also see that, too, in like exit 509 tickets are DER encoded.
If you care about every bit, there's a PEM encoding.
If you care about ‑‑ but there's also like a JSON encoding, there's an XML encoding.
It's ‑‑ it's really from the 80s.
And it's picked up a new encoding every time somebody cared.
It's also sort of a ‑‑ been a thorn in the side of security.
You know, particularly like blue team kind of people.
I guess been really nice for red team kind of people.
It's an extremely complex spec.
And a lot of our encoding for security purposes these days sort of takes ASN.1.
In context.
And tries to not be that.
And tries to be a lot simpler.
Because pretty much until the advent of memory safe languages, there weren't safe ASN.1 parsers.
Up through the 90s, up through the early 2000s, ASN.1 was really easy to find buffer overflows in for a very long time.
That's why we don't use it anymore.
But this is ‑‑ you know, sort of was what you used at the time.
Super interestingly, it doesn't use ‑‑ even though it's off C, off N, it doesn't use public private crypto.
There's no, you know, signed by a private key that could be validated by a public search.
Although that was technically added as a ‑‑ you know, a private key.
I think it came out in the extension to the RFC.
I think it came out in the newer RFC that's an option.
But that's not like the core of how it works.
And it's all about pre‑shared keys.
And having a key here and having a key here means I can encrypt in HMAC different pieces.
And then I can use that to then negotiate sort of the next key of the process in private.
This is all ultimately the underlying piece of how Windows domain logins work.
So your pre‑shared key in that case is your actual, like, password you type in.
On the Xbox, it ends up being keys that sort of were pre‑added to the console at manufacturing time.
And so it ends up sitting on ‑‑ there's an EEP ROM on every console that has all the keys.
All sorts of manufacturing time information.
And there's a little online key.
It's a heavily extensible protocol as well.
So there's these kind of arbitrary dumping ground of pre‑off data fields.
Microsoft ends up using these very, very heavily.
So we sort of skipped over MAX originally.
Which is the machine account creation service.
But MAX uses Kerberos but arguably to the point of not even being Kerberos anymore.
And is just using those pre‑off data fields to communicate not tokens but other information that we'll sort of get to right now.
So, yeah.
So MAX is the machine account creation service.
So original Xboxes ‑‑ I haven't quite figured out why this is the case.
They have a key available in the EEP ROM that was put there at manufacturing time.
Then an Xbox will use the Kerberos to convert that secret on the EEP ROM into a full account for the box itself.
And then ‑‑ yeah.
However, that account ‑‑ that key has exactly the same key length that was negotiated.
So it turns a 16‑byte key into another 16‑byte key for reasons I'm not totally clear with ‑‑ clear about.
Maybe they were still figuring out how the Xbox ‑‑ maybe they were still figuring out live.
And they just wanted to get all those pieces together at, you know, so that when they release live later, they'd have something.
I'm not really sure.
But we'll move on.
So it ends up using just standard Kerberos ASRex, ASReps to verify that shared secret, create an account.
And then from then on, the machine uses that account to ‑‑
present itself to the security gateway.
So like we were saying, there's a bunch of extra pre‑offs.
There's a client version that you sign with secrets, which basically tells you what executable is being used here.
So it ends up ‑‑ a lot of times it ends up looking like ‑‑ if it's just the machine itself and just trying to bootstrap this thing,
it ends up looking like ‑‑ I don't know.
The ‑‑ the Xbox's dashboard.
You've got this thing that they call the pre‑pre‑off that I don't really understand.
It just hashes the console serial and secrets in an interesting way.
The only thing that makes any sense to me is it helps some lookup that they have.
But it's not really necessary.
And it doesn't really add anything to from ‑‑ from a security perspective, as I can see.
Then there's this 131.
That's a constraint on user data in a way that's sort of meaningless.
It's a MS Kyle thing, which is another extension to Kerberos.
And then the current time stamp.
And otherwise, it sort of looks like a normal AS request.
request. Then the max service comes back to the console. It gives it a ticket. So like
we said, it's sort of like an OAuth token that doesn't make sense and gets thrown away.
In my case, I set the expiration to Unix epoch just to make sure it can't be used for anything.
And then it gives it an account creation preauth which contains the whole machine user identity.
The box ends up storing all of this on this partition space on the hard drive.
I have not really figured out why ‑‑ so there is this I want to say a half chance
meg space on the hard drive that isn't on any partitioned. I haven't really been able
to figure out why information gets stored there. The best theory I have is that the
‑‑ I can't remember.
The underlying storage there was originally supposed to be on a flash and they migrated
it because they didn't have an extra flash or didn't want to touch the flash or something.
But it's not really hiding that much because it's very clear from the binary what's happening
because it's the only thing that's opening the raw partition pretty much on the system.
So it's not really even a good obfuscation technique.
Maybe if you were looking at it but they're already using weird partitions and weird partitioning
schemes so it never really made sense but that's where it is.
That's what that partition space is.
Ultimately, all of that unpartitioned space is cached information.
So anybody who is super concerned about preservation of that unpartitioned space and afraid that
if they modded their console and never restored that piece, you can still get on live, all
that information isn't there, isn't necessary to get on live.
Live re-implementations.
Which is good news.
A lot of people were very scared that they had written their way out of being able to
be on live.
So users.
Users is a really interesting concept in Xbox live and this is probably one of the cooler
things that made me want to talk in front of DEF CON.
So a user on Xbox live is a very broad concept.
The most common thing that I've seen is a user on Xbox live.
The machine itself is a user in addition to what you would think of as people sitting
there with controllers in their hands in each controller port.
So the ‑‑ it's a really interesting take of kind of one of the first stabs of
like IoT security and this idea of the machine itself being given a full identity rather
than ‑‑ like.
For example.
For a lot of auth Z, auth N systems you see what device they're on end up being like
metadata for the user as opposed to combined ‑‑ like a user in its own sense and then smearing
users together into a combined authorization.
So yeah.
So boxes have their own ID.
And they have their own full ‑‑ they have their own gamer tags and ends up being like
SN.
Serial number and ends up being a ‑‑ I ended up sticking them in a different Kerberos
realm but I haven't been able to sign an original machine account so I don't know what
Microsoft originally does.
Just like regular users, machine users, they both have 16 byte shared secret that's the
‑‑ ultimately the ‑‑ the way you would call it.
bootstrapping of Kerberos, they have domains and realms which are basically namespaces
so you can think, you know, at blah, blah, blah.com, at blah, blah, blah.net.
Everyone has a 64-bit user ID.
Everything on original Xbox seems to start with 0009 for some reason, I don't know why
that is, but the boxes don't seem to care.
And then non-machine users will have flags and a passcode.
So there's this flags, if you ever ‑‑ there has two different concepts.
One is for guest accounts, if you ever wondered how that worked, you have the same XUID as
your host user.
You just have different bits in the flags that say, I'm a host.
I'm a guest account of this user.
Then the rest of the flags are things like I was a shit head and therefore I am completely
banned from speaking on everything globally.
And those sort of cross communications, black marks on the user are sort of put in there.
Also in the user account, they have the passcode which is a pretty simple keeping your little
brother from ‑‑ I don't know.
Getting on your account.
So it will just be AABB up down or something.
So that brings us to the actual authorization flow at this point.
At this point, your XBox is signed into max.
It's gotten a full account.
Then it moves into, you know, actually trying to connect.
And so this is a pretty standard Kerberos flow for the most part.
We end up creating a ticket granting ticket that gives you a cryptographic proof of identity
of the pre-shared key and gives you a ticket that you can present to the next piece.
It's sort of like an OAuth bearer token.
It lets you ‑‑ it essentially lets you prove that you are who you think you are to
other entities.
It can be a very multi‑step process.
This is sort of kind of what I was getting at where it will first build up a ticket granting
ticket with the machines account and then it does this combined identity thing where
it starts layering all of the other users on top of it and sort of smears all of the
identities together into this one cryptographic.
This is a really interesting concept and one I haven't seen used very much these days.
From there, we talk to TGS which is the ticket granting service.
So you give it a ticket granting ticket.
It gives you back a service ticket.
Pretty simple.
This will be a little bit ‑‑
Shorter time frames.
This will also ‑‑ you will tell it that you want certain back‑end services and it
will give you a ticket for those back‑end services for those users.
So at the end of the day, this is sort of another really interesting part and probably
one of the cooler parts of Xbox live is even before you are fully connected, you have this
cryptographic ‑‑
I don't know if you can see it but this is just a, like, attestation of identity that
is combined with which back‑end services you can talk to.
That's sort of the mid‑level of their back‑end system.
Which is really, really neat.
It sort of reminds me of how Facebook has added to their TLS connections on their back‑end.
The ‑‑ they really try to ‑‑ I don't know.
tag the identity of the user that was the cause of the request to everything so that they can
really track it through their systems very well. This could give you the same way to do that kind
of information, to track user identities through requests, to restrict users on a per-game basis,
per-user basis, and kind of handle it all very holistically, all underneath the individual game
protocols and all the other protocols, kind of what they expect. So it kind of brings it back to
other pre-auths. They've got 201, 202. So we have a service request, which is basically the game
saying, hey, I want to talk to Mac. I want to talk to Mac. I want to talk to Mac. I want to talk to
matchmaking. I want to talk to stats. And then the service address. You'll get an address of which
security gateway you can talk to and which underlying ports to talk to for both for the security
gateway. Well, so the security gateway is going to be on 3074, but also for the once you've
connected into the VPN, which ports you can talk to and which ports you can talk to. So it's
almost, it has very almost SDN kind of underlying components, which for something that was created
in 2002 is kind of nutty to me. So brings us to the security gateway. That's on, that's that port
3074. This is a custom VPN. It really looks like IPSec. Also really looks like WireGuard.
Which looks like IPSec a lot. It signs and encrypts pretty much all traffic. It's at layer two.
It smears TCP and UDP sort of into itself in a way that you also kind of see in IPSec to a degree.
It's very, very, very, very focused on saving bytes.
Wherever it can. I think some of that probably relates to trying to get this thing running
on modems originally, like it seemed like they were doing. Because they go to absolutely
heroic ways to save a byte here, save a byte there. Yeah. Cool. Here's the underlying
packet format.
So you have
the first byte contains padding and an op code. The padding tells you, so the encryption
for the actual payload ends up being, how about this, the padding for the actual payload
ends up being eight byte aligned, because that's the block cipher size. So the padding
tells you how much of the payload, how much of the block cipher goes past the payload.
You've got an op code. So zero ends up being control packets. Then you've got three each
for TCP, UDP, and another protocol called VDP. You've got three bytes for a spy. That
is security parameters index. That's essentially a session identifier. You've got payload,
which when we talk about that can just kind of be anything. So that will be for things
like TCP, that will be the actual fragment data. It won't be the headers or that kind
of information. For the control packets, it will be just kind of arbitrary data. Diffie
Hellman, it will be, you know, all the sort of pieces that need to be negotiated. Pretty
arbitrary amounts of data. For TCP, UDP, and VDP, you have, you know, a set of data,
have like a footer which contains what would normally be their header information in a
really cool but one of those ways Microsoft is going to heroic ways to save bytes.
If there's padding, so the protocol footer doesn't need to be encrypted, it will be signed,
but if there's padding, it can be stored up ‑‑ it can basically be optionally
encrypted if that helps you save bytes.
Because the encryption step will happen before trying to parse the protocol footer.
We'll have two bytes of sequence number, then there's also sequence number ‑‑ there's
also an additional two hidden bytes of sequence number where you just have to understand ‑‑
okay.
You just have to remember where you were.
You start at zero.
Once it rolls over, each side will bump up their higher bytes, but they don't actually
communicate that.
I think that's also true of IPSec, though.
That's not like a super crazy thing.
Then there's also a signature which is ten bytes of a truncated SHA1 of everything, including
the hidden sequence bytes with keys that were negotiated at the same time as the Diffie
Hellman.
Okay.
So one thing I am going to rag on a little bit is the way the signature check is computed
here.
It ends up being you do it over the protocol footer, then the header, then the rest of
the payload, then the sequence number, something like that.
It pulls them all out.
Which means that you have to do a significant amount of programming.
Processing of this packet to understand where the boundaries of these different pieces
are before you validated the signature.
If ‑‑ I mean, don't rule your own crypto is kind of rule one and two and three and
five.
But if we're at rule six and you are implementing your own crypto, just keep it simple and sign
everything in a linear way.
Don't ‑‑ don't force somebody to ‑‑ okay.
So, it's a little bit of a challenge to interpret something before they've been able to verify
the signature on it.
It looks like Microsoft did it right.
I didn't find any bugs in it.
It's just hard to get right.
And I wouldn't trust myself to get it right, basically.
Cool.
So, yeah.
We've got the control packets.
So it's up code zero.
A lot of Diffie Hellman parameter negotiation.
If you're shutting down the VPN to talk to it.
There's a piece for that.
There's kind of keepalives that keep the connection going and the service will kill it off if
it doesn't see keepalives in a while.
There's also ‑‑ interestingly, there's this event queue, too, that sits at this ‑‑ at
this protocol layer where a lot of server‑side events happen.
Okay.
So you're sort of at this layer two sitting underneath the TCP and all that where ‑‑ so
if you've ever seen, you know, your friend wants to invite you to a game or they started
playing another thing and it sort of pushes an event to your console and, you know, it
makes a little pop‑up, it ends up ‑‑ that event ends up getting pushed down at that
layer two.
Which is really interesting to me.
There isn't like a equivalent of like a web socket or something that they have.
I mean, obviously they didn't have web sockets in 2002.
But there isn't some higher level protocol that's being kept together.
But it's all sort of negotiated at this low level that these events are taking place.
Which is really interesting.
There's also a bunch of throttling and QOS management that happens in negotiating at
this layer.
The other op codes, we have UDP and TCP, but they remove a bunch of stuff.
If every packet is signed, then you don't need checksums.
I think they removed the urgent bit out of the TCP stack.
Which is awesome.
Urgent is awful.
I wish everybody could remove urgent.
Each of these has ‑‑ actually, I don't know.
There's only three op codes because they do a cute scheme where if your port 1024, then
you have ‑‑ you don't actually have to list the ports.
If you're within like 127 of that port, then you can list the ports as just single byte
offsets.
But if you're one of the other ports, you do normal two byte ports like you would expect.
There's also VDP.
That's UDP, but with part of the payload that is outside of the encrypted segment.
And that's where it stores voice.
Which means that voice in Xbox live is unencrypted in the air.
And that is ostensibly for lawful intercept.
So that, you know, the cops can get a wire and trace you and look at everything you're
saying.
So that is what that is.
Don't plan an insurrection over Xbox live, I guess is the point there.
Cool.
And then at that point, you have a full connection to the VPN.
You have a cryptographic attestation to your identity.
You have that identity also contains which services on the back end you're allowed to
talk to.
There's about 20 of them.
At least on the original I haven't checked in recently.
There's this one called presence that always gets used.
That essentially that's where you end up pushing your event that you are in a game.
And it ends up kind of being a dumping ground for a lot of pieces of the ancillary pieces
of Xbox live as well.
Games can have custom services.
So if you like, classic ones are MMOs will have custom services for their back ends.
So they'll just negotiate a different one and they'll connect through there.
Even if you're an MMO and you're running your own servers, all of these communications
still end up initially hitting this VPN.
Everything.
Is.
Kind of.
Encrypted through and through.
And is this one protocol stack?
Unfortunately, as I've been reimplementing this stuff, I played a lot of Halo 2 as a
teenager.
I kind of joke that I am doing this so that when I hit my midlife crisis, I have what
I want to do when I was a teenager as well.
But Halo 2 uses a custom service as well.
So it doesn't come for free.
But we'll have to.
I'm sure we'll get there.
These back end services actually tend to be HTTP.
They tend to be with custom binary payloads kind of on a per service basis.
But I wasn't really expecting something as forward looking.
Really, really strong inclinations that they're primarily written in C sharp ASP.net servers.
There's a lot of like .ASHX.
Which, in context, would have been like a beta version of ASP.net, I think.
Which is really, really, really forward looking for what, at least in my mind, for what,
you know, how to release Internet connected service for, you know, 2002.
And really, you know, once you have TCP up to just kind of treat everything as HTTP,
you know, it's not going to work.
It's not going to work for me for 2002 era was quite forward looking.
So kind of going through it.
Presence, like we said, always exists.
That's where client push events come from.
So like we said, there is that event queue where for server pushed events.
This is where the client push events for the most part end up coming from.
Matchmaking.
This is a matchmaking service that will for games that aren't.
Ranked.
For the most part.
But you're just trying to find somebody close to you.
Somebody, you know, maybe somebody close to your GOIP or somebody with, you know, low
ping for whatever reason ends up going through matchmaking service.
There's a strings service that I think does internationalization and maybe sanitization
for moderation.
So they can update.
These are the words you're not allowed to say.
And query.
There's feedback.
Which is this guy called me a slur.
So like moderation requests end up going through there.
Stats.
There's leader boards go through there.
You also the ‑‑ so I figured out a couple more of these since I wrote up these slides.
That also goes ‑‑ so for ranked matches.
That's where it ends up.
Building up your ELO or whatever algorithm is off of the stats information.
There's also an arbitration service that looks like ‑‑ a lot like matchmaking.
But it ends up generating sessions for ranked play.
Messaging.
You can send users messages.
Pretty clear.
Auto update.
This is, you know, one of those key pieces that was, like I said, kind of newer to Xbox.
Like I said.
It's live because they had the storage on each console necessary to do this.
Making sure that everybody is playing the same version of the game.
And then there's, you know, team management as a team service.
Let's see.
Oh, and there's also a NAT detection service that will let you do, you know, NAT punching
and at least NAT understanding.
A lot of the NAT stuff is actually interesting.
Because by sticking everything.
On that port 3074.
You get a lot of NAT punching sort of for free.
Because you've already communicated to the external services.
And so, therefore, any incoming game requests can also come in on that port.
Because you've already done 80% of NAT punching.
So it's kind of a nice way to do that.
Sweet.
So then we have match ‑‑ or just drawbacks.
Joining a game session.
What does that look like?
So you end up using the match making service to query for or sort of create a session.
That session information ends up containing a host and a lot of the, like, random parameters
of, like, what a game will contain.
So there will be a session identifier.
There will be a key exchange key.
Which lets boxes talk to each other without Diffie Helming to each other.
Once a box gets a list of potential hosts to join a game in, they end up logging into
that host with more or less the same VPN protocol.
So this ‑‑ that VPN is ultimately the kind of base layer of even that piece.
And system link as well.
Okay.
Yeah.
And we already covered NAT punching.
System link.
Yes, system link is about the same.
You'll throw out a broadcast packet with essentially the same key.
But will ‑‑ so it will be like a per‑game key that's on the disk.
So we're going to give it a key exchange.
so they can see each other's game announcements and then the ultimately the host box will set up
a vpn server and the other boxes will vpn into it and that's how system link ends up working
and it looks like actually games don't have a tcp stack other than based on this to this uh
vpn protocol so they couldn't even do anything if they wanted to
um cool uh how do you go about reversing this stuff um a lot of staring at gedra uh there's a
really uh i want to give a shout out to whatever contractor had to add xbox executable support to
gedra um it probably didn't need to happen at that point anymore and he probably was wondering what
he was doing with his life uh but uh i really appreciate it it's probably one of the best uses
of my defense dollars
um going looking at it uh gauntlet dark legacy ships with a pdb just on the disc
it doesn't have the uh online capabilities but you can kind of get your bearings about like what
an xbox game looks like uh red star um is an online game that ships with the full symbol
map including the online uh shared libraries um jedi knight jedi academy is uh gpl'd
their xbox version and that includes uh
all of the online components uh not the microsoft code directly but how to call it
and then in every executable xonline and xnet is broken out uh into separate sections uh xonline
is the online component xnet is what you just need for a system link uh and contains the the vpn stack
essentially all crypto is cleanly exported by the kernel so you can see that on the import list
um you can go here github.com zombie online zombie is agpl source for re-implementation
uh very proof of concept uh prs are welcome zombie.org whenever i end up updating dns
entries will be where you go to sign up for an alpha uh to get at it back online um and uh
yeah i mean i kind of want to move the industry towards um a theory of software security harm
reduction when it comes to network services where um and so kind of where i'm at there is
people are gonna use software now online that they can't update anymore which is
i mean you know rule one is don't do that but people are gonna do that
so i've got i'm open sourcing a lot of this stuff to really start thinking about how we can
protect people even in these very unsafe conditions and very like start opening things up
and shine you know doing so by shining a light and sort of adding knowledge um
and uh i don't think we have time for the demo is given and i don't think it's gonna work yeah so
sweet
you