Post by: Spree on November 18, 2002, 07:00:00 PM
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.
Post by: Fuzzy on November 18, 2002, 07:03:00 PM
Post by: Spree on November 18, 2002, 07:24:00 PM
is it possible to access the eeprom with evox. Can we dump it to do a comparison or is this not yet possible?
Post by: Zander on November 18, 2002, 07:34:00 PM
Z
Post by: Spree on November 18, 2002, 07:41:00 PM
Post by: upstatenyguy22 on November 18, 2002, 07:45:00 PM
| 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.
Post by: Zander on November 18, 2002, 07:54:00 PM
Z
Post by: Pr0crastin8r on November 18, 2002, 10:13:00 PM
Post by: Pr0crastin8r on November 18, 2002, 10:15:00 PM
anyway, if you guys want them for comparison I should be on IRC in a bit.
Post by: Pr0crastin8r on November 18, 2002, 10:21:00 PM
Post by: Pr0crastin8r on November 18, 2002, 10:55:00 PM
Post by: Spree on November 18, 2002, 10:57:00 PM
Post by: opjose on November 18, 2002, 11:27:00 PM
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!
Post by: ArMaGeDdOn on November 19, 2002, 01:20:00 AM
| 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!
Post by: Zander on November 19, 2002, 05:31:00 AM
| 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
Post by: Omikron on November 19, 2002, 06:00:00 AM
| QUOTE (Zander @ Nov 19 2002, 12:31 PM) | ||
opjose,
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 |
Congratulations Zander,
You have hit on a point I have been thinking about for some time now. I know for a fact that kerberos tickets are very reliant on synced time. I know this because my university uses kerberos extensively and the community here has done some probing into our infrastructure. If your computer clock is too far off from the server clock, the kerberos tickets are invalid and access is denied. I have yet to test my theory with my xbox because someone is borrowing it but I am sure this has something to do with it. In addition, it would not be too hard for them to implement other checks, besides time hash, to generate tickets. If there are other checks however, it has to be based on non-dynamic data or predictible data. The video mode can be changed at will and there is no way for them to "know" in advacne what mode you are using. Other aspects however, such as MAC,HDD Key, Serial, Processor Number, and even perhaps *Region Codes*, may be used to hash out something. It's really early in the morning so you'll have to forgive any minute errors I may have made but that is my little contribution for today.
Now I must go back to studying for my Chem exam...
Post by: PillMonster on November 19, 2002, 06:07:00 AM
Sounds good - best I've heard so far.
Post by: mod7 on November 19, 2002, 08:29:00 AM
Post by: Omikron on November 19, 2002, 08:35:00 AM
| QUOTE (mod7 @ Nov 19 2002, 03:29 PM) |
| Wow what do you know....man in the middle attack like I freaking mentioned what was it 5 days ago. If any of you use linux/unix out there here is a start. Try ettercap from http://ettercap.sourceforge.net/ by Alor and Naga....I am a beta tester for this and can help test I just cannot do too much c programming yet....so if anyone would like to try some of this stuff I am game....I have the sniffing/man in the middle knowledge if you have the c programming knowledge. btw already have packet sniffs etc performed on a sidewinder box on the inside nick and outside etc using tcpdump ettercap and other bits of info.....also this brings up a great program as well that is windows based it is called hailstorm....hmmm lets see url is http://www.cenzic.com/ they have an eval there for it....what it can do is capture all packets sent from a specific node and save it and regenerate it.....what needs to be done is a filter for ettercap written in c to replay the good packets from a non modded chip....i.e. your box with mod disabled then renable the mod and do a man in the middle attack and shoot off the good packets....not actually that hard cause all we have to do is send packets....I am however worried about time stamping should'nt be too much of an issue etc....pm me. |
Unfortunately, the man in the middle attack will be next to impossible. You forget that kerberos uses time as part of its authentication procedure. In addition, kerberos tickets EXPIRE. I do know what MS has set the expiration time to but it could be as little as 5 minutes. Hell of a window of opportunity, eh? For these reasons you cannot "replay" kerberos authentication procedures. They weren't stupid when they designed kerberos. In fact, they designed it *specifically* to thwart such attacks. You have to understand that kerberos isn't some dinky protocol MS wrote for xb live. It is a super-secure authentication protocol used in many classified environments.
MS using kerberos on the xbox is the same as using a biometrics retina scan to open your bedroom door. The only way to spoof such a security check is to rip out someone's eye, or in the xbox's case, the EEPROM. Good luck spoofing that.
Post by: Zander on November 19, 2002, 08:38:00 AM
It WOULD be that hard, if we didn't know the online key needed to decrypt the response from the AS server so we can get the session key to decrypt the ticket from TGS.
Z
Post by: mod7 on November 19, 2002, 08:50:00 AM
Post by: Zander on November 19, 2002, 08:52:00 AM
Finding out what the timestamp lee-way is I think will be easy.
Z
Post by: mod7 on November 19, 2002, 08:56:00 AM
and also regarding time auth.
Each host on the network must have a clock which is "loosely
synchronized" to the time of the other hosts; this
synchronization is used to reduce the bookkeeping needs of
application servers when they do replay detection. The degree
of "looseness" can be configured on a per-server basis. If the
clocks are synchronized over the network, the clock
synchronization protocol must itself be secured from network
attackers.
btw keep in mind that a relay attack is not the same as a man in the middle attack.
http://www.netbsd.or....pl?number=8376
Post by: Zander on November 19, 2002, 09:04:00 AM
You SHOULD also be able to intercept and modify it, re-encoding and regenerating the checksum all the while. Neither party every knowing any different.
Z
Post by: mod7 on November 19, 2002, 09:25:00 AM
http://marc.theaimsg...47881324253&w=2
also probably what were up against this time.
http://www.MS.com/te...dp_log_ovqw.asp
and something from that article that makes me smile
"These service tickets can then be used to access network resources without having to re-authenticate the client as long as the service ticket remains valid. These tickets contain encrypted data that confirms the user's identity to the requested service. Except for entering an initial password or smart-card credentials, the authentication process is transparent to the user."
without having to re-authenticate is the keyword here so attack is only on connection I would think.
Post by: mod7 on November 19, 2002, 10:41:00 AM
Post by: ArMaGeDdOn on November 19, 2002, 11:37:00 AM
| QUOTE (Spree @ Nov 19 2002, 08:43 AM) |
| Dude man no offense but we are trying to keep the thread technical. We don't need crap like that blocking the view. |
i'm just trying to cheer opjose on! this way he'll post even more technical info!!
and yeah. i'll shutup now.
but you're evil! 
Post by: Zander on November 19, 2002, 02:56:00 PM
I haven't given up hope..... yet. ALthough I do have a major headache now because of this.
Z