Post by: NetJunkie on November 14, 2002, 08:07:00 PM
Post by: darkhalf on November 14, 2002, 08:08:00 PM
| QUOTE (NetJunkie @ Nov 15 2002, 03:07 AM) |
| I have a similar post below. Mine hits as.xboxlive.com and then macs.xboxlive.com. Different IPs for those. On the as.xboxlive.com I send an AS-REQ and get back an KB-ERROR... I send an AS-REQ to macs.xboxlive.com several times but never get a response. |
Now thats interesting. AS-REQ is an Authentication Service Request which is used by Kerberos. You are requesting a ticket to so you can access some resource. Hmmm..
Post by: Zander on November 14, 2002, 08:13:00 PM
Z
Post by: darkhalf on November 14, 2002, 08:16:00 PM
I still think its an issue with the servers. After tommorrow night I will see what is up. On the beta forums it was advertised that we could play with celebrities. I bet that along with the influx of retail discs that got out "early" and you have some server problems. On the thread they said to try the servers after midnight.Not sure if thats gonna mean much, but I plan to focus more time tommorrow night when its OFFICIALLY launched. All I know is my retail disc will NOT update.
Post by: Xevious on November 14, 2002, 08:24:00 PM
Post by: andreo on November 14, 2002, 08:27:00 PM
Great work Zander!!!
Post by: lucasz on November 14, 2002, 08:36:00 PM
THANK YOU!!! I keep forgetting to bring home a plain old dummy hub for sniffing.
>Here is the result of about 1/2 hour of packet sniffing a failing xbox. This
>is my xbox, it hasn't been able to go online since Tuesday morning. I have
>seen a few requests on various boards for this, so I'm crossposting it like
>crazy.
>Beginning to end frame capture analysis of a XBOX Live dashboard
>connectivity test...
>Initially, obviously, there is a DHCP disc, then a return offer, then a req,
>then finally an ack. If you know anything about networking, you know
>what I'm talking about. One oddity here is, during the usual dhcp
>exchange, the xbox was doing arp requests within the broadcast domain
>for it's own IP, strange, but not showstopping. This goes on for about 5
>seconds, then we move on to the second phase.
That was the DHCP client making sure nobody else is using the IP in order to avoid conflict. Normal stuff.
>IP Mutlicast tests, the xbox hits whatever it's default router is with IP
>multicast packets. They are of address 239.255.255.250, which I'm sure if
>I had the time to look it up, it would be UPNP. It tried 3-4 of these then
>moves on to the DNS query portion.
Yup, that's used for UPnP. See http://upnp.org/down..._ssdp_v1_03.txt
>The first lookup is for AS.XBOXLIVE.COM against my primary DNS server,
>the return was 207.46.247.6, which if you reverse out, you can see that it
>reverses to AS.XBOXLIVE.COM. Then there is a 2 packet exchange
>between the xbox and AS.XBOXLIVE.COM. The packets are interesting,
>and mostly in hex. The first packet is sourced from the xbox with a data
>payload byte size of 421. .27 seconds later I get a replay from
>AS.XBOXLIVE.COM with a data payload size of 784 bytes. Couple of
>things to note...
>Within these packets, there is some dechiperable text, things like
>PASSPORT.NET and XBOX.COM. Also I see this...
>Xbox.Version=1.00.4831.5
>Title=0xFFFE0000
>TitleVersion=268595456
>SN.(MY SERIAL NUMBER)@xbox.com
>(MY SERIAL NUMBER)=my ACTUAL xbox's serial. :/
I think the version number MAY play a role in the results you get from a modded box. Some people can connect with the mod chip disabled, others can't connect no matter what. Maybe one version can be blocked by SN and the other can only be blocked if the BIOS is detected as different at sign on???
>Now THIS is juicy, during a connection test the xbox is passing your serial
>number in PLAIN TEXT. LOL, maybe it's not critical, but I don't think I like it
>much. I hope that this means somehow that the serial isn't THAT big of a
>deal, not sure.
I bet you a million dollars that this is important. Blocking a box by serial number while keeping track of all shipped serial numbers will deffinitely make it difficult to circumvent a SN block. If we figure out a way to change the reported SN though and we use other people's SNs, there would be too many valid boxes getting banned and MS would have to free everybody.
>In the send data packet from my xbox to AS.XBOXLIVE.COM I saw
>absolutely none of the data in my "Y" screen (X,Y,Z information). It
>appeared to be program code or encypted, perhaps both.
XYZ is nothing more than a hash of the network configuration. Change your IP, gateway, mask, DNS. Then check the XYZ info and see how much it changed. Maybe it's just meant to help Xbox Live support get the network config without making customers worry about privacy.
>OK then, once this is done, the xbox does yet MORE IP multicast packets
>out to 239.255.255.250, AGAIN more UPNP. Then guess what, MORE DNS
>queries (catching a pattern yet? :), but THIS time it's for
>TGS.XBOXLIVE.COM which resolved out to 207.46.247.6 THE SAME DAMN
>SERVER, nice fault tolerance, maybe they do this as some sort of reverse
>DNS round-robin, dunno. Anway there is one packet out and one packet
>in for an exchange between my box and the server this time it's a bit
>different. The outgoing data packet is 1076 bytes in size and the return is
>1054 bytes. Although the data packets are much larger this time around,
>the plaintext data I show up above is also in these packets. Odd...
Give em a break. They're just getting the server up. Once they have the backup server running, they'll change the second A record to point to the second server farm. It'll probably be in a different geographic location.
>After that 2 packet exchange the xbox does 2 mutlicasts second for 3
>seconds resulting in 6 more UPNP multicast packets. I wonder why they
>are trying this at the end? Dunno.
The Xbox doesn't know why it can't connect, so it's trying to make sure the ports are definitely open before giving up?
>So, in summation, the xbox tries to hit 2 servers, AS.XBOXLIVE.COM and
>TGS.XBOXLIVE.COM which both resolve out to the same IP address. I
>was hoping for more cleartext in the basic data packets used for
>connectivity tests, but oh well. Now at least at a very basic level I
>understand the process, the bad thing is I don't think I'm really closer to
>understanding WHY MINE DOESN'T WORK!!!!! ahem.
I think we all know why our boxen aren't working. ;)
>I know there are ppl out there who know networking better than I. I
>hope someone will take this and do some of their own sniffing and come
>up with something. The sniffs I did were done using Network Monitor 2.0,
>IRIS, and Sniffer 4.6. Enjoy.
Save the netmon trace and post it for d/l. I have netmon 2 and was trained by a certain company *cough* *cough* in using it. :)
>Thanks,
>Z
Post by: Xevious on November 14, 2002, 08:48:00 PM
| QUOTE (Zander @ Nov 15 2002, 03:04 AM) |
| After that 2 packet exchange the xbox does 2 mutlicasts second for 3 seconds resulting in 6 more UPNP multicast packets. I wonder why they are trying this at the end? Dunno. |
(Speculation mode ON)
On the UPNP multicasts you're seeing:
MS has said that Xbox Live will work flawlessly (i.e. be able to be hosts OR clients) even with multiple Xboxes behind the same NAT-ing firewall. The only way that I can imagine them doing this is to have the Live servers dynamically assign ports to the Xbox consoles. So the sequence might (and I say MIGHT) be something like this:
Xbox attempts to use UPNP to open port used to contact authentication server and/or look for other Xboxes connected to the LAN.
Contact authentication server (as.xboxlive.com) to obtain a MS Passport.NET token, which uses Kerberos AND has been well criticised for sending user information in the clear.
Using Passport token, log on to the game server (TGS?). Game server checks to see if another client is already at current client's IP (little brother playing MechAssault downstairs). If not, game server responds with standard port assignments; if so, game server assigns next available port for that IP. --OR-- Xbox, using UPNP, has already detected another Xbox connected to the LAN, decides on ports all by itself, and reports these to the game server.
Xbox uses UPNP to open game ports on firewall.
Xbox sends embarrassing personal details to M$ for later use as blackmail material.
(Speculation mode OFF)
So they are indeed using a .NET Passport for identification and authentication... That means that the passport certificate is stored somewhere on the hard drive... hmm...
I'm not completely familiar with the Xbox crypto scheme, but I'm assuming that it doesn't contain any secure chips like, say, a smartcard. If this assumption is true, then encrypt/decrypt is done on the CPU, meaning that the key could be intercepted, allowing the network transactions to be decrypted for further analysis.
I'm tired... am I smoking something here???
Post by: lucasz on November 14, 2002, 08:51:00 PM
| QUOTE (Xevious @ Nov 15 2002, 03:48 AM) |
| If this assumption is true, then encrypt/decrypt is done on the CPU, meaning that the key could be intercepted, allowing the network transactions to be decrypted for further analysis. |
Maybe someone can write a debugger that dumps all activity to a file, running in the background as you run the connectivity test?
Post by: eXpired on November 14, 2002, 09:03:00 PM
). This furthers my theory that SN are blocked on a server side basis. The kerberos AUTH most likely terminates due to blacklisted SN. Now it's just a matter of finding and deciphering exactly what is being sent to MS to signify a modified console/BIOS. If they are as careless with it as they were the serial, it may be as simple as hardcoding a packet reply with a valid string message. Patches for xbe files could soon follow 
Just my speculation.
Post by: Xevious on November 14, 2002, 09:29:00 PM
| QUOTE (eXpired @ Nov 15 2002, 04:03 AM) |
| This furthers my theory that SN are blocked on a server side basis. The kerberos AUTH most likely terminates due to blacklisted SN. Now it's just a matter of finding and deciphering exactly what is being sent to MS to signify a modified console/BIOS. If they are as careless with it as they were the serial, it may be as simple as hardcoding a packet reply with a valid string message. Patches for xbe files could soon follow |
Hmm... Yes, if by merely changing your Xbox's serial number you were able to log on to Live, you've presented a compelling argument for server-side auth denial.
The question in my mind, however, is if this is the case, then why doesn't the authentication server deny the blocked Xbox's request for a Passport token?
Post by: andreo on November 14, 2002, 10:05:00 PM
I think that the solution has to come as a complete package. Keep them from seeing mod chips and flagging the system and then change the serial number to get back on-line.
Post by: andreo on November 14, 2002, 10:08:00 PM
But I thought I would throw that in the mix.
Post by: Zander on November 15, 2002, 05:23:00 AM
Z