Leaderboard

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260613-3219d2d-uxp-ec5b4aa693-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260613-3219d2d-uxp-ec5b4aa693-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260613-3219d2d-uxp-ec5b4aa693-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260613-d849524bd-uxp-ec5b4aa693-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260613-d849524bd-uxp-ec5b4aa693-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260613-d849524bd-uxp-ec5b4aa693-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260613-d849524bd-uxp-ec5b4aa693-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260613-d849524bd-uxp-ec5b4aa693-w7plus-avx2.7z Official UXP changes picked since my last build: - Revert "Bug 2027433 use nullptr for silent up-mix channels" (4d9fe0ca23) - Revert "Bug 2027433 Treat null input channels as zero in AudioChannelsDownMix()" (cbdec72879) - Revert "Bug 2027433 Treat null input channels as zero in InterleaveAndConvertBuffer()" (68b774798b) - [DOM] Provide more silent audio processing frames. (f83dd5bf22) - Issue #3111 - Clean up logic in SweepFinalizationRegistries. (b336d24faf) Official Pale-Moon changes picked since my last build: - [Pale-Moon] Adjust default theme to handle adjusted metrics for border truncation. (d7d7589555) No official Basilisk changes picked since my last build. My changes since my last build: - Revert "Revert "Revert "Revert "Implement FinalizationRegistry" and related commits.""" (ff2a1248c4) Update Notice: - You may delete file named icudt*.dat and icu63.dll inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

Views counter not counting caused by PHP upgrade. Waiting on patch.

You have no idea how large of a project it is to migrate a 20 year old forum full of custom code to a different forum software.

we talk a little away from each others, the "fix it" part was for notheretoplaygames not for K4sum1 and we have like 100 % the same meaning: "2) We-the-consumer can just slip back to a previous version - IT AIN'T GONNA HURT YOU ONE D@MN BIT TO USE A PREVIOUS VERSION." i totally agree on that one, but what notheretoplaygames also says is that he has to much of upgrades he says always something like "that upgrades go a little to fast" but here is where i tryed to point out you can fix this version trick - i dont have to repeat what i wrote about that, its a version trick in short again also you only missing the part with version 8 - thats the last one from the "common trick list" - there are certainly more - but having these would be ok for now and it does indeed work against that "fast upgrade problem" the other part regarding the user agent - if r3dfox has a problem with the new versions - yes the user agent is a solution that work against that - it might not fix it totally - but it would be a step into the right direction that same thing also goes for supermium - what is even the problem to searching for the value that is being added to not_a_brand with "version 8" ? thats the only thing you missing, its only 1 thing

Yesterday, I uploaded files to MediaFire, and the used RAM increased to over 600 MB. After closing the tab, only a very, very small amount of used RAM was freed up. @roytam1, any chance to natively improve that behaviour in New Moon 28?

Update notification! As already reported, the Root Certificates have been updated and are now from 29-04-2026. Here again a screenshot: After a long delay, I have just updated my self-created, offline Root Certificate Updaters in the section 11.2.4. Downloads related to Root Certificate Updates (in the first post of this thread). Cheers, AstroSkipper

Would you please stop with that. You have absolutely no clue what I’m dealing with personally and privately, which is why I don't have time to constantly check the server. MSFN is a one-man show. And how do you know I won't say thanks? On top of that, I’ve wanted to shut MSFN down several times over the last few months because of this situation. So back off. Stick to software, hardware discussion or go find another forum. I don't care. Just be careful. Have a nice night or day or whatever.

I completely missed that one. I almost always have to "convert in my head" posted dates. The US is kind of backwards, we mostly do month-day-year but the standard online seems to be day-month-year. So to VistaLover's credit, I do prefer when people SPELL OUT the MONTH - avoids confusion when other countries do things backwards.

Nothing was reset. I just pruned some inactive members. Found breach, egyspider webshell. Old WP plugin. Took me 4 days to clean up everything. Reindex sitemap and requested new Google indexing. We are getting back on google. As for country flag, I will fix that. Thanks for pointing it out. Anyway, I do as much as I can. Not much spare time.

