MSN 7.5+ Authentication: The Patchening


#1

a.k.a. Implementing Real Accounts onto Escargot Pt. 2: Not blindly listening to people saying that it isn’t possible and doing more extensive research! :wink:

On a certain Escargot GitLab issue regarding a formerly hot topic about Escargot, logging on with real Microsoft accounts, one of the devs linked an older Escargot GitLab issue. Number 4, to be exact. Most of the issue is pretty interesting to read and watch how much progress the dev team tried to make in terms of getting it working.

Basically, a file MSN Messenger fetches during authentication, ppcrlconfig.bin, contains XML that includes the RST.srf URL we desperately needed to get the account services intertwined.

However, there were some miscalculated roadblocks along the way. Aside from the aforementioned dev’s unnecessary suggestion to decrypt Microsoft tokens when the Escargot server gets them, there’s also his outrageous statement that the ppcrlconfig DLLs in WinSxS, a DLL cache, mind you, are encrypted and was thus considered a dead end, even though I wouldn’t be relying on a DLL cache to look at an application’s DLL modules. :stuck_out_tongue:

Alongside that is also the apparent fact that the ppcrlconfig DLL in the ProgramData folder (C:\ProgramData\Microsoft\IdentityCRL and C:\ProgramData\Microsoft\IdentityCRL\production) auto-repairs itself, which sounded very odd.

Several hours ago, I had put that to the test.

I had modified a copy of ppcrlconfig.bin I had downloaded from Microsoft’s servers over a year ago to contains links to custom domains I then “hacked” with HOSTS entries.

Then came the setup of the Escargot dev server to host the .bin under HTTP for MSN to download and the URLs I had to change, which are listed below:

https://login.live.com (Stored inside ppcrlconfig.bin; used for RST location)

http://clientconfig.passport.net/ppcrlconfig.srf (Stored in MSN 7.5; somehow redirects to the .bin file anyway)

loginnet.passport.com (Also stored in MSN 7.5; used for RST location)

When I logged in on the dev server, I had come to the realization that it connected to the real RST.srf anyway, due to the entry in the ppcrlconfig DLL in the ProgramData folder (C:\ProgramData\Microsoft\IdentityCRL ONLY). I kept an original copy of the DLL and modified it so it would connect to Escargot’s RST.srf handler. Needless to say, no auto-repairing of ppcrlconfig.dll happened during the 40+ minutes I had been testing the new setup.

However, MSN 7.5 refused to even connect to the MSNP server when these changes were put into effect. I also noticed that whenever I typed in anything in the e-mail address column, it would make a new GET request to http://<local ppcrlconfig host>/ppcrlconfig.bin for every keystroke.

I am not giving up yet, considering that I had just tried this out. And I also might have forgotten some other key things to modify and tweak. The only problem I have is reinstalling MSN 7.5 over and over again, since I don’t have any spare computers ATM, plus whenever I access the HTTPS portion of the dev server via my XP VM, IE and the server start complaining. So I may not be able to look into this as much as what the Escargot team has on their to-do list.

Let’s see how far we can go with this, regardless. :stuck_out_tongue:


The MSN Chat Revival: 10+ Months Later
Can I still use MSN Messenger for Pocket PC?
The Escargot Mega FAQ (Subject to change)
Any email servives that i can use wlm 2012 with?
Can Tweener be given the "real account" treatment? (Companion thread to "MSN 7.5+ Authentication: The Patchening")
Can someone please make a new DeltaSync server?
Can someone explain me this?
After a year of being puzzled, we've finally got the WLM 2009 problem solved!
Email notifications work in MSN Messenger 7.5
Anything new about patching?
#2

oh shit?


#3

If I am successful in my endeavors, maybe I’ll give @valtron the fruits of my labor. :wink:


#4

msn is secretly a keylogger all along!
AAAAAAAAAAAAAAAAAAAAA :ms_ants:


#5

So, out of nowhere, my Windows XP VM now effortlessly connects to Escargot. So I guess this can be something I won’t have to do on occasion.

And in case XP’s cipher support acts up again, I have a little trick up my sleeve… :wink:

image


#6

virtual machines on sp2 irl


#7

SP3* :stuck_out_tongue:


#8

it’s almost impossible to get a sp3 disc.


#9

my iso is pre-sp3 :stuck_out_tongue:


#10

same


#11

So, it seems that SRFs explicitly expect XML to be the whole response body, so maybe MSN will accept the SRF and connect to the custom RST.srf. Then again, it would retrieve the .bin file regardless on Windows 7, so who knows what XP has to offer. :stuck_out_tongue:


#12

Ugh. I’m experiencing the same nonsense with HTTPS where it won’t connect to the dev server unless I access it via localhost, which isn’t the case with my XP VM.

Time to fiddle with more variables…


#13

Since I’ve learned that HTTPS verifies the common name or domain, and that I haven’t been able to get them configured correctly for XP to give my local setup the green light, it’s back to 7 and wondering how I can convince whatever gives MSN the RST authentication URL.

However, from re-testing 7.5, it seems that simply patching loginnet.passport.com is all that’s needed to redirect the authentication services. Let’s hope that MSN requires nothing else from ppcrlconfig.dll, though. :stuck_out_tongue:


#14

Welp, MSN doesn’t use that loginnet.passport.com. The dreaded ppcrlconfig.dll does. :stuck_out_tongue:

We’ve been duped!


#15

https://the-eye.eu/public/MSDN/Windows%20XP/en_windows_xp_service_pack_3_x86_cd_x14-60489.iso
it will take a million years to download.


#16

And when modifying the loginnet.passport.com/RST.srf URL, Windows defaults to using login.live.com/RST.srf.

Gr.
:stuck_out_tongue:


#17

So not even modifying the login.live.com URLs will make Windows convinced. Somehow finds a way to default back to good ol’ login.live.com.


#18

Oooo. This explains a lot:

Time for more patching.
:stuck_out_tongue:


#19

Lol powersocket


#20

OK, so it looks like @tristanleboss was right when he said that ppcrlconfig.dll auto-repairs itself. However, Windows auto-repairs the DLLs in the AppData folder rather than the ProgramData folder. This also leads me to believe that Windows primarily uses the DLLs in the AppData folder, which is why patching the DLLs in the ProgramData folder was a no-go.

And how it auto-repairs those DLLs?

By downloading clientconfig.passport.net/ppcrlconfig.bin, sillies. :stuck_out_tongue: