Consider this a sort of follow-up to my thread about the partial archive of MSNTV2 service content I posted a few days ago.

A month ago I finally got my hands on a working MSNTV2 box from eBay. I already attempted to get one some months ago but by the time I was able to get a power adapter for it it wouldn't power on and I feel that that unit's motherboard was fried at some point (At least I was able to get the CF card contents out of it). This new box I bought (technically used) powered on on first try and it already had an account associated with it. Now there was figuring out how it carried out network traffic.

My setup for analyzing the network traffic was using a Raspberry Pi 3 configured to bridge my Wi-Fi connection to the Ethernet interface, where the MSNTV2 can then talk to the internet. While originally I did this as I assumed the MSNTV2 wouldn't let you configure DNS even on broadband (it does, from what I can tell anyway), now that I'm working in a room where I don't have easy access to my router it's pretty much my only choice (either that or moving the router, but meh). After configuring the Pi to bridge the connection, opening up tcpdump, and logging in on the unit, I was able to find my first lead: DNS requests were sent for a domain under the name "sg4.trusted.msntv.msn.com". For those not caught up, MSN TV seems to have hosted its many MSNTV2 services on these "SG" domains which are identified by "sgX", X representing a number from 1 - 4, and it seems that there were only 4 of these service types that were reserved. As of writing, it is known these services resided on domains "sgX.msntv.msn.com" and "sgX.trusted.msntv.msn.com". The difference with the trusted domains was that they were configured to allow HTTPS, and since that's how my MSNTV2 box decided to start communicating, I figured things would get a little difficult from there.

