Leaderboard

@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.

Also here: https://github.com/e3kskoy7wqk/Firefox-for-windows-7/issues/147

I don't have a Facebook account (*zero* "social media" for me, can you imagine my OT-ish-ness on any of those types of sites, lol). BUT... Sounds to me like there is an *EASY* solution -- convert Facebook's "infinite scroll" to a PAGED VIEW instead. This is sctrictly AI-Generated, but using AI has always been a good STARTING POINT for me, but will require a Facebook account to test and adjust accordingly: // ==UserScript== // @name Facebook Scroll to Pages // @namespace https://example.com/ // @version 1.0 // @description Replace Facebook infinite scroll with manual page navigation // @match https://www.facebook.com/* // @grant none // ==/UserScript== (function () { 'use strict'; // Configuration const POSTS_PER_PAGE = 10; // Number of posts per page let currentPage = 1; let posts = []; // Utility: Create navigation buttons function createNavButtons() { const nav = document.createElement('div'); nav.style.position = 'fixed'; nav.style.bottom = '10px'; nav.style.right = '10px'; nav.style.zIndex = '9999'; nav.style.background = 'white'; nav.style.padding = '8px'; nav.style.border = '1px solid #ccc'; nav.style.borderRadius = '5px'; nav.style.fontSize = '14px'; const prevBtn = document.createElement('button'); prevBtn.textContent = 'Previous'; prevBtn.disabled = true; prevBtn.onclick = () => changePage(currentPage - 1); const nextBtn = document.createElement('button'); nextBtn.textContent = 'Next'; nextBtn.style.marginLeft = '5px'; nextBtn.onclick = () => changePage(currentPage + 1); nav.appendChild(prevBtn); nav.appendChild(nextBtn); document.body.appendChild(nav); return { prevBtn, nextBtn }; } // Change page function changePage(page) { if (page < 1) return; const totalPages = Math.ceil(posts.length / POSTS_PER_PAGE); if (page > totalPages) return; currentPage = page; renderPage(); // Update button states navButtons.prevBtn.disabled = currentPage === 1; navButtons.nextBtn.disabled = currentPage === totalPages; } // Render posts for current page function renderPage() { posts.forEach((post, index) => { const start = (currentPage - 1) * POSTS_PER_PAGE; const end = start + POSTS_PER_PAGE; post.style.display = (index >= start && index < end) ? '' : 'none'; }); } // Stop infinite scroll function disableInfiniteScroll() { window.onscroll = null; document.addEventListener('scroll', e => e.stopImmediatePropagation(), true); } // Initialize script function init() { disableInfiniteScroll(); // Collect posts posts = Array.from(document.querySelectorAll('[role="article"]')); if (posts.length === 0) return; renderPage(); } const navButtons = createNavButtons(); // Wait for posts to load const observer = new MutationObserver(() => { const newPosts = Array.from(document.querySelectorAll('[role="article"]')); if (newPosts.length !== posts.length) { posts = newPosts; renderPage(); } }); observer.observe(document.body, { childList: true, subtree: true }); // Run after initial load window.addEventListener('load', init); })();

I only use 32-bit Supermium and haven't experienced any significant problems on normal sites, even the heavy app ones like Discord or YouTube. The multi-process nature allows the browser to use all available memory. On XP you can "only" access about 1.5 gigs per process. The site I ran into problems tried to load ffmpeg webassembly for converting media files in the browser. The native exe is just over 100 MB. But the site used over 3 GB of RAM after switching to the 64-bit version. That is insane.

@nicolaasjan I'm currently trying to figure out why nothing is showing up with MojeekBot or Bravebot. It seems, however, that the malicious script or code on the MSFN server wherever it may be hiding isn't playing nice with Mojeek or Brave. And that is most likely why Mojeek and Brave don't really have any issues with MSFN at the moment. But maybe, the hackers will update their malware at some point, and then that will be the end of those two search engines, too, when it comes to search results regarding MSFN. And as things stand right now, they have all the time in the world, since the administrator @xper or supervisor @Tripredacus hasn't taken any action yet.

