Print

[Anarchy99]

theoretically wouldnt it be possible to emulate xbox lives service for match making and such(although probably difficult because of encryption and such)
then just with some dns magic make the xbox think its connecting to xbox live when really its connecting to "open xbox live" which would hopefully be a clone of the real thing minus banning.
i think thats where we should be focusing our attention because then who gives a $#!& about ban waves because we could still get the multiplayer features needed.
has any group attempted this or is attempting this?

i just think that the community is to content with the status quo (bannings or xlink with the 30ms ping limitations)
and yet ive never seen anyone post dumps or discuss xbox lives encryptions even though server emulators are a big part of unofficial multiplayer for many pc games especially mmos some are even very simply written in python and such just coded to pass on "valid checks" and there very cobbled together

just curious because it seems weird that we have never heard of this

thanks

[Xizer]

Too much work when you can just get superior PC versions of most Xbox 360 online games and play them without having to deal with the Xbox Live bullshit.

[yoss]

Live payloads are encrypted. SO if you can crack the encryption I'm sure there are lots of people willing to do the rest of the work for you

[torne]

Live is authenticated and encrypted with MS-Kerberos, or a variant thereof. Emulating live for an unmodified console is almost certainly impossible. You would need to be booting a modified kernel which had security features patched out of it.

[Camedo]

It's not impossible, just very difficult. With a strong effort, i'm sure the community could crack the protocol open.

We just need to remember the potential this could have. If your Xbox 360 was convinced it was talking to a real LIVE server?

You could, among other things:
 Download movies, music and TV show from the net - for free.
 Games on Demand, straight to the Xbox - for free. (Without flashing!)
 Play games online - NOT System Link emulation, actually online.
 Use Banned Consoles online - We don't give a damn if you mod your console.
 Run Homebrew! Finally!

There's an insane amount of possibilities. Redirecting the XBOX Live connection isn't hard - just roll up a package with a DHCP and DNS server into a little bundle and point the Xbox at it. It'll try to DNS lookup LIVE servers and get stuck with fake IP addresses pointing to the fake Live server.

Of course the protocol is trickier to emulate, but not impossible.

[torne]

As I already said, emulating Live for an unmodded console probably *is* impossible. Protocols secured by public key encryption are impossible to emulate without modifying the client, or finding a security flaw in the implementation.

However, now there are rebooters which can boot a patched kernel, so you could change the keys that the xbox uses for the kerberos authentication. It would still be spectacularly difficult to reverse engineer the protocol and reimplement it, though

[shivadow]

Did I see someone mention the cost of the servers and bandwidth?. Oh, thats right I forgot that everything is free in mommy-buys-me-everything-land...

[BoNg420]

QUOTE(Xizer @ Nov 25 2009, 09:24 AM)

Too much work when you can just get superior PC versions of most Xbox 360 online games and play them without having to deal with the Xbox Live bullshit.

XBOX live bullshit > spending $500 every 6 months on new video cards.

[Datenshiz]

I was thinking about this yesterday but got my thread closed as it was in a different part of these forums, either way. The Xbox live communication uses i think the DES encryption algorithm, if its somehow decrypted the rest wouldn't be THAT hard.

The Kerberos model does, however, have certain weaknesses:

    * In Kerberos IV (the version of Kerberos used by AFS and Zephyr) all encryption is performed using the DES algorithm. While DES was considered "unbreakable" at the time of the release of Kerberos IV, it is now believed that a sufficiently motivated miscreant could, with only modest computing resources, conceivably crack DES encryption in a relatively short period of time. Some researchers have, in fact, been able to do just that under certain specific circumstances. Since the trustability of Kerberos authentication depends entirely on unbreakability of the underlying encryption technology used by the system, this poses a threat to the security of Kerberos IV. In the current release of Kerberos, Kerberos V, support is provided for "plug-in" symmetric encryption algorithms. Kerberos V systems can use, for example, the much more secure triple-DES or IDEA encryption algorithms. The overall structure of Kerberos V remains the same as that of Kerberos IV. Webauth, for example, used 3DES keys to secure services (more on Webauth later... :-).
 
   * Kerberos was designed for use with single-user client systems. In the more general case, where a client system may itself be a multi-user system, the Kerberos authentication scheme can fall prey to a variety of ticket-stealing and replay attacks. The overall security of multi-user Kerberos client systems (filesystem security, memory protection, etc.) is therefore a limiting factor in the security of Kerberos authentication. No amount of cleverness in the implementation of a Kerberos authentication system can replace good system administration practices on Kerberos client and server machines.

    * Because Kerberos uses a mutual authentication model, it is necessary for both client machines and service providers (servers) to be designed with Kerberos authentication in mind. Many proprietary applications already provide support for Kerberos or will be providing Kerberos support in the near future. Some legacy systems and many locally-written and maintained packages, however, were not designed with any third-party authentication mechanism in mind, and would have to be re-written (possibly extensively) to support Kerberos authentication.
 
  * The Kerberos authentication model is vulnerable to brute-force attacks against the KDC (the initial ticketing service and the ticket-granting service). The entire authentication system depends on the trustability of the KDC(s), so anyone who can compromise system security on a KDC system can theoretically compromise the authentication of all users of systems depending on the KDC. Again, no amount of cleverness in the design of the Kerberos system can take the place of solid system administration practices employed in managing the Kerberos KDC(s).

