Nov 2 '20
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.