VistaLover

... Do I get extra points for prophesying ? Try the above Direct Link now and you'll get the door slammed at your face : Access Denied You don't have permission to access "http://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip" on this server. Reference #18.c46656b8.1600036305.1ef6b01c

FT DeepDark has been my preferred Firefox Complete Theme ever since it was made available ; of course, Fx Quantum killed it , so development reached an end, with its final version supporting Fx 56.0 (and I could only run up to Firefox v53.0 on this Vista machine ) ... It is a crying shame that Firefox Complete Themes haven't been salvaged, in CAA or elsewhere... If you are persistent, you may find some versions archived in the web archive and similar services... Specifically where FT DeepDark is concerned, its author (Stefano Rosselli, a Swiss) has attached a very limiting licence to it so, despite me having the XPI file saved on disk (from the era it was still on AMO), I'm not at liberty to redistribute myself... However, all hope is not lost for you:

... I took the test using Firefox ESR 52.9.1 (32-bit), and the pop-up with the error reported was also displayed at the end of the test execution: Given that the initial fork point of official UXP was Mozilla ESR 52.6.0 (the platform used in Mozilla Firefox 52.6.0 browser), an educated guess of mine would be that this is something Serpent 52 inherited all the way back from Mozilla ; at the same time, one may also claim that the "site" doesn't - by choice - support fully older desktop Firefox versions/engines ... At any rate, this is all probably a moot point , seeing that - as I can also confirm - by dismissing the pop-up, one can successfully get the final test score... I went as far as searching for the term "parent.RankDataLists", but nothing useful for debugging purposes showed up EDIT: ... Scratch that ; it's been reported that even Firefox 80 produces the same error pop-up ...

... Has been reported in the past, but in relation to Serpent 55 : ... BTW, not a fan of these benchmark sites myself, but whatever tickles your fancy...

TBH, I don't think Moonchild himself had anything to do with it; that was all pure/unadulterated M.A.T. , acting out of spite indiscriminately against forks run on NT < 6.1; proper branding was irrelevant at that point in time; and, of course it was intentional; M.A.T. claiming snarkily, quite proud of himself, on the afternoon of the 25th that https://forum.palemoon.org/viewtopic.php?p=197919#p197919 ... and some of his sidekicks in that same thread trying to prove the doubters are delusional... I'm happy for @letmeindude for standing up to the lot of them, and for doing major debugging of the issue (both in the PM forums and GitHub). As for a "reasonable explanation", don't expect one... I'll just refer you to what MC posted on the matter (link in my post just above yours...)

... Are you sure this is FULLY de-obfuscated? function displayContent() { if (X("0x3", "^Mn5") in navigator) { uaPrefix = navigator[X("0x10", "wOY$")] + "/5.0 (" + navigator[X("0x5", "&j9b")] + ";"; if (!navigator["userAgent"][X("0xf", "wkB!")](uaPrefix)) return; if (navigator[X("0x4", "G9*&")] && (navigator["oscpu"][X("0x8", "^Mn5")](X("0x9", "Puzb")) || navigator["oscpu"][X("0xe", "73(^")](X("0x11", "e6DU")) || navigator[X("0x0", "DLe0")][X("0x2", "fCh&")](X("0x6", "pseB")) || navigator["oscpu"][X("0xb", "k4n@")](X("0xc", "GBIt")))) return null } var ig = document["getElementById"](X("0x1", "6osW"))[X("0x7", "rMvY")][X("0x13", "czCY")](!![]); document[X("0x12", "&iPz")]["appendChild"](ig); document[X("0xa", "Y8yJ")]["id"] = X("0xd", "wOY$") } ... Though he doesn't acknowledge he had anything to do with their removal, Moonchild's account of things: https://forum.palemoon.org/viewtopic.php?p=198040#p198040 TL;DR 1. He pretty much (as expected) justifies M.A.T. because he was undeservedly banned from MSFN without notice, as being "a long-standing member with a good track record" () 2. Once again, fork users are being called "so selfish"... The whole affair boils down to two things, basically: 3. MONEY ; the addons infra is being maintained fiscally out of M.A.T.'s own pocket; supposedly, "freeloaders" such as the fork-users put a significant extra burden towards bandwidth consumption/server costs... Edit: Fork users, when using the default Search Engine, DDG, also contribute towards the official project by Moonchild, do they not? 4. Branding (and all related stuff discussed extensively elsewhere in these forums). NB: The term "out of spite" is never mentioned ... I must thank @siria for being the first person in these forums mentioning in the past this HIDDEN Firefox pref When SSUAOs for the add-on repos stopped working for me, but I could still access them in my sister's Win7 laptop inside the same WLAN, I became sure I smelled of fish ... I arrived to the conclusion he must be checking OS version by Javascript, so I remembered that pref and applied it independently on my own; I did not disclose this early on, fearing the involved person's unpredictability... general.oscpu.override changes the Javascript-detected OS version globally; you can read more about it here . However, I wanted something more elegant, that would only work on these two "affected" sites; since I have Greasemonkey for Pale Moon installed, I concocted the following userscript: // ==UserScript== // @name Fake 'navigator.oscpu' on PM & Bk add-on repos (25-08-2020) // @namespace VistaLover // @description Changes 'navigator.oscpu' on PM & Bk add-on repos // @include https://addons.palemoon.org/* // @include https://addons.basilisk-browser.org/* // @run-at document-start // @grant none // @version 1 // ==/UserScript== Object.defineProperty(navigator, 'oscpu', { value: 'Windows NT 6.3' }); Sharing it now for purely academic reasons, just in case... BTW, navigator.oscpu is a feature of only Firefox and friends, Chromium-based browsers don't (easily) divulge the OS version when queried by JS... So, one major crisis averted, I'm sure there'll be more coming...

... I, too, was using DNS Quad 9 Public servers (9.9.9.9,149.112.112.112) until I recently found out that Dropbox links weren't resolving , e.g. : https://www.dropbox.com/ https://dl.dropboxusercontent.com/s/7d47x36vuibc39h/palemoon.js ... so I went back to DNS Cloudflare Public (1.1.1.1,1.0.0.1) ... (OT: Using the very handy nirsoft utility QuickSetDNS v1.30 )

The block was originally implemented (no doubt by M.A.T. ) in the afternoon (my timezone, i.e. UTC+0300) of August 14th, 2020; it denies access to forum.palemoon.org by UAs containing the PaleMoon/28.10.1a1 slice ; that one was relevant to recent New Moon 28 builds prior to the latest one (which, at last, has 28.10.2a1 as appversion) : What is noteworthy is the nature of the error generated, which would have the uninitiated believe it was related to a genuine TLS connection/certificate issue ... On that day, @roytam1 "dared" to post in The Official Interlink Mail & News Discussion Thread : https://forum.palemoon.org/viewtopic.php?p=197174#p197174 which presumably tripped M.A.T. over: But the official forums do not only contain M.A.T.'s "board", who granted this individual God-like rights to ban online community content at a whim? <OT rant> I'm not a young person anymore, sadly, but I swear to all of you I hadn't come across, both in my whole real life and in my "digital" one (since ca. 2005...), such a mean-spirited, vindictive and petty individual, and this is also taking into account the latest unethical shenanigans... The great Albert Einstein might have said : ... but I must add a third one: human evilness Note to admins: As you all probably know by now, I have shown exemplary conduct in these forums; but this time I had to vent ; I apologise profusely and can only swear this won't happen again... </OT rant>

... He's using the WSUS (Windows Server Update Services) that comes with Windows Server 2008 R2 SP1 to access and download Win2k updates, not an actual Win2k installation... @max-h : Where can one find/install/configure a suitable version of WSUS on Vista SP2 itself (if at all possible...) ? Having an existing installation of WSUS on WS2008R2 as a means to fetch Vista updates isn't practical, to say the least...