I tested with the Mojeek bot: MojeekBot/2.0 (compatible; http://www.mojeek.com/bot.html) It sees nothing now :

Anyway, it depends entirely on the filters and bots used by Brave and Mojeek.

As you can see, I already did it first.

Ok. You're right. I can confirm these two Thai results. Perhaps the "Brave bot" behaves in the same way as the Google bot for these two results only. Just an assumption. I don't know how Brave exactly acts.

In your screenshot I cannot see either the search engine used or the search term entered. Such screenshots are unfortunately meaningless.

None of your search terms bring up any Thai results on Brave, at least here in Germany.

@deomsh A search engine can't find and show websites which weren't indexed before. This is usually the job of their automated web crawler.

True, I do not know if client hints are the real culprit. I only know that UA is *not*, that CH is *not*, and that both combined are *not*. FALSE, I do not now, nor have I ever, relied on "research" of any kind from ANY member herein that begins with a *D*. That is your obcession, not mine!

I totally forgot to say: Very tricky! Good idea!

Hey... Sorry, that I wasn't here for some ~3 years but mostly always put the new releases to my tools page (https://soggi.org/misc/tools.htm) as a mirror. The last two releases didn't made it to my page since they are both much slower than the 0516 release and (a minor thing) the tabs don't have the grey border any more. Here are screenshots of the 0516 and 0530 release of New Moon 28 (32-bit/SSE2) together with task manager and Blank / MSFN / WayBack Machine tabs loaded after exactly 4:00 minutes, nothing other has been changed except starting NM28. As you can see the 0516 release took 2:23 minutes and the 0530 release took 3:15 minutes CPU time on a dual core in those 4:00. Edit: Screenshots removed, see this post for the next screenshots! kind regards soggi

No idea! I’m just compiling facts, analyzing connections and drawing conclusions. And that doesn’t come particularly hard for me, as I’ve been doing nothing else for decades, and it’s second nature to me. Let’s hope he might still take action! I’ve never had any contact with @xper. To me, he’s always been a bit of a mystery.

It is precisely observations like these that are important and useful. Thank you, @nicolaasjan!

Ok. New theory. New topic views seem to be counted after two days, but then more frequently. I don't know if it is then real-time but here are new results: 70 replies and 985 views:

If I just do "MSFN Windows XP" then there are no results from msfn.org If I do site:msfn.org "MSFN Windows XP" then there are lots of msfn.org results. Again, a mixture of correct and hacked results. A 'site' search seems to reveal the results that are otherwise hidden. Ben.

I can get msfn results from google if I do a site:msfn.org search, I then get a mixture of correct results and the hacked results. So, there are results there but it's as if the Google crawler has been fed the hacked results. As I still can't find a way to arrive on one of these hacked pages I assume it's Google's own crawler that has been compromised. FWIW, this is https://msfn.org/robots.txt User-agent: * Allow: / Ben.

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260530-3219d2d-uxp-3c23f8ee4e-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260530-3219d2d-uxp-3c23f8ee4e-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-20260530-3219d2d-uxp-3c23f8ee4e-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-20260530-d849524bd-uxp-3c23f8ee4e-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260530-d849524bd-uxp-3c23f8ee4e-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260530-d849524bd-uxp-3c23f8ee4e-w7plus-avx2.7z Official UXP changes picked since my last build: - Re-land: Fix devtools on 32-bit big endian platforms (0915736715) - Issue #3053 - Implement CSSStyleSheet constructor (f5a84f4ad2) - [js] Use size_t when inflating UTF8 (7bbdccd376) - [NSS] Fix instances of softoken attributes freed after owning object. (300dd371b2) - [NSS] Handle SEC_ASN1_NULL in sec_asn1e_contents_length. (9179441f96) - [libjar] Check Jar entry names for nulls. (aadb6beb07) - [NSS] Align PKCS7 digest array with digestAlgorithms. (089170ae83) - [NSS] NSS_CMSContentInfo_SetContent: only modify cinfo if everything succeeds. (7167a8fabc) - [NSS] Initialize src in SEC_PKCS5GetIV (07201fa1ae) - [NSS] Avoid integer overflow when converting AVA value to hex string. (6511833580) - Bug 2029771 - Heap use-after-free in [@ token_destructor] reading tok->pk11slot after nssToken_Destroy frees the token arena. (57bef0265c) - Bug 2029782 - fix 8-byte over-read of AES-192 key buffer in x86 builds without USE_HW_AES. (92b3f6dd67) - [netwerk] nsRequestObserverProxy ref cleanup. (bb2275d400) - [netwerk] Make nsSocketTransport2::mConnectionFlags atomic. (bb85939429) - Bug 2036905: Fix UDPSocketParent::ConnectInternal data race on mSocket. (8d4079866b) - [netwerk] Make socket transport hold a reference to TLSServerConnectionInfo. (349f46bbb2) - Bug 2027381 - improve error handling in SECITEM_DupArray with non-null arena. (b3f801743b) - [NSS] Fix maxSize calculation in NSSUTIL_AddNSSFlagToModuleSpec. (c36357a954) - Revert "Issue #3092 - Perform a minor GC on tab close" (3ae3595f6a) - Revert "Issue #3092 - Initial idle GC implementation" (860d4457ae) - Revert "Issue #3092 - Implement parallel sweeping and compaction tasks" (52ce9ebea5) - Revert "Issue #3092 - Implement BackgroundFinalizeTask for parallel garbage collection finalization" (ac0510f380) - Revert "Issue #3092 - Add new GC sweep tasks." (e95b229db8) - Revert "Issue #3092 - Refactor WASM compilation handling" (d582d12ad8) - Revert "Issue #3092 - Safely parallelize GC background finalization" (c144b4f403) - [NSS] Fix use of uninitialized length after failed PK11_SignWithMechanism/SymKey. (2a26d9508b) - Bug 2029818 - avoid refcount over-release in CERT_CertChainFromCert error path. (62d731d2c2) - [DOM] Check values in audio resampling. (244c614a47) - [layout] Hide accessible carets when needed. (4bf236902c) - [libvorbis] Allocate memory with _ogg_malloc (e9c3451d54) - No issue - Remove ISO-2022-JP from menu, overridability and detector. (c690e26c67) - [gfx/layout] Simplify textruns (b611d80223) - Bug 1784128 - Assert count passed to PR_Read/PR_Write in nsFileStreamBase fits INT32_MAX. (f83e05cf23) - [DOM] Hold a strong ref to VoiceData in nsSynthVoiceRegistry::RemoveVoice. (2f73a3004b) - [media] ffvpx patch: Fix leak in flac decoder in case of alloc failure. (9afa7a80cc) - [DOM] Stop speech synthesis if the originating document is closed. (f041eb0607) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. 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.