So I went ahead and set up an Apache server with a self signed certificate and the lowest SSL protocols I could manage (specifically TLS 1.0 and 1.1) and configured the hosts on the Pi so that the SG4 domain would go to that server. As I expected the box still would error out, but I assumed the network captures and Apache access logs would yield more information. Needless to say, the many captures I recorded on tcpdump and viewed on Wireshark on my main machine showed that the box expects the server to understand only SSLv3 and/or SSLv2 (ignoring the fact that most captures I sent to my main got corrupted as I didn't realize FTP was sending them in ASCII mode...), and Apache access logs showed nothing from the box. After finding this out I went ahead and tried to get SSLv3 working on my Apache setup by compiling and linking an older version of OpenSSL with SSLv3 enabled on the system. To put a long story short it didn't work out and I didn't get anywhere. Pretty much the flags I set for SSLv3 support didn't carry over too well to Apache. I plan to give it another shot when time allows, but for now I'm in doubt I'll be able to do it alone at this capacity. I don't possess the ability to analyze the executables the unit runs to get a better idea of how it operated, and not many people that I'm aware of are even interested in poking around with WebTV stuff period, let alone MSNTV2. What I can analyze however is the service structure based on the URLs I have collected so far.

As stated before, "SG" services hosted the core MSN TV services that allowed the end user to login, use things such as Mail, Discuss, Messenger, etc., and also a "Sync" service that I assume was for possibly synchronizing service URLs the user could access(?). Four of these services in total were available on 2 subdomains: "sgX.msntv.msn.com" for what I assume is regular HTTP communication and "sgX.trusted.msntv.msn.com" for secure communication (note the "trusted" part of the domain; and remember X in this case represents a number from 1 - 4). Most services simply used one of the two subdomain schemes, but Mail and "Sync" services had their own special "SG" prefixes - "Mail-sgX" and "Sync-sgX" respectively. Outside of those "SG" domains, there has also been a headwaiter domain observed in the wild - "headwaiter.trusted.msntv.msn.com". While my guess is as good as yours, what I do know is that in original WebTV terminology, a "head waiter" is the service that verifies the box and account logging in. Since at least for me, my box immediately goes for the SG4 domain already stored in it to log me in, I can only assume the headwaiter domain is used to verify new boxes/accounts or that the SG domains being used for login is most likely for caching purposes and was intended to be erased after some point, with headwaiter being the default. From what I've heard from a guy who's developing their own classic WebTV server (which is private right now), MSNTV2's servers also used IIS and XML web services. Most of my findings at this point are mere speculation however and unless we can find more solid information on how MSNTV2 worked, this might be all we have on it. If anyone's got more useful information on MSNTV2's services or infrastructure, please speak up! It'd be an honor to get some substantial information compiled together to at least figure out a way to allow these boxes to log in again. That's all for now.

Update: Was able to build a version of Apache that'd accept SSLv3 connections and I got a little further with the HTTPS SG connection than last time. Sadly, by the time both the client and server finished handshaking, communication stopped from what I could observe in my various packet captures. Not even enforcing stronger cipher suites did anything (strong for SSLv3 standards, anyway; and the strongest the MSNTV2 can go up to is cipher suite "TLS_RSA_WITH_3DES_EDE_CBC_SHA"). Whether this means the trusted SG domains run a protocol other than HTTP under TLS (unlikely IMO) or the box has some other requirement to undergo SSL communication is beyond me, but regardless this means I might not touch MSNTV2 stuff for quite a while until I have more information on how the login process works exactly. For now, take care everyone! :)

Today I finally decided to muster up the courage to reset my MSNTV2 box so it would function just as if I had bought it new (which I didn't lol). While stuff such as a login page were sacrificed and now possibly no longer exist assuming that was simply pulled from web servers, I was able to find another little nugget of information that actually validates one of my previous theories. When attempting to start the registration process on the box, my Pi caught another domain the box tried to connect to: "headwaiter.trusted.msntv.msn.com". Previously I had speculated that the head waiter domain was for authenticating new/registered boxes, and judging from this new information I can believe that was the actual use for that domain. Sadly the SSLv3 issues persist and even chaining my self-signed certificate for use with the headwaiter domain didn't fix anything. I can only assume that either the box doesn't like communicating to services that use the same IP it's connecting from, or it needs the root certificate installed to be able to verify the connection before doing anything useful. Whatever the case may be, I believe I still won't get very far without any extra help. If only there were people who could be able to find efforts like these and pitch in. *sigh*

Although it's been a week, I've discovered a lot regarding MSNTV2's internals. A few important ones being that power off code 8086 opens a factory service menu, although that's outside the focus of this post and I won't go in depth into that, the system's specialized interface pages and files are stored as its own filesystem within the NK.BIN ROM (which is stored on the CF card's first partition; also won't get into that here), and replacing the XIP files in said ROM are as easy as using a tool like binmod. Surprisingly the first "dead' unit I got for free from an eBay bid magically decided to work when I felt like plugging it in so I decided to mess with that for my experiments. What I essentially did was replace two .p7b files in the XIP store on the ROM, msntvcerts.p7b and sysroots.p7b, and replace them with my own versions that contained the root certificate my local web server utilized. The modified NK ROMs I threw onto the CF card did appear to load (unless the box is caching ROMs) but they had the same behavior pre-modification, and nothing changed in terms of SSL communication aside from the fact the system software on the box I was testing actually supported TLSv1, which is nice at least. Afraid to say though that for now, I'll be leaving this whole project on hiatus until someone that knows what they're doing can step up.

A quick aside, from the dump of the CF card on the formerly "dead" unit, I scraped out as many service page assets as I could (this sadly did not include actual service pages), and most of them appear to be for a later revision of the home page that I'll simply refer to as "HomeBB" from looking at related URLs corresponding to the asset locations. Knowing now that that box runs a version of the system software newer than the one on the other box I was primarily testing with makes me regret resetting that one before even considering dumping that for any assets for the earlier home page (the one that's been partially archived by Wayback and had planned to fully reassemble) or anything else worth saving, but ah well, lesson learned. I don't plan to release said assets publicly for now since they're essentially useless, but I'll make sure they're in good hands in the meanwhile. I also decided to contact one of the WebTV scene members to see if they'd be willing to contribute anything valuable (especially MSNTV2-related) to this ongoing effort, but I haven't heard anything from them in the 5 days I emailed them. Only time will tell what will happen with that.