As already mentioned, the next problem I have investigated is the large number of 0-post accounts without any activity created up until 16 January 2026 and one from today. It must be thousands as far as I could see. These were created automatically using a script or other methods over the last years. Maybe, some of them are genuine but most of them aren't. A key indicator for those accounts is whether they have never been visited or only once when creating. Fake accounts, or so-called ‘sleeper’ accounts, could be all those where it says: ‘Last visited: Never’ or ‘Last visited: [Date of creation]’ if looking into them. A genuine account is usually visited in the moment of creation and later from time to time. Real, new members set up all necessary things and take a look into their accounts. Anyway, those accounts are the ‘sleeper cells’ of the attack. They were not used to carry out the infection itself (the malicious code was introduced onto the server via a security vulnerability), but serve as infrastructure to make the spam appear legitimate to Google. Here are two typical examples – accounts that really stand out because of their names and status ‘Last visited: Never’ which does not make any sense at all : 1. Building ‘domain trust’ (initial trust) Large forums such as MSFN have safeguards in place against brand-new accounts. If a bot registers today and immediately posts 50 links, the system raises the alarm and blocks it. Attackers therefore use automated scripts to register thousands of accounts in advance and simply leave them dormant for months. To the forum software (and to Google), the account ages. An account that has existed since “January 2026” will enjoy much greater trust in June 2026 than an account that is only 5 minutes old. 2. The profile spam method (hidden profile links) This is probably the most common use case: every forum member has their own profile page (msfn.org/board/profile/XXXXX-username). A normal user fills in their biography there. A spam bot uses the ‘Website’, ‘About me’ or ‘Signature’ fields to insert Thai keywords and casino links there. The key point: as these accounts have 0 posts, they never appear in active threads. No moderator and no member ever sees them in normal forum activity. But for the Google bot, these profile URLs do exist! The malicious code on the server (our cloaking parasite) now ensures that it feeds the Google bot internal lists of all registered profiles. Google crawls these profile pages, finds the Thai links and indexes them. 3. Exploitation of internal messaging systems (PM spam) or hidden drafts Some sophisticated forum bots use dormant accounts to send spam messages (PMs) to other members in the background (which would, of course, have been noticed), or they create hundreds of posts in the ‘Drafts’ section. These drafts are never published, but exist as data fragments in the database. If the server-side malicious script specifically accesses these tables, it can trick the Google bot into believing that this content is public. 4. Why did the wave of registrations come to an end in January 2026? The fact that no further accounts of this kind were created after January 2026 suggests two possible scenarios: 4.1. The loophole was (unintentionally) closed: The administrators may have installed an update to the forum software in January, activated a new CAPTCHA (e.g. Cloudflare or Google reCAPTCHA), or blocked registration for certain IP ranges or email providers. 4.2. The quota was full: By January, the attackers had generated enough ‘sleeper’ accounts to run their campaign for 2026 and withdrew the registration bots, as the accounts now simply had to ‘mature’. These accounts are used for what is known as profile injection spam. They do not harm the forum database itself, but they serve as a ‘host’ for the hidden links that the server parasite then sends exclusively to Google. For the administrator @xper, this means: not only he has to delete the malicious code, but he must also use a simple database command (SQL) to completely eliminate all accounts with 0 posts that were created over the last years and never visited or visited on the date of creation only, or contain dubious links in their profiles. Or much better, delete them all if there is no genuine activity, as they are then superfluous anyway, apparently not needed and pose a potential risk.

@nicolaasjan This is an attempt to explain what happens when the contaminated MSFN server meets other search engine bots than Googlebot or bingbot. For everyone else, it refers to @nicolaasjan's test and observation: Why alternative bots (like MojeekBot) trigger the "Welcome Loading ..." freeze 1. The mechanics of the attack: The server-side user agent sniffer The malware installed on the server uses a conditional script (usually written in PHP within core files like index.php or .htaccess rewrites). This script scans the incoming request for specific keywords in the User-Agent string to determine whether to serve the clean forum to a human user or the spam payload to a search engine. 2. The Googlebot trigger vs. the MojeekBot catch-all fault With Googlebot: The malware has a fully defined template. When it detects Googlebot, it successfully injects the hidden HTML container containing the Thai spam, links, and keywords, allowing the page to render fully for the crawler. With MojeekBot (and potentially other secondary search bots): The malware's sniffing routine recognizes the word Bot or Bot/ (via a regular expression or wildcard check like *bot*), flagging it as a search engine. However, the malware's backend does not have a valid spam-template or correct database-routing configured for this specific bot identifier. 3. The cause of the freeze: Broken Document Object Model (DOM) & JavaScript execution The string "Welcome Loading ..." is part of the forum’s native lazy-loading or initialization layout (often used during the initial handshaking phase between the server and the browser's JavaScript engine). When MojeekBot hits the server, the malware triggers, intercepts the request, but then crashes or terminates prematurely (e.g., throwing a silent PHP Fatal Error or an unhandled exception because the variable for the payload is empty or undefined). The backend script crashes mid-execution: It completely fails to fetch and load the actual forum database content (the threads, posts, and UI). It leaves the HTML document incomplete and broken, trapping the page forever in the initial "Welcome Loading..." state. This observation proves that the infection is not a static HTML injection into old threads, but an active, dynamic routing script on the server. It intercepts all automated crawlers based on a broad User-Agent filter, but breaks completely when encountering bots it wasn't explicitly optimized for (like Mojeek). To fix this, the administrator @xper or supervisor @Tripredacus needs to look for malicious conditional statements filtering user agent keywords inside the server configuration or core PHP initialization scripts.

More likely to reduce the amount of work they would've to do each time the new version is released. I mean, no need to constantly cut out the unneeded code parts from chromium itself. Basically, the file consists of wisely stubbed/redirected APIs. (a compliment to win32)

Rowl https://www.definitions.net/definition/rowl

Yes, a good suggestion to block rumour spreaders.

It would be odd to simply publish all of the source code of something which has *subscription mode* and paid Patreon versions, yes, I'm aware about the free github versions, too.

There was a leak, my first release wasn't protected with X-prot, so someone, someone I shared my app with, had hacked it and made another launcher app based on my knowledge, but it's nowhere near as good as the original, that person didn't know all secrets. Clearer now?

I think Klemper's logic is very simple, and I tend to agree, no source for that particular dll would mean Supermium is indeed close source, it's simply won't even launch without it. It's not "hearsay", no source for that dll was ever published, I looked.

Coal