Hello!

i have an request for everyone who wants an alternative live server
maybe it's possible too fake a live server, but to do that, i need packets of an xbox signing in too xbox live.
namely the kerberos packets on port 88.
if we can fake an Live! kerberos server, the xbox can login to it.
then we can decode the packets send by any game, too find out what they are sending in plain tekst ( not encrypted ).
so... if anyone has any ethereal packets where the kerberos signin is in ( unbanned ).
i love too get them.
you will all be greatly rewarded

C'mon nobody has any packets or something?!?

This project is so utterly complex for a few reasons:

Xbox games use a series of cryptography techniques to encrypty and decrypt data. First off, all packets are signed with what appears to be DES encryption. Which is basically 54bit encrypted data, the only useful way to aquire the key for cracking the encryption would be to retrieve it from what I am calling a handshake packet.

This handshake packet is sending out various bits of data about each xbox using what looks like a custom algorithm developed by MS.

The problem we face is the lack of network source. The XDK isn't good enough for this, the XDK provides libraries to interface with this functionality, but will not allow us to replicate any encryption keys due to the fact that we have no way of knowing what an idividual program is sending.

I'm not saying it is impossible, but the complexity of Xbox Live is way past any reasonable work.

from the xdk docs. it uses either kerberos or diffie-helleman
if we can get the handshake packets you can figure out the way it's hand shaked and decrypt/encrypt packets

I think I realized something the other day. This isn't live related, but syslink related.

I read the xdk docs awhile ago so this might not be 100%, but from what I remember, there are two forms of encryption going on. The first is the session key created during the first packet exchange between client and host xboxes. You can tell which of these are encryption handshaking packets because of a flag set in the packet (this is in the SDK whitepapers on the topic).

