Print

[Spree]

Zander what about this....

what if the update to xbox live checked values against the modschip causing a test failure.  Then it changes some of the hex values in the eeprom.  Now when you try to login to xbox live your hashed from the start.  Because all it has to do to hash you is check the specific value that you no longer have.  If this is the case then what we need is a map of the eeprom to understand what values have been changed.

In the eeprom there are going to be sectors for serial #, xboxlive info, and various other things but if we could do a comparison against unchanged eeproms we should be able to seperate what is the serial and what is the other changed info.  Then if we cloned only that information we should pass the test and not get hashed.  This is how it works for the eeprom for dss systems except dss is a little different since we are implementing jumps to bypass the information we don't have.  We don't have to write new code here we only need to replace the correct code.

This is where it sucks to not have a copy of our old eeproms cause if we did we could probably just copy that back to the eeprom and be ok.  That is my theory anyway.

[Fuzzy]

i said we have to compare eeproms in my other post and you disagreed...

[Spree]

zander,

is it possible to access the eeprom with evox.  Can we dump it to do a comparison or is this not yet possible?

[Zander]

Dunno man, i don't run evox, nor have I ever compared eeproms. I'm not a chip guy, I'm a network guy.

Z

[Spree]

I keep everyone talking about eeprom.bin and if we had those bins we could compare them to see where the differences are and maybe we could adjust them.

[upstatenyguy22]

QUOTE (Spree @ Nov 19 2002, 02:00 AM)

This is where it sucks to not have a copy of our old eeproms cause if we did we could probably just copy that back to the eeprom and be ok.  That is my theory anyway.

                                    We do have a copy of our old EEproms - at least we all should.  When you first hit backup from the evox dash (you know, like before you ever did anything with your xbox and screwed with live or a new HD or anything, the one you burned to CD for safe keeping just in case like all the tutorials tell you to...) included in c:\backup is eeprom.bin - your current eeprom.  So you can fairly easily use eepromagic then to restore that old eeprom - which I have done, I'm sure opjose and a number of others have done.  Problem is it makes no difference.

Some things are similar to DSS here, but DSS has to use the hash and eeprom updates because it's one one satellite to your card - with MS, since we have to log in to live, they can easily implement this ban from their server-side, sending us bogus packets or denials or whatever they chose, rather than having to mess with switching flags in the eeprom.

[Zander]

This also follows established RFC rooted standards, like kerberos.

Z

[Pr0crastin8r]

ermmm.... i think i have a copy of my old eeprom... let me go check...

[Pr0crastin8r]

HAHA! I have it!  It's dated OCT16.   I'm going to go and compare checksums with my current banned eeprom.  would changed network configs etc get stored in the eeprom and thus alter the checksum?  or is the eeprom pretty much gonna stay the way it is?  

anyway, if you guys want them for comparison I should be on IRC in a bit.

[Pr0crastin8r]

BAM, got my banned one off the xbox. now signing onto irc...

[Pr0crastin8r]

somebody on irc (i think it was virtudude? not sure) told me that he had already compared eeproms and they were the same.  anyway... i still have mine if someboyd wants to check em out.

[Spree]

I'm not able to check IRC tonite can you post some results here.  I'm sure there has to be some differences.  I don't think that it is a banned serial bc otherwise there wouldn't be differences in the xyz and that is specifically what they have been looking at everytime I have talked to them.

[opjose]

Zander:

I can verify that the MAC address is directly tied to the serial number of the Xbox.

I've been able to generate a valid eeprom (but not valid as far as XBLive is concerned) by decrementing the low order byte of one number in the serial and the incrementing a byte in an adjacent low order byte of another number.

This old CRC trick gets the Xbox to accept the checksum and headers as being correct. However the MAC then is seen as screwed up.

By performing the same trick on the MAC address you can get a working eeprom. However there is something more to it than this, somehow the header values (I believe) are tied to the Serial/Mac keys, although it could well be that the online serialization is at fault as I have not had a chance to try this.

So far EVERYTHING you have said mimics what I have seen in packet sniffing attempts, though you are now a bit further than me.

Yes, there -ARE- holes all over the place eh?

I'd imagine a linux patch sending the same packets obtained during an initial negociation of an unmodded (or better yet modded system with the chip switched off but the drive locked) would do the trick as the eeprom values which are sent do not change subsequently.

If we could intercept the exact sequence which gets the Xbox to reveal if it is modded or not, then a filter of some sort may be possible that would replace the "I'm modded" packets with ones from a virgin Xbox (e.g. from the same Xbox before modding), and BANG... Kerberos is none the wiser.

Great stuff BTW!

[ArMaGeDdOn]

QUOTE (opjose @ Nov 19 2002, 06:27 AM)

Zander: I can verify that the MAC address is directly tied to the serial number of the Xbox. I've been able to generate a valid eeprom (but not valid as far as XBLive is concerned) by decrementing the low order byte of one number in the serial and the incrementing a byte in an adjacent low order byte of another number. This old CRC trick gets the Xbox to accept the checksum and headers as being correct. However the MAC then is seen as screwed up. By performing the same trick on the MAC address you can get a working eeprom. However there is something more to it than this, somehow the header values (I believe) are tied to the Serial/Mac keys, although it could well be that the online serialization is at fault as I have not had a chance to try this. So far EVERYTHING you have said mimics what I have seen in packet sniffing attempts, though you are now a bit further than me. Yes, there -ARE- holes all over the place eh? I'd imagine a linux patch sending the same packets obtained during an initial negociation of an unmodded (or better yet modded system with the chip switched off but the drive locked) would do the trick as the eeprom values which are sent do not change subsequently. If we could intercept the exact sequence which gets the Xbox to reveal if it is modded or not, then a filter of some sort may be possible that would replace the "I'm modded" packets with ones from a virgin Xbox (e.g. from the same Xbox before modding), and BANG... Kerberos is none the wiser. Great stuff BTW!

                                    you're my hero!

[Zander]

QUOTE

By performing the same trick on the MAC address you can get a working eeprom. However there is something more to it than this, somehow the header values (I believe) are tied to the Serial/Mac keys, although it could well be that the online serialization is at fault as I have not had a chance to try this.

After talking to a couple of guys last night, I might be at a brick wall. The online key burned into the eeprom during the xbox's creation IS stored in the back-end database on the XBL network. I can tell this because as apart of the kerberos spec as defined in RFC1510, the key is a shared secret key, the key is never put over the wire, it's already known by both parties. AS.XBOXLIVE.COM knows this key by querying the back-end (which I'm sure is Active Directory) and it get's the key needed for authentication, this key matches the eeprom.

Now here is where it get's sticky, and I get out of my field. What if the online key is semi-random upon creation? Among a few other things in the eeprom, you have the following (as near as I can tell).

time
audio setting
video setting
serial #
MAC
hdd key
online key

now IF that online IS random, they we may have a problem. There would be no way to determine the online key based on the serial number or MAC of the xbox unit that someone is trying to "clone" to get it online via Live, you would need to open the box and get the contents of the eeprom. IF the online key is a hash somehow of the MAC or maybe HDD key, then we could have something to work off of.

But I'm afraid if the online is random, then we are screwed. Thay means getting serials off of unit means nothing (this would explain why the serial is transmitted in the cleartext during the conversation, it means nothing, it's just used by the back-end to lookup a key to be used for encryption.

Thoughts?

Z