MSN Explorer war Microsofts eigener Internetzugang: Browser, E-Mail, Messenger und Portal in einem. Die Server dahinter sind abgeschaltet. Seitdem startet der Client, fragt nach Hause – und bekommt keine Antwort.
Puppenspieler gibt die Antworten. Er spricht Passport 1.4 und Directory Access, liefert Konfiguration, Anmeldung, Berechtigungen, Assistentenseiten und Installationsdateien. Der Client merkt nichts. Er tanzt, weil jemand die Fäden hält.
Fällt einer aus, bleibt der Client stehen – meist ohne zu sagen, warum.
clientpost.srf nimmt Adresse und Kennwort
entgegen. Die Antwort trägt Erfolg, Ticket und das Ziel, auf das der Client
danach springt.Diese Formate stammen nicht aus Dokumentation – die gibt es nicht mehr –,
sondern aus dem Disassembly von msnsign.dll und aus Mitschnitten
eines funktionierenden Nachbaus. Sie sind der eigentliche Grund, warum es
jetzt läuft.
Der Parser prüft ein Attribut auf dem Wurzelelement, nicht ein
Kindelement. Das Ticket steht innerhalb von <User>.
Und die Zielangabe braucht eine Abfragezeichenfolge, weil der Client
&home=… anhängt.
<?xml version="1.0" encoding="utf-8"?> <LoginResponse Success="true"> <User> <TNP>t=…*1&p=…</TNP> </User> <Redirect>https://…/dummy.htm?ru=1</Redirect> </LoginResponse>
Das Wurzelelement heißt Return, nicht root.
root ist die Hülle der Anfrage. Belegt an einem
Endpunkt, der bis heute antwortet.
<Return><Result>SUCCEEDED</Result> … </Return> <Return><Result>FAILED</Result><Errors><Error> <Code>217</Code><ErrNumber>901</ErrNumber> </Error></Errors></Return>
Der Anmeldename steht in PMN, nicht in Member –
erkennbar am XPath Member[PMN $ieq$ "…"] in der DLL. Als Rolle
kennt sie SubscriptionViewer, SubscriptionAdmin
und BillableAccountAdmin.
<Members><Member> <PMN>name@msn.com</PMN> <PUIDHigh>…</PUIDHigh><PUIDLow>…</PUIDLow> <Role>BillableAccountAdmin</Role> </Member></Members>
Die Konfigurationsdatei unter nexus.passport.com/client/client.xml
wird weiterhin von Microsofts Buildsystem erzeugt und ausgeliefert – nachweisbar
am eingebetteten Erzeugungsvermerk mit Zeitstempel, Buildserver und
Umgebung prod. Die Anmeldung dorthin ist tot, die Konfiguration
lebt.
Verzeichnis client.xml | läuft |
Anmeldung clientpost.srf | läuft |
Profil ClientProfileRequest.srf | läuft |
Berechtigungen getpermits.asp | läuft |
Mitglieder enumerate.asp | läuft |
Assistent getxgl.asp | läuft |
Produktdaten msninstallersvc.asmx | läuft |
Programmdateien /downloads/ | läuft |
Messenger gateway.dll | offen |
| Gruppen · Postfachdaten | offen |
Installation und Anmeldung laufen vollständig durch: Konto anlegen, Pakete laden, installieren, starten, einloggen. Messenger und die WebDAV-Dienste fehlen noch.
| Client | MSN Explorer 9, deutsche Fassung |
| System | Windows XP in einer VM |
| Server | IIS mit ASP.NET 4 |
| Netz | hosts-Umleitung der MSN-Namen, eigenes Stammzertifikat |
Das Paket enthält den Emulator, die Assistentenpakete, Skripte für Zertifikat und Registry sowie eine Anleitung. Ein Wort der Warnung: Der Client prüft das Zertifikat und besteht auf HTTPS – ohne importiertes Stammzertifikat kommt keine Verbindung zustande.
Das Verhalten eines vernetzten Programms steckt zur einen Hälfte im Client und zur anderen im Protokoll. Wer nur die Installationsdateien aufhebt, hat die Hälfte aufgehoben – und die uninteressantere. Erst wenn die Gegenstelle wieder antwortet, lässt sich sehen, wie das Ding wirklich funktioniert hat.