2008 R2 is the Server side of Win7 (and plain 2008 is the Server side of Vista); both 2008+2008 R2 are still supported by WU/MU, thus WSUS, if the corresponding updates that bestow SHA-2 support are manually pre-installed... This isn't any news, is it? OTOH, you haven't responded with clarity to @Vistapocalypse's query: Have you recently tried WSUS on plain Vista (+SP2?) ??? M$ don't offer an official update that implements SHA-2 support to the OS, one may use the KB for 2008, but does WSUS really work on Vista SP2?

Hello I'm not a Discord user myself, so the report "this trick stopped working" doesn't provide, at least to me, any detail I could use to troubleshoot further... My original post you quoted was from 20 months ago so, yes, many things might've changed since then... First thing that stands out is the domain name change, discordapp.com -> discord.com Then, FirefoxESR 60 has been long EoS'ed by Mozilla, likewise Win7 has been EoS'ed by Microsoft... It is highly unlikely Discord have already removed support for Win7 (... but I'm sure they'll do so when paid by Microsoft, who push their spyware Win10 onto everything on-line...), but it's quite probable they've stopped supporting ESR 60; ESR 68 (now at version 68.11) is on the way out, so to speak, while the new ESR is 78; so, in August 2020, I'd use general.useragent.override.discord.com;Mozilla/5.0 (Windows NT 6.3; rv:78.0) Gecko/20100101 Firefox/78.0 How exactly is your Discord experience broken in @roytam1’s (latest) Basilisk forks (BTW, they're called Serpent; mentioning the official app name tends to upset people upstream... ) ? Please be specific... This is, of course, the place to post about Serpent (and friends); while letting us know that a different Basilisk fork works for you has importance on its own for the wider XP/Vista communities, it doesn't help to identify that specific "some reason" you wrote about, due to which Discord stopped working in Serpent; if we are to assume the breakage is due to Serpent code and not due to a change implemented recently by Discord, then you can at least perform some bisection to identify the LAST GOOD and the FIRST BAD Serpent builds where Discord is concerned; then it'd be fairly easy (usually...) to pinpoint the culprit change that caused the offending bug... Is the above used in Centaury? I see two issues with it, though... 1. %OS_SLICE% will reveal the actual OS you're running the browser on, and if that one is XP (Windows NT 5.1;), then you're more probable to get blocked by Discord... 2. Having different values for Mozilla Platform (Gecko) revision (rv:73.0) and Firefox version (69.0) is not standards compliant, so I'm really puzzled the whole UA string works for you (?) Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent FWIW, I have just created a temporary/guest account with Discord and having applied the SSUAO I posted above, I first see some GUI glitches in latest Serpent 52.9.0 32-bit: ... i.e. three vertical (empty) scrollbar placeholders display, while, IMO, they shouldn't (they don't show up in 360EE v12, Chromium 78 based...), but I can't tell anything more is broken, since I've never used Discord before...

The exact URI to that script is https://game314425.konggames.com/gamez/0031/4425/live/Build/UnityLoader.js I downloaded it locally on disk and probed it with an editor ; I couldn't find "Disabled by lack of compiler support", but did find the original warning/error: "Your browser does not support WebAssembly." Looking closer at your Web Console output, it appears the message is generated by the browser's asm.js module, when it tried to compile js code fed to it by the UnityLoader.js script ; BTW, many thanks @UCyborg for your most helpful contribution, as always : You might've mentioned it previously in these forums, but it didn't dawn on me that that was the case... I am running Vista SP2 32-bit and my 2007 era Intel Core 2 Duo is SSE2 capable; so using the "-xpmod" variety of Serpent-52.9.0-win32... By the looks of it, you should be running the "-xpmod-ia32" build, derived from the "ia32" branch of Roytam1's UXP fork: https://github.com/roytam1/UXP/commits/ia32 TBH, I don't follow closely the development of that branch, only that of the custom branch (produces NM28+St52)... @UCyborg wrote that WASM expects at least SSE2 instructions set , so there's your answer... @roytam1 : Perhaps it could be a good idea to disable WASM and LOCK the related prefs (inside about:config) in your ia32 builds, so as not to create false expectations by the users of those builds on their pretty old processors... Just throwing this out there for consideration... As posted, I first tried the site with a pristine St52 profile, and it did ask permission to use Flash; Flash is used to deliver ads in the embedded player, just before the game itself loads (when it does... ).