This post has been edited by Datenshiz: Dec 7 2009, 02:36 PM

[Martinchris23]

Surely it would be a better venture to be looking into removing the 30ms ping limit on system link games for XBR/FreeBoot enabled consoles? I know some games are better via XBL but with the likes of MW2 having some excellent system link playability, it would be a good compromise.

[torne]

QUOTE(Datenshiz @ Dec 7 2009, 01:28 PM)

The Kerberos model does, however, have certain weaknesses:

Pretty sure you copypasted someone's description of "problems with Kerberos" without understanding a word of it (IMG:style_emoticons/default/smile.gif)

QUOTE

    * In Kerberos IV (the version of Kerberos used by AFS and Zephyr)

This one is irrelevant; MS Kerberos is derived from Kerberos-V and uses much better algorithms than DES.
 

QUOTE

   * Kerberos was designed for use with single-user client systems

This one is irrelevant; Xboxes are single user client systems.

QUOTE

    * Because Kerberos uses a mutual authentication model, it is necessary for both client machines and service providers (servers) to be designed with Kerberos authentication in mind.

This one is irrelevant; this is about the difficulty of retrofitting Kerberos on existing systems. Amazingly the Xbox was designed with Live authentication in mind.

QUOTE

  * The Kerberos authentication model is vulnerable to brute-force attacks against the KDC (
the initial ticketing service and the ticket-granting service).

This one is irrelevant; nobody is going to be cracking the Live KDC any time soon. (this is talking about attacking the *computer that runs the KDC*, e.g. by bruteforcing the root password, not attacking the protocol)

Well done (IMG:style_emoticons/default/smile.gif)

[Datenshiz]

Yes its copy pasted, never claimed i wrote it either, thought it was pretty obvious, especially as my English suddenly improved 1000%.

Now maybe you would want to clearify the problems with these ideas as you obviously seem to know a lot about it already?

Well Done. (IMG:style_emoticons/default/smile.gif)

This post has been edited by Datenshiz: Dec 8 2009, 01:55 AM

[torne]

If that's not clear enough for you then I don't know what to say

[Datenshiz]

In what sense did your previous post explain anything except that what i pasted about Kerberos didn't pertain to xbox live? You haven't clarified anything, remotely necessary to this topic. Whats been clear is that you're just a douche with nothing to bring to the table other then pissing people off with your arrogant attitude.

This post has been edited by Datenshiz: Dec 9 2009, 01:35 AM

[torne]

I try, really. I assumed you meant the problems with your 'suggestions' for breaking Kerberos. I'm guessing you mean "why can't we emulate Live" when you say "the problems with these ideas", then?

Quoting myself:

QUOTE(torne @ Nov 25 2009, 03:52 PM)

Live is authenticated and encrypted with MS-Kerberos, or a variant thereof. Emulating live for an unmodified console is almost certainly impossible. You would need to be booting a modified kernel which had security features patched out of it.

This tells you what the first step is: reverse bits of the system until you find the code that handles Live authentication (the MS-Kerberos client implementation) and work out how to patch it with Freeboot/XBR so that it will accept a different set of keys for the servers. There is a tiny probability you might find an actual exploit in this code (see the recent spate of SSL client implementation vulnerabilities for the kind of thing you want to be looking for) but you probably won't.

The closely related second step: you will need to be able to look at the communication between an xbox and the real Live servers in plaintext, otherwise you have no hope of ever understanding the protocol. To do this you will need to patch the system with Freeboot/XBR some more, so that it leaks you the session keys in order to decrypt the traffic with a PC, or so that it just leaks you a copy of all the decrypted traffic directly. The minor difficulty here is that it probably won't be very long until MS implement checks which detect XBR/Freeboot, since the current versions make no effort to hide themselves from detection, and you'll get banned, so you might need quite a large supply of keyvaults/xboxes to get this one done.

Once you've done both of those things you are now at the point where most PC-based server emulation projects start: you have the ability to change where the client connects to, and you have the ability to monitor the traffic to the real server for reverse engineering.

Is that helpful enough?