Leaderboard

Works in Mypal 78, but not in New Moon 28 and Serpent 52. The reason lies in this poorly written function performDownload (line 26, column 119) within the download.js script on the sooftware.com server: function performDownload(num) { event.preventDefault(); ... Strictly speaking, of course, the variable `event` (line 26, column 140) is not defined that way. But Mypal 78 and Supermium seem to be able to handle it. The function performDownload should actually have been constructed this way: function performDownload(event,num) { event.preventDefault(); ... New Moon 28 and Serpent 52 are very sensitive to things like that.

you need sending proper Referer header or you will get a cloudflare's captcha page.

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, for example, 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.

He says can't test on Operating Systems other than W7. I have no any problems found running on W8.1, it's works perfectly i think. By the way W8.1 is technically more as W10/11 than 7, so it is strange if it are workjing on 7 and NOT on 8.1 But actually, I rarely work with Windows anymore and usually use Ubuntu. It is just a kind of curiosity of mine to keep up with this browser support on W8.1. I got stuck on 8.1 because W10/11 never interested me.

(https://panda-free-antivirus.sooftware.com/windows/download/401339) Confirmed also in latest NM28 : (but works in r3dfox-140) @roytam1, any ideas why?

And to complete the puzzle, there’s still one key piece missing. And that’s the 0-post accounts, which were created in large numbers during a specific period, or periodically, or stand out because of their name or other unusual characteristics. I’m currently looking into this in more detail, as far as I am able, and trying to identify any obvious connections.

There is a significant difference compared to February. We have proven here, unequivocally and beyond any doubt – with mathematical precision, so to speak – that the MSFN server has been compromised by malicious code. This can no longer be denied. Any attempt to deny this would be embarrassing and would call into question the server operator’s technical competence. And it is, of course, perfectly clear that the infection was already present in February and that @LoneCrusader was already seeing it at that time: It could therefore have been nipped in the bud back in February, had it been investigated professionally, deeply and thoroughly. That is very regrettable and is completely beyond my comprehension.

Same here. But I used the MojeekBot user agent Mozilla/5.0 (compatible; MojeekBot/0.11; +https://www.mojeek.com/bot.html) And the Bravebot Mozilla/5.0 (compatible; Bravebot/1.0; +https://search.brave.com/help/brave-search-crawler) behaves in the same way. I also tested again the Googlebot and the bingbot. And with these bots, you can clearly see the Thai/Siamese-contaminated MSFN sites caused by "Cloaking". Here is a screenshot when using the bingbot user agent:

I can confirm that the forum software counts views of posts only periodically. What kind of periods I can't say. The first period, after creating the thread about "MSFN and its lack of search results in Google, Bing, and all search engines depending on them", was two days, but today, it updated the views twice with a distance of some hours. Now, there are 70 replies and 973 views:

I’ve been a Google user from the very beginning when their first search engine was released. And an Android user since 2014. Nothing Google has done is for the benefit of its customers or users; it serves only its own interests. And if there were a real alternative, I would have moved on long ago. The good thing is, I’m a very experienced Android user and can make up for a lot.

Google cares about Google. And nothing else. When they say that new optimisations have been performed, then they have minimised their costs and maximised their profit. Google doesn't really care about consumers or preserving knowledge for future generations.

If @xper or @Tripredacus can bring themselves to take my comments seriously and investigate the MSFN server, they must do so very thoroughly, as the infection is more or less hidden or invisible. In IT security, this phenomenon is known as "cloaking" (making content visible only to search engines) or shadow injection. Here is an attempt at a factual, technical explanation of why this Thai content was invisible to visitors in their browser: 1. The phenomenon of "cloaking" (the user-agent switch) The malware that has infected the forum checks the user agent (the visitor’s identifier) every time a page is loaded: If you, as a normal user, visit the site using a browser, the server sees: “Ah, a normal person.” The script ignores you and delivers the completely clean, familiar MSFN forum. You don’t see a single spam post. When the Google bot (Googlebot/2.1) visits the page, the malicious script recognises the identifier and switches over. It injects the Thai keywords, casino text and spam links into the HTML code specifically for this one bot. As the Google bot sees this, it stores it in its index. As a user, you won’t notice a thing until you search for MSFN via Google and wonder about the hieroglyphics. 2. Exploiting the internal search function (URL injection) Many forum software packages have a vulnerability in the way they process search queries. Bots send millions of specially crafted search queries containing Thai terms to MSFN. The forum then dynamically generates a page with the title: "Results for the search: [Thai casino link]" . The bots copy this generated URL and link to it en masse on dubious external websites. When Google follows these links, the bot lands on MSFN on a Thai results page (which exists for it) that never appears in normal forum operation or in the sub-forums. 3. Hidden system files (database level) Often, the attackers do not embed themselves in the visible text area of the threads, but instead modify a deep-level system file (such as the .htaccess file on the server or a core file of the forum software). This file intercepts the data stream and adds the Thai code in the background – but only if the request comes from a search engine. Conclusion: There’s no need to worry: the forum on MSFN that people use and love every day is clean in terms of its content. The database of genuine threads remains unaffected. This is a purely technical "parasite infestation" running in the background, specifically optimised to deceive the Google bot and exploit MSFN’s reputation (domain authority) for illegal advertising purposes. As the administration doesn’t see this malicious code during normal forum operations, it usually only comes to light when Google’s hammer strikes mercilessly in the wake of a core update.

Given that I am presenting the whole matter here in an objective and well-founded manner for the greater good, and that I cannot identify a single breach of the forum rules, a ban is neither lawful nor justifiable, unless complete arbitrariness is at play. I would be more inclined to receive a thank you for my efforts to save an important forum from ruin. Not to mention how much time I’ve already spent researching all this, tracking down sources, then spending hours writing it all up and posting it. And then there’s my guiding principle: Veritas saepe molesta, sed dicenda est. Nihil semper ad nihilum.

https://github.com/e3kskoy7wqk/Chromium-for-windows-7-REWORK/issues/37#issuecomment-4237808546 https://github.com/e3kskoy7wqk/Chromium-for-windows-7-REWORK/releases/tag/149.0.7793.0 New version has been released, with removed dependencies on dxgi in libGLESv2. Simply install VC 2015–2019, or if you don’t want to install it, just copy the relevant files. DWrite is also included.

This is not a problem (only) with legacy browsers. It is also related to the use of tweaks that reduce the ID'ing of one's browsing behavior, even in the newest versions of FF and derivatives. I haven't used legacy browsers (other than icecat, if you can call that legacy) for over six months. And yet, I get annoying cloudfare BS all the time. I blame those who use cloudfare, or similar s*** to "secure" their sites. Do your homework. Make safe your castle on your own. Do not rent knights for hire to do so.