Probs your valtron’s brother
Interesting… Even XP has
ppcrlconfig.dll in the AppData folder.
I guess that explains why it’d always short-circuit and use HTTPS.
addcontact.xml (1,1 KB)
addgroup.xml (1,2 KB)
addmember.xml (1,1 KB)
addusertogroup.xml (1,8 KB)
addressbook.xml (1,0 KB)
changenick.xml (1,4 KB)
deletecontact.xml (922 Byte)
deleteuserfromgroup.xml (995 Byte)
deletegroup.xml (916 Byte)
dynamicitems.xml (1,2 KB)
deleteoim.xml (516 Byte)
getmaildata.xml (493 Byte)
deletemember.xml (1,1 KB)
getoim.xml (521 Byte)
updateprofile.xml (1,0 KB)
Maybe this will help
I appreciate the help, but these are just the SOAP requests for various Messenger services Escargot already has implemented. My problem is coaxing MSN to use a modified DLL that contains completely unrelated XML so that it can connect to different login services, in this case, Escargot’s. Said DLL is also signed, explaining why it tries to download the BIN if it’s modified.
I have a solution that involves byte patching whatever checks the signature of the DLL (either the MSN executable or yet another system file) so that it’ll always announce it as signed, and MSN can happily authenticate on login. And I’ve heard that PPCRL also does certificate pinning to check the signature of the login server’s certificates (
login.live.com), so that’ll have to be investigated into further. Unfortunately, I don’t have the tools nor the resources to get such tools to do that myself, so I’ll have to see if the reverse-engineers over at the Escargot dev team can get online and help me.
on-the-fly memory patching questionmarkquestionmark
Nah. More like a game of “find the ASCII string and x86 instruction byte”.
Search and Destroy Patch then?
Not sure if most people are aware, but Escargot is now becoming a fancy federated server where accounts can integrate to any and all frontends along with their contacts and settings. Because of this, frontend-specific integration would probably be a disaster and interfere with other frontends. Basically, I’m cancelling this project and leaving the MSN frontend as-is. However, I hope I can revisit it in one way or another.