IIRC (which I probably don't), the other encryption used is to make a signed checksum of every packet so that they cannot be modified. The question I used to have was.. how does each xbox know the secret key used in this checksum procedure? I think I figured it out, though. It's the LANKey stored in the XBE header for the game.

So, one has to figure out how to take a message M, and compute the signed hash h(M, LANKey) that matches a signed packet. Some options:
single-block DES encrypted CRC
carryover of the last round of CBC DES encryption on packet
variants of above.

With this in mind I'll re-read the xdk docs and see if anything else comes to mind.

Cheers,
Tom

I've been interested in exploring this for a while now. It would be cool to be able to fake a connection to Xbox live, and/or run your own server.

I was looking through my EEPROM. There's 2 keys. (Well, there's more, but I'm concentrating on these 2) One is the LAN key which syslink uses. (Games send the signature to the host box before signing packets.)
And the other is called a Live key. I intercepted Halo 2 packets. The first packet it sends is the key telling Xbox Live that Xbox's signature. After that every other packet is signed using this key.

I hope this research helps.

ok, so all packets are encrypted using the Live! key?
...so do we know the decryption scheme? or does it uses another key system...
if it only uses the Live! key we can decrypt (and encrypt) packages to/from Live! servers...

If u can get the encyrption key, u can hook up a man in the middle to spoof a signal to live that that the Xbox is stock. or u could just spoof the stock-check the xbox does when it boots up and therefore skipping the need to encipher it in the 1st place. I dont think that nessicarily this will be most useful to people who got banned tho...

and wait isnt this alot like Mimesis??? if u have questions ask them

This has nothing to do with Mimesis. Mimesis is simply a modded content provider for which you need their app to use. It doesn't integrate or emulate Live in any way.

As you put it so well:

Not quite.
The first packet sent by a client to a server in a syslink connection contains nothing more than a nonce (a random unique ID). The server (who receives the nonce) generates the public parameters for the DH authentication and sends that to the client. I have to look at this again, but I'm pretty sure that is the order.

Definitely true:
The key is generated using diffie hellman algorithm between the two xboxes. It's different every session. If we could modify these packets, then we could set up a man in the middle attack on system link. live is a whole other story.

However, the first thing we need to do is figure out how every packet is authenticated. The last 10 bytes of every packet is the XHash of the packet, which is a cryptographically signed hash. Who knows what it is.

As well, when the client and server agree on a key with DH, they use it to generate a table of keys (not just one), and then in the header of each packet it gives an index to the table for which key to use for encrypting the packets. Who knows how they generate these keys, it might be something as simple as, given key1, key2 = des(key1), key3 = des(key2).. etc.

Why would I ask the team I'm on about something like this? I'm pretty sure everything we know has nothing to do with Xbox Live! besides the DLC format.

I've said it before (on the same subject) and I'll say it again. For a Live! emulator you need someone with broad knowledge of encryption, x86 assembly and a lot of spare time.

These are not a subjects you can handle by reading tutorials, you need to have been in the business for years in a row.

i agree with the encryption sceme.
i'll get an extra network card very soon so i can capture packets myself.
but on that x86, that you must code in assembly x86... why?
you need to know something about encryption
and i thought i read in the xdk docs that they use an kerberos encryption thingy
and you don't get banned for capturing Live! packets

i found some interesting stuff...
i've captured some packets using ethereal, and found out it DIDN'T acces port 88.
not even one time!
it uses some weird ports through...
if you want the captured packets send me an PM.

You really dont so much. If u could capture a signal from a stock xbox while connecting to live and sacrifice a free trial for a non-stock connection then u could compare the two. Just get a few diff boxes, and chk all their important info and see if u can see it in the messages. or u could find the information about how to see it by watching the xbox encipher it in the 1st place. that would probably be the better idea.

no, seriously, you're wrong. Without knowing how to decrypt the messages you won't see any difference between stock and modded xboxes connecting. The first thing you'll notice is that every time the same xbox connects to live you see completely different packets. You don't know how to decrypt messages without knowing the precise implementation of the algorithm in use. The only realistic way to do this is to reverse engineer the functions in the socket library.

I might've read it somewhere in the XDK whitepapers (very quick), but I thought all traffic is encapsulated in UDP, for compatibility with routers that do NAT (google for "NAT punch"). That means there is first the UDP header, then a TCP / UDP header, and then the payload. It's possible that those second headers are encrypted already, I don't know for sure. Logically, it's also possible that the payload for the first _encapsulated_ packet is continued in the second packet, like with segmented TCP (or IP over ATM, I forgot bigtime) frames, so it will be more of a mess.

Maybe you can find the bytes for 88 (0x58) at a logical position somewhere in first captured packet, check the TCP reference and write a Ethereal filter based on that. Oh, and I also heard MS cut out some "useless" bytes here and there in the TCP protocol to save on bandwidth, so good luck with that

d0wnlab is right, "comparing" won't help here, although I think it is one of the basics of reverse engineering, in this case you'll only have 2 sets of byte noise (haha "white noise" you get it? oh the wit ), nothing usefull.

if you want i can post the logs somewhere...
i'm not really good with ethereal...
i've captured some things (login logout doing nothing starting a game...)
so...

Correct. All traffic is literally on udp port 3074 (syslink no exception.. i think this applies for live as well). They have modified tcp/udp headers inside these packets.


I'm pretty sure, in system link context anyways, the only things encrypted are the payload and.. shoot. One other thing. Can't remember atm. But not the remainder of the contained header. It's very well laid out in the XDK documentation (or so I've heard)

i will look up the captured packages...
there are some weird ports in it though...
some other ports than 3074 and only ingame...
i've looked up the first message send
and one of the first data bytes (after the UDP header) are the hex 58 ( that's decimal 88)
it's the six'st byte after the data start (before that comes an UDP header etc)
but after the first 2 packages the whole package changes... it get's smaller (really smaller)...
the six'st byte is the port when the captured message size is:1378 bytes...

you can get the first two packages here:First Data packageSecond data package

i've tried another game... (conker live&reloaded)
and in that live signin it did send some kerberos packages...
maybe it's just my pc so i will rerecord halo 2 live packages...
ethereal sais the of the request kerberos package that the encryption type is rc4-hmac
yes it was just my computer; halo2 also sends kerberos packages

Oh joy! Finally, someone else has decided to look into this... Most people I've spoken to wanted no part of it because they feared the big, bad M$. Apparently misunderstanding the fact that I in no way intended to "hack xbl". If any of you care to take the time to read through the topic regarding this, you might find some useful info that was found researching other methods.

Deconstructing XBL

I initially attempted to try to figure out how the xbe files connect to xbl, THEN go about how to initiate handshakes between them. As you'll find in the topic, there are 3 servers used by live for various handling. If we could eliminate the need for the authentication checks (i.e. serial/mac address etc), then that would be one less thing we'd need to worry about "emulating"... anyways, a lot of my comments may seem n00bish or naive, but I mention many times my lack of programming knowledge. Definitely not my strong suit lol.

@d0wnlab, As much as I want to see this project take off, don't forget about those of us quietly following the progession of OpenDash Excellent work from what I've seen thus far. Definitely looking forward to the next public release.

btw, since I can't edit my original post, just thought I'd mention that the previously posted thread did ultimately yield some results (anyone heard of Mimesis)?

I'll continue to quitely plug away at this on my own. I still don't doubt that there will eventually be a way to play any/all xbox live enabled games online... FOR FREE! Good luck gents.. enjoy!

edit = stupid punctuation...

Hello, remedee

i'm trying too figure the live connecting out myself...
and the thing i figured is it uses kerberos as packed distributing.
as.xbox.com is the kerberos application server
that distributed the encryption keys
btw, from the ethereal information it uses rc4-hmac as an key destribution system...
(in what type of encryption)
and btw, why would you fear something from MS?
they can't sue you for something that's legal (at least packet logging is legal)
btw, just came trough my mind.
the best way too reroute Live! is though an "fake" dns server somewhere on the internet
just an public dns server with all xbox.com and xboxlive.com Live! addresses (as.xbox.com etc) rerouted to the fake Live! server

look at this:http://www.ietf.org/internet-drafts/draft-jaganathan-rc4-hmac-01.txt
that i found in google using rc4-hmac windows
because ethereal sais that the key is rc4-hmac...

Tp21, I did get your PM, but the server keeps rejecting my response, saying the servers are too busy. Anyways, for the rerouting of the DNS servers, I understand WHY it seems like it would be easier to do it that way, but rest assured if you put a centralized server up somewhere (or anything with "xbox" or "live" in your own server), M$ will be all over that in a heartbeat (nevermind how many ppl would be banned by accidentally hitting the actual live servers in a modded state). Thats a big part of why I initially considered the idea of patching the xbes to look for another server. That could be a difficult way to go about it, but at the same time, as I said in the post, patchers for xbes aren't terribly difficult to put together. Just an idea.

The other one, that made a lot more sense to me was to somehow do it at the bios level. Meaning there are no modifications made to the xbes. Consider this...

Most bioses, as well as nkpatcher utilize Live Blocking to avoid getting yourself banned. With that in mind, rather than block the traffic, route it to your personal dns server. Nkpatcher is fairly easy to modify and for this reason I think would be a better choice.

Now doing this at the bios level completely removes the need to modify any xbe files, therefore allowing even retail games to be routed. If Nkpatcher could be modified to hook the calls to the 3 xboxlive.com servers required, and route the traffic to whateverfakeserver.com on your network, then it stands to reason that it may be a bit easier to determine which traffic is required, and which can be left out.

Just a theory:
Game attempts to connect to "live" -> nkpatcher intercepts, returns "success" or whatever to the games request for authentication, but allows game traffic itself to pass to the server.

I'm obviously not going to sit here and say that the authentication can simply be left out, or that it'd be easy to return a successful request to the game, which is why its a theory. But, it may spark some ideas as to how to go about it.

Ok, I have a ton of stuff floating around in my mind right now, and this has gotten much longer than I intended already lol. Keep me posted on your progress and I'll let you know how my talks go with modifying nkpatcher to reroute traffic to a random server.

Public service announcement:
What you are trying to do here is NOT legal. It violates the anti-circumvention section of the DMCA. The people who reverse-engineered Blizzard's Battle.net service and released their own free service were sued and lost. They also lost on appeal, and there's practically no chance the Supreme Court is going to take up the case. So if you do somehow manage to break the encryption and authentication protocols, MS will come after you and they will win. The case law is on their side.

Blizzard v. Bnet.d

Actually I'm interested in cracking System Link encryption to look for buffer overflows in network code as a potential way of booting linux, which is clearly outlined as an exception in 1201 (f) of the DMCA.

Not that that really matters since I'm a Canadian and these here servers are hosted in the EU (iirc).

Fair enough. I'm still not entirely sure why Kai/XBC etc. are able to operate without issues though. Is it because they are simply re-routing network traffic, without making any modifications to the xbox system or software? That seems logical, I'm just trying to better understand why one way of modifying network traffic is acceptable, but not another. TIA

Kai and XBC do not crack anything. They just take xbox traffic on one lan, tunnel it over the internet, and recreate the packets on another lan. That combined with "rooms", etc, and you have a tunnelling service. Just because they're routing the packets does not mean they know anything about them.

does anyone know how the system link packets are encrypted (probebly using the system link key thingy in the xbe)
but does anyone know?

Can't really help you much there...

Anyway, the theory behind changing the IP from within the XBE could work, but as was mentioned in the linked-to thread, why not redirect the DNS through the PC, instead of the xBox? It may be possible through the hosts file, so when your box tries to resolve as.xboxlive.com, it'll resolve to youserver.net.

Of course, this is still only a small part of the puzzle...

i've just found something cool in the xdk documentation: if you open up the help file thingy, and search for link and click the found link xbox secure sockets, you'll learn a LOT about the things used to send/recieve xbox packets.
for example, the encryption used xbox<>xbox is DES xbox<>SG(security gateway) is 3DES (58bit).
there is even the packet size etc!
even how the hash etc is created (for some part)!

Sort of on/off-topic. I just started thinking about the Live-emulation stuff this weekend, and started researching it today on the forums/web, and haven't really noticed anybody mentioning my primary reason for wanting a private Live server:
New games coming out, if you haven't noticed, are supporting System Link less and less in favor of pushing Live. Which is ridiculous! The new Tony Hawk, the new Burnout... each have multiplayer options... for Live only!

Completely unacceptable. The network code is there, they simply chose to gouge more money rather than enabling the functionality.

For this reason, a private Live server becomes necessary just to play games which can and should be LAN enabled in the first damned place!

Infuriating!

It is infuriating. Same with Battlefield: Modern combat - it didn't even HAVE system link. That's a slap in the face.

Have fun emulating a live server, though.

yes, you're absolutely right!
but the problem is, we don't have enough people that know (enough) about encryption, and networking (and programming, etc).
it IS very possible to emulate a live server (a hell lot of work, but possible)
but we just need more people.
btw, if you read the XDK documentation, you find out a LOT about live!
it uses DES (and 3DES for login) as encryption, and (for live) XK(Xbox Kerberos).
(system link uses diffie-hellman)...

Lol if i mean if u guys get this on the way U could call it Mimesis Live

any ways if u guys ever get a version running i have a server on 100mbs u can use that

Another approach I've heard mentioned is to patch the XBEs (possibly to redirect direct toward SysLink libraries, or at least to prevent the traffic encryption) and then implement a clear text XBOX!Live-lite server.

This throws up it's own set of challenges, but may be more realistic than cracking XBOX!Live.

Also, due to the XBEs usage of libraries, once achieved, patches for games should come quickly.

Inspiration:
"If you can't beat 'em...change the rules!"
"Can't play the game anymore...change the rules."

I know this is going to sound like a Total nOOb question/suggeestion...

But surely the way in which I would imagine the Xbox handling the Live traffic would be like this:

Game (app) sends request to Live service -> Live service handles all encryption -> sends packet to M$ live server.
M$ Live server send reply packet(s) -> Live service decrypts packets -> send to app (game)

It would be an absolute nightmare for a s/w house to start coding their own modules to handle the live traffic, it would to me, be far simpler just to send the data intended for the live server to a transport service (Library server) and let that routine handle all comms to a from the M$ live server(s).

Surely all we want to do, is create an alternate transport service? one that doesn't encrypt/decrypt the packets (improving speed) and send them to OUR server on OUR IP address?

Maybe a shit idea, but if you think about it, what libraries are installed by the LIVE installation disc? and what do they do? then modify THEM and see what happens?

T.

Just wondering if this idea is dead, or I can follow the progress somewhere else?

yeah, it's pretty dead...

Now theres an idea!

That makes sense, I mean think about it.. of course xbox live is encrypted to hell. Its a paid service!

But if you could make live games run system link libraries instead then we could use xkai or better yet. Setup a vpn server for our own syslink/live!

That would be amazing! Granted it would still be hard and I'm sure every game would be difficult/different to modify to use such libraries but I think this can be done

Most of the great games for the xbox 360 are available for PC so here is an idea. Buy your games for PC instead of the 360 and you can play them online for free.

Microsoft can't sodomize you unless you allow it.