I thought Basilisk/Serpent supports that, huh?! Latest St52 has buildID=20200814013442; WASM has been indeed supported since long ago, even MozillaESR 52.6.0, the initial fork-point of UXP, came with native support... Whether that native support is ON/OFF by default is a different matter, though... MozillaESR 52.6.0 had all native WASM support pref'ed OFF by default; in latest St52, the behaviour is determined by following two commits: [Basilisk] Issue MoonchildProductions/UXP#1611 - Use platform default for WASM https://github.com/roytam1/UXP/commit/95c5a64 Issue #1611 - Enable WASM by default but only enable jit when 64bit https://github.com/roytam1/UXP/commit/ed0edf6 Indeed, when I launch latest 32-bit build in a NEW/CLEAN profile, this is what I get: i.e. WASM is ON, but baseline just-in-time (jit) is OFF; if that isn't the case in your set-up, then something altered the default settings, either a (security?) configuration imposed by an extension or you did it yourself (directly in about:config, using a user.js file, etc) in the past, possibly following online advice, and forgot about it... FWIW, visiting the linked URL in the above CLEAN profile, I get no warning of the kind you reported; the site does require Adobe Flash though, and it took a considerable amount of waiting for the game to fully load ; but it did eventually: OTOH, on my very old/DIRTY profile, with many extensions (some of which of the WebExtension format), many userscripts (in GM-for-PM), many userstyles (in Stylem + Stylus), uB0-legacy with many filter lists, the game never loads fully , because of async OOM errors: ... so YMMV even with WASM turned back ON...

I tried in Serpent 52 2020-7-31 and ... (redacted for brevity) But Config Descriptions does not show anything in "Source comment" column (the column is added). ... You assumed things and that's why it didn't work in the end as you had thought it would... My mention of that extension in my post (of more than a year ago) was only inside the context of Mozilla Firefox... The original Config Descriptions v1.0.1-signed.1-signed legacy extension DOES NOT support Serpent 52.9.0 (or official Basilisk, or Pale/New Moon for that matter...) Serpent 52.9.0 != FirefoxESR 52 Good News: 1. You can patch the extension yourself, so that it works in Serpent 52.9.0; in file bootstrap.js change L223-L224: - "resource:///defaults/" + prefsDir + "firefox.js", - "resource:///defaults/" + prefsDir + "firefox-branding.js", + "resource:///defaults/" + prefsDir + "basilisk.js", + "resource:///defaults/" + prefsDir + "basilisk-branding.js", While you're at it, you can also remove the META-INF directory, as Serpent does not observe extension signing... Proof: 2. The old Firefox extension has been ported to both Pale/New Moon + Basilisk/Serpent; just install from: https://addons.basilisk-browser.org/addon/config-comments/ ... A strong word of caution while you are toying with e10s in Serpent 52.9.0: what little supporting code is left there is very rudimentary/fragile/unreliable at best ; please back-up your Serpent profile, especially your sessionstore, prior to starting these experiments! Use a secondary/temporary profile for testing! I speak from BAD experience myself ; once you decide e10s isn't good enough for you or (my case) one of your most valued legacy extensions breaks under e10s and you, thus, have to return to single-process, it's highly probable your profile has been borked beyond repair (I had to begin from scratch, took me many hours to resume my original profile... I hadn't backed-up ; you really should ). MCP applications (and forks) have been developed as single-process, and that's it...

This is most excellent news @SIW2 , thanks for the confirmation! If only we could untangle @Dylan Cruz 's predicament...

... so without SHA-2 code-signing support (AFAIAA, this can't be implemented to OSes prior to Vista SP2 and in the latter, packages targeting originally WS2008SP2 are needed ), that method will become a moot one... I foresee that the next release will only be SHA-2 signed... ... And, as expected, that has just happened! The latest WSUSscn2.cab file (links are still the same as in my previous post) is ONLY SHA-2 signed and probably just useless under XP SP3: M$ is putting an end to everything pre-Win7, it seems...

... And just to be on the safe side, your previous screenshot from Aug 8th reported definition version 1.321.917.0; can you confirm you are now on a "higher" version after executing downloaded file mpam-fe.exe ? That would dispel any doubt that the manual update procedure for MSE is a viable way to keep using it under Vista SP2! I am genuinely sorry you can't get this to work, Dylan, but I'm also out of ideas what you should try next... Perhaps a visit to Windows Event Viewer could shed some light on this mystery... Just one final, probably just silly, question: Where did you get your copy of MSEInstall.exe v4.4.304.0 ? If it was within the context of some WinXP related thread, it's possible they linked the 32-bit variant, which would also install under Vista x64; verify you have MSE 64-bit installed (the 64-bit mpam-fe.exe is not able to update MSE 32-bit, and vice versa...). Ultimately, only you know how you've configured your Vista SP2 system (I read several times that GPOs were used - not available here in my Home Premium Edition ), so it's possible something went amiss there... Best regards

... Says a WinXP x64 user (going by your avatar), a minority inside the community of XP users (most of which have been on x86 all along) ... FWIW, when Vista OEM was first released (as a successor to WinXP x86) and pre-installed in new hardware (this was my case here ), it was practically always 32-bit (the lack of 64-bit Vista drivers was, of course, an issue at the time...)! Do you actually have figures to support that "long shot" argument, or are you simply going by MSFN posters in these threads? In any case, I am a 32-bit user myself and just being patient for @win32 to work his miracles ; all Vista users have waited and wished for this for the last, say, four years, I think one can wait just a tad longer until something stable and functional is released in due time...

What do you actually mean by that? Please download latest 64-bit mpam-fe.exe from the link below: https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64 and save it in a location you have write access - please note down its actual file version; at the time of this writing, the latest file I can pull down is of v1.321.1115.0 (~ 107MB) Open then your MSE (x64) app and switch to the "Update" tab; note down the "Virus definition version" displayed (consult the screengrab uploaded by @SIW2 ). Then launch the previously downloaded mpam-fe.exe file (if you are under a limited User account, it may be necessary to run the file "as administrator"); it performs a SILENT install/update, do not expect a GUI to pop up... Give it 3 to 4 mins and revisit the "Update" tab of MSE; if the "Virus definition version" displayed now has been raised, compared to its previous value, then ALL IS FINE! You have successfully updated your MSE - repeat the process as needed...

... You must've gotten the wrong file, then... "mpas-fe.exe", whether 32 or 64-bit, is the standalone offline installer for updated anti-spyware (as) definitions; this file should only be used to manually update Windows Defender, Vista's native anti-spyware solution! "mpam-fe.exe", whether 32 or 64-bit, is the standalone offline installer for updated anti-spyware (as) + anti-malware (am) definitions; this file should only be used to manually update MSE (NB that when MSE is first installed, WD is being de-activated, so as not to conflict with MSE, which is both an anti-spyware and anti-malware solution!) You should probably only download from the (revamped) Microsoft Security Intelligence portal: https://www.microsoft.com/en-us/wdsi/defenderupdates Definitions for MSE there get updated 3-5 times during the course of 24h, but probably once a day is a sane frequency to manually update... You can read the Release Notes below: https://www.microsoft.com/en-us/wdsi/definitions/antimalware-definition-release-notes ... for latest as well as the previous 19 releases...

Hi @SIW2 When I first quickly read your post as an e-mai notification, I must have got it wrong , believing that the "is not working" bit meant that the whole app itself somehow stopped working ; this doesn't seem to be the case, most fortunately! The "it cannot install the definition update." bit I believed it to mean that the MANUALLY downloaded "offline" standalone defs updater, file mpam-fe.exe, ceased being able to be run/installed; that doesn't seem to be the case, either... By "It was fine yesterday" do you actually mean that before August 9th, 2020, MSE on your Vista SP2 install was able to (automatically/manually) fetch and install updated MSE definitions via Microsoft/Windows Update (that's what the big "Update" button does, it searches MU)? If affirmative, that would be the first such mention... On my own system, MS/WU quit fetching anything in mid-July of last year, and that included Windows Defender (WD) defs updates... Installing SHA-2 code-signing support to the system, alas, did not change things... You obviously have SHA-2 code-signing support installed, if you were able to get current (prior to Aug 9th) defs updates installed; but that support augments Vista's build number to 6.0.6003, and WU (when it worked) gave it the cold shoulder; that's why I'm quite sceptical of your report.. In any way, Error 0x80244019 when checking manually for defs updates in MSE is because dear M$ has shut down the WU infrastructure for Windows Vista ; this has been reported and detailed elsewhere in the MSFN forums... (EDIT: @Vistapocalypse posted while I was in the middle of composing this message...) The only solution is to download manually (e.g. once daily) the standalone updated definitions installer, mpam-fe.exe, from MS's security portal: https://www.microsoft.com/en-us/wdsi/defenderupdates and run that file to get you up to date... (Scroll down to the MSE section and select the bitness of installed MSE; download and run file mpam-fe.exe) Please report back, MSE on Vista SP2 shouldn't be dead yet! @Dylan Cruz , what is the situation there?

First thing I want to say is that I agree with @Vistapocalypse that your query ("How to get MSE running on XP SP3 in August 2020") does NOT belong in this thread... But having seen your failed attempts at this endeavour being spread at various places in the MSFN forums, let me "put you out of your misery" ( ) by offering you an abridged version of the story of MSE on XP (more detail can be found towards the last pages of the relevant thread linked to by @Vistapocalypse ) : 1. M$ continued to offer definition updates for MSE/WD on XP SP3 automatically through Windows Update for approximately two years after the OS was EoS'ed ! This fact alone upsets me tremendously to this day because we, Vista users, were not offered a single day of additional support by MS with regards to MSE! (the very last version of the app compatible with Vista contains a trigger/time-bomb that completely locks it after the OS EoS date! ) ; we're seeing the same thing again with EoS'ed Win7 SP1, which continues to receive MSE defs via WU! 2. When WU stopped offering MSE defs on XP, updated defs had to be manually downloaded from MS's Security Portal https://www.microsoft.com/en-us/wdsi/defenderupdates and applied by the user. Community enthusiasts and an esteemed member here in MSFN created automation for that procedure, so XP users were kept happy for a while longer... 3. Before I proceed with the story telling, let us focus on the offline defs file itself, mpam-fe.exe ; this is comprised of 6 constituents (you can extract the .exe with 7-zip) mpasbase.vdm mpasdlta.vdm mpavbase.vdm mpavdlta.vdm mpengine.dll MpSigStub.exe ALL these files are digitally code-signed by MS against MS root certificates and are verified by the OS that they haven't been tampered with before they are allowed to be applied/update MSE; any attempt to modify these files renders them invalid; but more of that later... .vdm files contain the actual antispyware/antivirus definitions, either in full (mpasbase.vdm, mpavbase.vdm) or delta (differential) formats (mpasdlta.vdm, mpavdlta.vdm); mpengine.dll is the most important constituent, i.e. the AV engine inside MSE which does get updated from time-to-time (and partly mitigates the fact that MSE itself hasn't been updated for quite a long while now... ) . 4. With a specific mpengine.dll update, M$ dropped a nuclear weapon on WinXP users of MSE, because the updated DLL contained new functions not found under XP, only under Vista+ (thankfully for us Vista users.. .) You can probe yourself the mpengine.dll file under XP with Dependency Walker... Hence, newer/updated versions of mpam-fe.exe would not succeed in installing, after that failure MSE would revert to the last working defs+engine. 5. MSE on XP was then stuck with a stale version of engine+definitions and, as time went on, started nagging about that fact... As with all signature-based antimalware solutions, the software itself becomes ineffective at protecting you from the ever evolving online threats... 6. A desperate solution was given some consideration, that is using the last compatible mpengine.dll file coupled with updated .vdm files (extracted from an updated version of mpam-fe.exe), but this was actually "a hole in the water" kind of thing, because updated .vdm files also demand an updated engine to work, i.e. both are interlinked! 7. So here we are now: MSE on XP dead and buried! 8. In the following months, M$ introduced further changes to the defs installer, mpam-fe.exe: 8a : The "Subsystem version" value in the PE header was raised to 6.0 (Vista+); this is the main reason you get the "is not a valid Win32 application" error on trying to launch it; lowering that SubSysVer to 5.1 (XP) will accomplish NOTHING, because of two reasons: one is the incompatibility of the mpengine.dll with XP's kernel, discussed in 4 above; the other reason is: 8b: Starting on the weekend of 19/20 Oct 2019, the standalone mpam-fe.exe file as well as all of its constituent files are ONLY being code-signed with a SHA-2 digest algorithm; no matter what you do, you can't get SHA-2 support under XP (and on Vista SP2 you must install select WS2008SP2 updates, as I'm sure you know by now...). Do you now see why this quest of yours is totally futile? Please, lay it to rest... As for some other points you made, M$ don't keep/offer an archive of deprecated mpam-fe.exe versions; in all honesty, what good would that be to anyone, security-wise? In a total hypothetic scenario, you would need first an XP Extended Kernel solution that will restore XP compatibility to mpengine.dll , plus backporting SHA-2 code-signing support to XP; I've seen stranger things happen, but you shouldn't hold your breath on both of these... For the benefit of the whole community, I have re-uploaded that at below link: http://s000.tinyupload.com/index.php?file_id=60954865039051356545 (included is a custom batch file; place the modified PE inside FixPEC folder and run .cmd; as with everything downloaded from the internet, please first scan with a reputed AV software; I can assure you the file that was uploaded by yours truly was safe...)

Please re-read my actual post! It pertains to insecure/weak cipher suites when ONLY TLS 1.0+1.1+1.2 are enabled! I'm sure you've been notified already of the fact I ONLY use the 32-bit variant of the OS, so no clue really... Try using the one I provided and go your way from there; I have faith in you! (FTR, a link to a M$ support article IS provided...)

For the more observant among you, you might've noticed that @Dylan Cruz 's last screengrab contains one additional IE9 cipher suite [TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13)] that is absent on my IE9 SSL Labs Client Test! In fact, on a TLS 1.0+1.1+1.2 enabled Vista SP2 machine, IE9 supports the below twelve variations of cipher suites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy(2) 128 TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Forward Secrecy(2) 256 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) WEAK 112 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128 TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128 (2) Cannot be used for Forward Secrecy because they require DSA keys, which are effectively limited to 1024 bits. At some point, I had removed support for half of them, deemed to be extremely WEAK/insecure: Removed: *TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 (TLS1.1) *TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 (TLS1.1) *TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 (TLS1.2) *TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) WEAK 112 *TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128 *TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128 which currently leaves me with TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy(2) 128 TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Forward Secrecy(2) 256 NB: The last two do not support FS, so I might remove them, too... PS: On my 32-bit system I used Disable_RSA_Ciphers_RC4-128-128_3DES-168.reg : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS] "Enabled"=dword:00000000 A computer restart is needed before these changes take effect! Reference: https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols

The Protocol Support section of the SSL Client Test available in browserleaks.com also fails for me here in IE9 32-bit: ... while, at the same time, the Handshake section is displayed correctly: Perhaps they're using some CSS/JS code in the first failing section that the deprecated IE9 rendering engine can't cope with... (?) For IE9 specifically, you may want to use the SSL Labs Client Test, https://www.ssllabs.com/ssltest/viewMyClient.html :