Windows 10 EOL is not about Windows 11, it's about OneDrive "Backup"

The end of Windows 10 support is not about Windows 11; it's about stampeding everyone on to OneDrive cloud storage - either as a pure money-maker, and/or to extend geopolitical reach.

Microsoft has to patch Windows 10 anyway

Consider: If Windows 10 will have code repair updates developed against exploitability for those who choose to buy extended support for three years, then that work has to be done anyway.  Extending update delivery to systems is the same cost, whether they are on Windows 10 or 11.  A wider pool of Windows 10 users may mean more niche testing, but also means more involuntary testers, making it easier and quicker to find out what needs fixing next.  

In the worst-case scenario, a massive exploitable base of unpatched Windows 10 systems could pose risk to everything connected to the Internet, which may compel Microsoft to "support" (fix) all those systems.

Folks aren't joyously flooding to Windows 11, throughout years of ongoing development, right up to these final days before Windows 10 (and Windows 11 23H2 and older) go out of support.  Many systems are disqualified due to TPM 2.0 and other requirements, but others are simply user refusal, as well as the inertia of large managed networks.  

In response, Microsoft offers Extend Security Updates (ESU) programs to both professional networks administrators and consumers.  The "pro network" crowd have to pay, but a new "free" option has been added for consumers that looks too good to be true... and is.

Baked-in ransomware

If you allow the Windows Out Of Box Experience (OOBE) to lead you by the nose ("a little WiFi here, a little sign-in there"), then this is what happens:

• you sign in to an online Microsoft Account
• your internal storage is encrypted without your knowledge or consent
• the encryption key is available only from your online Microsoft Account
• all appears to work as normal, so you don't get the key you didn't know you'd need

Now if that smells like a ransomware attack, that's because it is exactly that.  Microsoft doesn't extort money upfront, payment doesn't involve complicated crypto currencies, and it's not about payment anyway; it's about the option to deny access, either for breach of the vendor's private law (the EUL"A" that no-one reads) or at the behest of US policy, such that sanctions can apply to data as well as money.

Data survivability is now brittle, as various local situations can trigger a demand for the key:

• you need to boot into Safe Mode
• you need to access your storage from a different system
• something glitches the TPM, e.g. a firmware ("BIOS") update

There may be server-side issues too, e.g. your online account is hacked, or deleted by the vendor, or you follow advice to discard the account to use a Local account instead, or your account hasn't been signed in for "too long", or the vendor or US policy applies a "data sanction" on you.

Theft-to-cloud as "backup"

Backup is actually a hard problem; the aim is to keep all wanted data changes, while excluding all unwanted changes - a mix of sheep and goats, needles in the haystack.  Strategies vary, but always involve multiple copies of data such that if one is afflicted, the other is available to restore.

Sync is the opposite of backup; if anything bad happens on any one system, that unwanted change is immediately propagated to all systems.  The server beyond your reach is now the dog, and all "your" devices are now its chew-toys.  Whatever entity signs into that online account is deemed to be "you", and shares some control with the vendor; if you're locked out, sorry for you!

Once you get past the OOBE (if not before), you're pestered to "backup" to OneDrive.  If you swallow the bait, the content of many shell folders is automagically copied to the OneDrive cloud storage service, while what you see locally as your files may appear to work, but in reality may have been replaced with stubs to online files, "to save space".  Just like automatic Device Encryption, this payload is hidden, with delayed effects that arise when you try to work offline, and "your" files aren't found within the large cache footprint that the cloud service uses as an ashtray.

So, now your data is exfiltrated, local copies destroyed, and you're even more vendor-dependent.  When you run out of free space at the server end, you'll have to pay up for more space, or buy some other service that bundles the extra space you need.  

This is a straightforward hook-and-reel-in sales scam, similar to a time-bombed "free trial" that lasts just long enough to create data you can't use unless you pay (especially Outlook's .pst walled garden).  That's a significant incentive to the vendor, leaving aside any geopolitical implications.

You can use Windows 11 safely

As at August 2025, there are ways to skirt these risks while still upgrading to Windows 11 for more effective ongoing support.  There are ways to break into the OOBE to trigger a restart that will add small links for "I don't have Internet" and "Continue with limited setup"; there are ways to craft a bootable USB installer that bypasses various compatibility checks and onerous UI pressures.  As long as you can install Windows 11 and run the OOBE while safely not connected to the Internet, you have the potential to be safe; staying that way requires ongoing resistance to embedded sales pitches.

There are also ways to block Device Encryption by policy, as applies via a .reg import or direct Regedit; to hide OneDrive, or at least stop it reducing your files to online pointer stubs, and so on.  If Device Encryption is already in effect, you can step over the scary warning to turn that off; maybe it will take a long time, as the warning states, or maybe not - the whole process is so opaque (or transparent, in that one sees through it even if trying to see it is harder) that I've no idea if it completes as quickly as it seems, or if it grumbles along unseen for hours or days.

Upgrade carefully, if system is compatible

In my opinion, it's better to carefully upgrade Windows 10 to 11, after suitable backups, as long as your system is compatible, than stay on Windows 10.  It's also a good time to upgrade the OS hard drive to a speedier SSD, as that way the original hard drive can be your "undo" fallback backup.

If your system is incompatible, you may be able to force the upgrade via Rufus or similar tools, and/or more manual methods - but I'd be reluctant to do that.  "Hard" incompatibilities include PopCnt instruction and SSE 4.2 support; without these, Windows 11 24H2 (the minimum version supported after October 2025) will likely BSoD on boot.

Some of the softer requirements may be attained by changing partitioning from MBR to GPT, changing boot mode from CSM BIOS emulation to UEFI, enabling Secure Boot, and enabling TPM, either as such, or drilling down into CMOS Setup to where the processor vendor implements this as a fTPM.

So far, so good - but if you can't pass the PC Health Check or the Windows 11 Installation Assisitant won't install, then you'd have to resort to an "unsupported" state via bypass methods e.g. Rufus.  I don't see a great future there; the PC may be fine, until some update or annual new version starts to invoke things that are not there, which could leave the system unable to run, or even boot up.

"If a bad guy can run code on your system"...

Microsoft's 2000 Ten Immutable Laws of Security still make sense to me, even if the battle to keep our computers "Personal" has long been lost.  The list has been weaseled to pass off "the cloud" (= other people's computers) as safe enough, but the original is here.  The first Law:

"If a bad guy can persuade you to run his program on your computer, it's not your computer anymore"

I'd show you the rest of the laws, virtually all of which are broken by the unwanted intimacy of current vandor (vandal/vendor) practice, but the WayBack archive page first bordered on the unusable (refreshing banner ad moving the page, refusal to copy selected text to clipbord or print the page), then after coerced "donation", lost where I'd come from and failed to load the page when the URL was re-pasted.  Enshittification is certainly not unique to a few big vendors; buggy code is everywhere, and it can be hard to distinguish stupidity from perfidity!  Bah, humbug, etc.

Should you trsut your vendor?

At the top of the Trust Stack is the intent of the party to be trusted; at the bottom is the competence to do what they intend to do.  There have been updates that either trashed data completely, or accidentally placed it out of reach, raising concerns about the bottom of the trust stack, as if the need to constantly fix code via "updates" wasn't enough.

Most of the links are about a scenario where the user profile subtree in C:\Users was shunted off and replaced with a new profile, so at least the files could be found... unless they couldn't in some cases.  However, I remember a much harder crisis where user data was deleted completely, not in the recycle bin, due to a side-effect related to... OneDrive (formerly called SkyDrive, until someone watched the Terminator movies and suggested a branding change).

It is utterly indefensible for a code vendor to delete user data, no matter what they were trying to do with it; the sheer arrogance beggars belief. Moving directory file entries to a C:\Windows.old is one thing, but to delete completely and irreversibly, is quite another risk to take with what is not yours.

So... should you trust the "man behind the curtain"?  After all, well-resourced professionals with a large budget should keep their servers running more reliably than a home user's system, and you may feel that is true for you.  

But leaving aside vendor priorities and intent, the fact is that there's nothing magical about what the cloud is made of; it's all stacked layers of code with significant error rates, whether it's the cross-platform compilers, the microcode squirted into what used to be "hard logic" processors, a UEFI as complex as Windows 95 (or "extensions" thereof), the firmware within off-processor components as complex as MS-DOS, web browsers and the unwashed junk they have to run, or the strapping together of these things in de-featured web Apps and PWAs.

We have no insight into what goes on in cloud servers; the fixes, emergency kludges, crises narrowly avoided or not, the data loss affecting "only a few users", etc. until a Cloudflare mess wakes us up.

Emaul Attackments: .HTM vs. .PDF Risk

My bank used to send statements via email as .PDF, but now sometimes switch to .HTM(L) file attachments instead. Here's why that's an elevation of risk...

Both HTML and .PDF files can contain auto-running JavaScript, elevating the risk from "reading a document" to "running a program".  But whereas one can (and should) disable JavaScript in Acrobat Reader, it's impractical to do that for the web browsers that typically "open" HTML files.  

Microsoft's Chromium-based Edge does not run JavaScript in .pdf files, at least as at August 2022, so these files are still safer than HTML even if "opened" in Edge.

Inspecting the bank's HTML "statement" in Notepad shows JavaScript followed by an encrypted mass of content, which could be (and do) anything.  Here's the start of a "real" bank statement "document"...

-script type="text/javascript"-
document.write(decodeURIComponent(atob('JTNDaHRtb... 

...munged to invalidate HTML syntax for safety; here's a suspected malware sample...

-script type="text/javascript"-
document.write(decodeURIComponent(atob('JUVGJUJCJUJGJT...

...can you tell the difference?  Why should I have to trust embedded code to "read a statement"?

Automated messages containing attachments and/or links are always hi-risk, as it's so easy to forge what the recipient sees as "message text" - and already I see fake "email statements" from "my bank", given the message dates don't correlate with statements as seen via the bank's web site.

So, let's hope the bank re-thinks this strategy, rather than reprise "Banking On Java"

The HTML problem

Using HTML everywhere as "rich text" for "documents" started with the "everything is a web page" mania of Windows 98, where HTML Application files (.hta) abounded, and HTML Templates (Folder.htt) were dropped into file system directories and namespace folders to create a "web" look.  This was when Internet Explorer was meshed deeply into Windows, to support Microsoft's claims it was not a separate bundled program competing unfairly with Netscape.  HTML also became the new .chm Help at this time.

Using HTML as rich text for "documents" creates a wide safety gap between the low skills needed to use a system, and the higher skills needed to use it safely.  The seeds of this lie in the Object Oriented Programming concept, where "documents" are "objects", and all objects can have Methods (code) and Properties (variables).  Normal programming practice is to interface with such objects by asking their methods to expose their internals - and so "reading a document" becomes "run code".

JavaScript

How risky is JavaScript - doesn't it just work safely within a single document or page?  Well, it's powerful enough to be the sole code for Progressive Web Apps, that are expected to become ubiquitous as the "desktop" programs we use today - and malware use is already rife.

PDF: Safe, Print; Pick One

Geek summary: If you print a .pdf and "enable all features", you're enabling all risks!

Adobe's PDF is a significant edge-facing risk, and unlike their wretched Flash, no signs of it going away soon.

The email risk

"Opening" a .pdf in a web browser is risky enough, but a bigger risk are all those automated .pdf emaul attackments; "invoices" spawned by generic accounting packages, "forms to print, sign, scan and return", etc. Even if there's a pretense at certificate-based "security", the sender still expects the recipient to trsut a handful of easily-forged pixels, boilerplate text, and a From: address as being "from someone you know".

Evaluating risk of incoming email links and attachments needs proof of trusted human intent to send, not just which human's system appears to have sent it, as malware is likely to spread via harvested addresses that can be used to populate both the From:, and the To:, CC: and BCC: sides of the fence. When both From: and To: addresses are harvested on the same infected system, the malware will most likely be "From: someone you know"!

Digital signatures proving it came from that user's system don't address that problem; you need to read the message "text" to see if the human sender intended to send the message and the attached file(s).  A smart sender will write such text, but the lazy, clueless or disinterested will not; when the accounting program or whatever pops up a boilerplate message (typically "you need Adobe Reader to open this file" with a link that one hopes doesn't point to a malware server), they'll just click Send without changing (personalizing) this text at all.

So we have all these near-identical boilerplate messages bouncing around, telling users to "open" files and/or click links to install software, with attached .pdf - and those files are exploitable enough, without the need to trigger heuristics by faking the file type to "open" raw code.

Risky "data files"

Risks from "data" files stem from the object model, that treats everything as an object, and all objects can have Properties (internal variables) and Methods (internal code) that other objects can use.  The human user is just another "object" that happens to be at the end of peripheral UI input devices.

This is the code equivalent of dumbing down user concepts of "read", "edit" and "run" to just "open"; the same safety-oblivious mindset underlies both, and the interface programming model makes this worse by swinging from reading exposed Properties to running Methods to return these.  That implies the object is now trsuted to run code, to get anything out of it.

Specifically, .pdf is designed to run JavaScript hidden from the user, and even if this script is prevented from "doing anything nasty", it can be leveraged to set up the stack to climb the exploit ladder to running raw code.  If you look in the Acrobat (Reader) Edit, Preferences section, you'll see other exploit opportunities such as multimedia, "opening" other file types, etc.

These risks have been obviously non-theoretical since the Concept "prank macro" and subsequent destructive (including hardware-killing CIH payload) Word and other MS Office macro malware, yet that didn't stop Adobe baking the same risk into the .pdf standard years later.  

Today's reading suggests Microsoft quickly saw the risks, but at the time, I remember the first response had two purposes; reassure users this was "not a virus" but just a "prank macro", and provide a removal method specific to that particular vir.. uh, "prank macro", as if there'd never be another one. It took years to (more or less) fix that "works as designed, won't fix" easy exploitability, and that happy period of easy scripting arguably established the commercial viability of malware.

Protected Mode

Fortunately, we have Adobe's Protected Mode to keep us safe - at least until we print.

I've always been creeped out when "reading" a .pdf and having to print it out, when that asks me to "enable all features".  What "features"? Allowing the "data file" to drop and run code?  Apparently yes, this is exactly what happens if this actually exits Protected Mode (not that Adobe tells you this in that happy "enable all features" dialog box).

It's also good to ensure you use Reader and not the full Acrobat as your default .pdf "open" file association, as full Acrobat duhfaults to disabling Protected Mode!

I hope you've been clicking this article's implicit links along the way, as that's where I "show my workings" as to how I understand this situation.  

Now consider how many of those links "opened" a .pdf in your web browser...

Driver Cure or Driver Curse?

If you'd just dropped into the PC world last week, you'd think all software was perishable and had to be continuously refreshed. Must always have the latest version BIOS, drivers, etc.

This attitude runs counter to an older wisdom, that the first question when something goes wrong, is: "What changed?" With this in mind, the last thing you want is vendor-driven changes to your code base; in fact, for a critical working system, you want no changes at all.

The logic behind all this is contradictory...

• Software vendors make mistakes, requiring software repairs ("patches" or "updates")


• This happens so often, you may not be able to keep up with the constant flow of updates


• So it's best to let the software vendor push updates whenever they see fit

This boils down to: Trust software vendors to push changes into your code, because they fail that trust so often you can't keep up with the pace of quality repair required.

So, should you always patch, or never patch? Or sometimes patch? If "sometimes", then on what basis do you use to decide what needs patching?

Balancing risks

Some code is so critical, you may consider it too risky to change, e.g. BIOS and device firmware, device drivers, core OS code, and code that is running all the time and can crash the PC if it goes wrong.

Some code is so exposed to arbitrary unsolicited material, you may consider it too risky to leave unpatched, for fear that malware may exploit defects in the code to attack your PC.

Code should never fall into both of the above categories; if it does, you're probably looking at really bad software design. For example, integrating a web browser so deeply into the system that it's indivisible from the system's own UI, would be a bad design decision. Or consider a service so critical to the system's internal functioning that the OS shuts down the whole PC every time the service fails, that is waved at the Internet on the basis it's "networking"; that would be a really bad decision (Lovesan vs. RPC, remember?).

Trust me, I'm a software vendor

The two reasons not to trust a software vendor are incompitence and perfidity. A vendor who claims you "must" leave your system open to a constant stream of fixes, has declared themselves incapable of writing code that can be trusted to work properly.

And frankly, when even "legit" vendors hide deliberately user-hostile code within their products, set to automatically deny you service if its logic considers your license state is invalid (product activation) or distribute rootkits within "audio CDs" (Sony), I'd not trust any vendor's ethics.

Finally, even if you trust the vendor's ethics, you have to look at the mechanics of code distribution. Fakeware abounds, so when a third party claims to serve you fresh code from the vendors you trust, you have to ask yourself how trustworthy is that third party?

You also have to ask why you'd trust a particular software package. Open source advocates would say it's because you can read the source code yourself, or at least feel safer in that others have done this on your behalf. Closed source advocates would say it is unrealistic to read source code yourself, and instead would point to pre-deployment testing that would pick up unwanted behavior before the code was used in the real world.

Patches and updates change both of these equations, because now the code you read and/or tested, is no longer the actual code that is running. Any patch may add unwanted behaviors that favor whoever pushed the patch into your system. For the same reason, you should avoid software that stores "your" settings on the server side rather than on your PC (e.g. Real Player, many Instant Messaging apps) and "Privacy Policies" and End User License "Agreements" that state "these terms can be changed whenever we see fit", as so many do.

The race to patch

There's a race between freshly-released malware, vs. your antivirus scanner that protects your system. When a new malware is found, the antivirus vendor analyses the code to work out how to detect it, then how to safely remove the code, then that logic is packages as an update that your PC's scanner pulls to update your protection.

Compares this to what happens when a new vulnerability is patched. The malware coders can compare pre- and post-patched code to isolate the fix, then work out what the unfixed code did wrong, and thus how to attack that code. The exploit code is then packaged into malware prepared earlier, such as a downloader stub, and that's pushed into the wild.

Notice the similarities between these processes, i.e. recognizing and removing malware compared to extracting and exploiting code defects from studying patches?

If you rely on resident antivirus to protect you, then you are betting on the av vendor to beat the malware in the race. By the same token, you may expect malware coders to be fast enough to exploit your edge-facing code before the patch arrives to fix the defect. Hence the manic rush to patch, for fear of prompt exploit.

It's actually a bit worse than this, for two reasons. Firstly, sometimes it's the malware folks who find and exploit defects before the code vendor learns about these and fixes them. Secondly, software vendors have to ensure their patches don't break any systems, whereas a malware coder just wants it work enough of the time to spread, and doesn't care if it breaks other systems in the process. Less rigorous testing means "faster to market", right?

Self-spreading malware can also spread faster from more systems, and thus beat the patching or updating processes to the punch. Malware can be delivered in real-time via pure network worms, or links to servers that are themselves updated in real time. Often the malware that enters the system is just a downloader stub; it only has to last long enough to pull down the "real" malware, which can replace itself in real time as well.

Edge-facing software

With all this in mind, you can see why one would want to patch edge-facing software as soon as possible. Examples include web browsers, Java, Acrobat Reader, Flash and media players, and anything that is constantly exposed to the outside world, such as software that waits for instant messages or "phone" calls.

The best solution is to remove that edge-facing software, and thus the need to patch it. Do this whenever you don't need that software, when the software or its vendor are too flaky to trust, or when the update process itself is something you want to avoid.

For example, you may catch a vendor trying to shove new edge-facing software as "updates", even when that software is not present and therefore doesn't require patching. That's how Apple used to push Safari to PCs running iTunes or QuickTime, until they were pressurized to stop.

For another example, a vendor may decide you don't need to be asked before updates are pushed, or even told when this has happened. And when you look at that vendor's updater, you find it running as multiple scheduled tasks; then when you look at the details, you find a task that appears to be run once a day, is actually repeatedly run every hour throughout the day. That's the equation with Google, and why I would avoid any edge-facing Google software.

If you can't avoid edge-facing software, then you can protect yourself in two ways; by updating it as soon as possible, and/or by choosing such obscure, small-market-share products that they aren't likely to be attacked. The latter is like living in an unlocked shack in the countryside; that works not because shacks are "so secure", but because there are so few attackers around.

Driver Cure or Driver Curse?

So now we come to Driver Cure, which is a third party product that pulls in the latest versions of your device drivers. Would you want this? I'd say no, for two reasons.

Firstly, device drivers are code that runs so "deep" in the system, that any mistakes are very likely to crash the entire OS, leaving the file system corrupted, data files unsaved, etc. Device drivers usually run all the time, so bad code may prevent the system from being able to boot or run at all, even in Safe Mode. So I definitely don't want unexpected changes to this code, any of which may cause the system to stop working.

Secondly, device drivers are not edge-facing, so the risk of explosure exploit should not be high. That means less reason to patch in haste.

Thirdly, if malware were to be integrated into the system as deeply as a device driver, it would have considerable power and be very hard to remove. So we'd want to know a lot more about third party software that inserts "drivers" into the system.

The "Driver Cure" folks also push XoftSpy, which was one of several hundred fake anti-spyware scanners, until they supposedly "went legit". As such, sites and blogs may no longer call XoftSpy "malware" for fear of being sued; we may instead consider it as a legit antispyware that isn't very good at what it does, and costs money where better products are free.

So, in spite of "reviews" like these, I would avoid Driver Cure and anything else from that particular software vendor or distributor.

Spybot 1.6 and Bart PE

Technorati tags: Bart PE, maintenance OS, malware

Malware scanners tend to focus on resident protection rather than intervention and clean-up, but Spybot has always had a clue there.  Not only does Spybot explicitly support Bart PE as a formal scanning platform, it can also be aware of inactive registry hives, e.g. if you were to drop an ?infected hard drive into a Windows host system to clean it from there.

Bart has a plugin facility to integrate tools, and whenever there's a new version of a plugged-in tool, there may be changes required, or new unwanted behaviours to work around.  Such is the case with the new Spybot 1.6

Spybot 1.6 plugin changes

A Bart plugin is a set of files that control how a program is integrated into a Bart CDR.  Build-time instructions are defined in an .inf, menu integration via an nu2menu.xml, runtime control via a .cmd (if needed), and human documentation via an HTML file.

The .inf defines what files are to be copied to the CDR and where they are to be located, in the SourceDisksFiles and SourceDisksFolders sections.  If you've used SourceDisksFiles to explicitly name every file from within Spybot 1.4 or 1.5 to be copied to CDR, and you then drop in the Spybot 1.6 file set and build a new Bart disk, then you'll find Spybot will fail to launch from the disk.

If so, you can fix this by adding a line to include sqlite3.dll, which is a new file not present in earlier versions of Spybot SD.  Or you can use wildcard syntax to include all dll files, i.e. *.dll as files to be included.

Unwanted behaviour

Spybot 1.6 has a controversial new feature; it deletes Temp files when it starts up.  This is "controlled" by a 6-second dialog box that appears as Spybot starts up (so if you start it and walk away, you'll miss it) and defaults to "Yes, delete temp files".

This is a bigger problem within the Bart environment, which often has troublesome graphics due to unrecognised display chipsets.  In my first Bart session with Spybot 1.6, I expected the dialog, but it appeared with blank buttons.  By the time I checked out what button was what, testing on another PC, the 6 seconds were up, and I'd lost material I'd have preferred to include in further malware scans.

There is a rather obscure fix for this, which I will add to my Bart plugin's .inf file, using one of the registry modification sections.  If using the RunScanner plugin to launch Spybot (should not be required, as Spybot "knows" about such needs), then you'd want to delay the RunScanner redirection until this value had been read by Spybot after starting up - else it will look for it in the inactive (target) hives instead.

Should You Detect Old Malware?

Technorati tags: Malware, Safety, Security

We've gone from thinking of software as a "durable good" to evolving under selection pressure.  This certainly applies to malware and blacklist-driven scanner countermeasures, which are assumed to become either extinct or irrelevant over time. 

Who needs old scanners?

You may want to keep an old scanner if it still detects stuff other scanners can miss, or if it was the last version that ran in your environment - though as an "extra" on-demand scanner, not as sole resident protection, of course.

For example, Kaspersky's CLI scanner no longer runs under Bart, and I haven't adapted AdAware 2007 (which I don't particularly like) to run in Bart either.  There are still manual updates for AdAware SE, so that's still "current", and Kaspersky CLI still works in Safe Cmd.  However, I may want the safety of formal scanning with Kaspersky CLI, and for that, I'd need the last "old" version and updates that still worked from Bart.

Another example is McAfee's Stinger.  Just as an "old" Kaspersky CLI may find stuff other updated scanners will miss, so it is with the even older Stinger - it's particularly good at catching TFTP-dropped malware and some bots, both of which are likely to be found in an NT that has not patched RPC against Lovesan et al.

F-Prot's DOS and Win32 CLI scanners are also discontinued, i.e. no further updates, but are still useful.  Specifically, these scanners will often detect "possibly new version of ... Maximus", and sometimes that rather loose and false-positive-prone detection still finds things others miss.  These scanners also find other false positives unrelated to Maximus, so handle with care.

Does old malware matter? 

Firstly, you may encounter vintage malware on vintage systems and diskettes (e.g. boot sector infectors on old DOS or Win95-era PCs, old MS Office macro infectors in "documents" from old systems).  Malware of that era were mostly self-contained and fully automated, and often had destructive payloads, so they will still bite... so you'd want to detect them.

Secondly, think of the spammer equivalent of the guy who still uses a PC built from old parts running MS Office 2000 on Windows 98, because these old feeware programs pre-date automated defence against piracy - i.e. no software budget.

A less-obvious feature of botnets is that those who own them, don't want folks controlling them for free.  So if you want to send spam through a modern botnet, you will probably have to find someone and pay them.

On the other hand, old bots that are still in the wild, may have been cracked so they can be operated for free - or may simply pre-date the rise of malicious info-business and thus lack modern mechanisms to block control.  In which case, our impoverished spammer may use these instead - so it may still be prudent to detect and kill them off, especially in the context of poorly-patched or defended systems (e.g. unpatched Windows 2000, no firewall, outdated or missing av).

SysClean on Bart PE

Technorati tags: Bart, antivirus, mOS, SysClean

Trend SysClean is a self-contained, stand-alone malware cleaner that can be used from the Bart PE boot CDR environment.  Unlike many free cleaners such as McAfee Stinger and Avast Cleaner, it detects most things that a full-range resident av would detect, rather than a small subset of these.

On the face of it, it should be easy to run SysClean from a Bart CDR boot, but there are a few gotchas that can mess you up.  If you're one who has sorted those out ages ago, yet recent found SysClean to no longer work in Bart. 

Either way, read on...

How SysClean works

SysClean exists as a SysClean.com engine, plus a larger signature data file with names such as LPT%VPN.xxx, where xxx is a 3-digit number that rolls over from .999 to .000 or .001 whenever there have been that many updates.  You can wildcard the data file as LPT$*.*, LPT$VPN.*, LPT$*.???, etc.

SysClean does not have to be installed before use, which makes it attractive as an intervention scanner.  There is no integrated updater, so you'd manually download the latest signature data before use.  As the engine is also subject to change, I'd recommend downloading a fresh engine alone with new signature data.

SysClean.com is not a true .com file, i.e. it is not a DOS-era 16-bit memory image of code that runs with all segment registers set to the same 64k space.  Instead, it is a Win32 executable that unpacks itself and then jumps into itself to run.

From all of the above, you can predict pitfalls when using SysClean from Bart CDR. 

General issues

The easy way to avoid these pitfalls, is to copy the files to a HD location and run them from there, all done within the same Bart boot session.

If you want to integrate via a SysClean plugin into Bart, you have to essentially automate this process, as well as avoiding a few other issues.

As SysClean writes to its own location, that location must be writable (i.e. can't run directly off the CDR) and must have enough free space to unpack (which may not be the case if running within a small RAM drive).

As SysClean.com chains into the SysClean.exe that it spawns, you must ensure your automation logic does not prematurely continue, i.e. after SysClean.com terminates but while SysClean.exe is still running.  The Start /W approach is likely to fail in this way.

SysClean launches sub-tasks, and that means it may fail in environments that impose limits on the number of tasks that can run at the same time.  WinPE, Bart PE and Windows XP Starter Edition may fall into this category.  If you have one "wizard" batch file that launches another batch file that launches a set of scanners in sequence, then scanners that start additional processes may hit the limit.

Some of the scans are launched as sub-tasks that run in "DOS-style" CLI windows.  If you used a tool within your launcher batch file to hide the batch file window, this may hide the CLI subtasks as well - creating the impression these aren't running from Bart.  I haven't gone into this, e.g. removed my CLI winder hider etc. and thus am not sure the CLI scans are done in Bart, or really are skipped.

Recent failure pattern

If you've beaten all of the above problems years ago, you may have hit the following failure pattern recently...

SysClean extracts itself and runs OK, presenting you with its GUI.  You then slick the Scan button and it starts scanning memory, before scanning files.  But it never completes this process; even after the CD and hard drive burbling stops, it just sits there "scanning memory..." forever.

The system and app haven't crashed.  If you click to stop the scan, nothing happens, but if you click the [x] to close SysClean's window, that works.

Quick fix

If you run SysClean again, within the same Bart session, it works perfectly!

Why does if fail the first time?

A few months ago, SysClean changed its behaviour; at the start of the scanning process, between checking memory and scanning files, it now pops up an "OK" status dialog, to the effect that no viruses were found in memory.

When run in Bart, this dialog never appears - so you can't see it and you can't click it away.  And thus, SysClean will stall, waiting for an "OK" click that will never come.

Why does it work the second time?

When SysClean runs, it spawns a resident process called TSC.BIN that remains running after SysClean is done.  This is spawned before the failed "OK" prompt; I suspect it's spawned as early as possible, to run as "air cover" should any active malware code try to interfere with the scanning process.

The problematic prompt is only launched if TSC.BIN is not already running when SysClean starts its scan (perhaps TSC.BIN is itself the origin of the prompt, as part of its initialisation). 

So the first scan starts TSC.BIN and suffers the UI stall, whereas all subsequent scans during the same Bart session will already have TSC.BIN running and are OK.

I see one SysClean plugin approach may side-step this issue by scooping the extracted files into the plugin, rather than having the plugin run SysClean.com to extract them at runtime.  This may avoid the problem if it is the extraction process that triggers the dialog - though that seems unlikely.

Malware "War", Lost Territory

Technorati tags: Malware, Safety

I've often seen the malware situation described as a "war", and conventionally, wars are fought over territory. 

What territory has been lost to malware?

Consider various integration points that are now routinely defended against usage, on the basis that the only things likely to use these, are malware.  These OS "features" are now effectively "owned" by malware, in that legitimate software will trigger defence alerts if they are used.

Consider a number of ill-advised features that are designed to allow arbitrary material to automate the system, e.g. MS Word auto-running macros, auto-running scripts in HTML email "messages", \Autorun.inf processing on USB flash drives, etc.  Today, these will typically be disabled, because the most likely use will be by malware.  So Malware "own" that, too.

Consider several business models that involve messages, attachments or links sent by the service's site, such as email greeting cards.  As malware can arrive via forgeries of such messages, usage is limited to those who are too dumb to know the risk they are expecting the recipient to take, which is a smaller and more limited demographic than when such services were first started.  Effectively, these kinds of businesses and practices have been killed by malware.

Should we scorch and abandon some of this territory?  For example, remove OS integration points that are hardly ever used by anything other than malware?

Should we assess likely future "ownership" before creating new technologies and features that are likely to be swamped by malware?

Norton Security Scan - False Positives

Technorati tags: Malware, Risk Management, Safety, Bug

The Norton Security Scan utility is free, and bundled with the Google Pack.  It's an on-demand scanner that looks for malware and risks.

Unfortunately, it detects protective settings applied by Spyware Blaster and similar tools, as being the malware these tools are protecting against. This is a generic type of bug that often arises when tools assume anything other than default is a hostile change, or when overly-loose detection cues are in effect.

Specifically, settings within HKCU's P3P\History that block unwanted cookies, are detected as evidence of malware.  In the case I'm currently working on, only around 5 of over 100 protective entries were detected in this way.

The tool then claims it is unable to fix these problems, which is just as well, as doing so would actually weaken system safety.  The end result is similar to Winfixer et al, i.e. false-positive (actually, reverse-positive) detections plus referral to feeware products if these are to be "fixed" - so one hopes Symantec will fix this sooner rather than later.

The case I'm working on is interesting, as it was brought in because it was slowing down, with malware as the suspected cause.  Formal scanning finds no active malware, and one wonders if the slowdown was the result of installing Google desktop etc., with the false-positive from Norton Security Scan as the red herring.

I'd like to try Norton Security Scan within mOS contexts such as Bart or WinPE CDR boot, but it appears as if the product is available only via Google Pack.  There are no references to it at Symantec's site, and the FAQ doesn't seem to consider "so where can I download this thing?" to be "frequently asked".

Norton Life Sentence

Technorati tags: Antivirus, Safety

This post is about Packard Bell, Norton Antivirus, Norton Internet Security and OEM bundling.  For many readers, those four are all "yuk" items already...

Formal maintenance

Every "WTF" (i.e. ill-defined complaints, or just in an unknown state) PC that comes in, gets the formal treatment; 24 hours of MemTest86 with substituted boot CDR to detect spontaneous reboots, Bart boot HD Tune, and Bart booted formal malware scans.

This laptop cannot perform the RAM test because it keeps switching itself off, presumably because it is "idle" (no keyboard, HD, CD, LAN, mouse etc. interrupts).  CMOS Setup shows no facility to manage such behavior, which is disabled in Windows already.  Strike 1, Packard Bell.

The hard drive and file system are fine, and absolutely no malware at all were found on multiple formal av and anti-"spyware" scans, nor in four anti-"spyware" scans done in Safe Cmd.  Spybot did note that the three Windows Security Center alerts were overridden, and this was later confirmed to be a Norton effect.

Specs and software

This is a fairly high-spec laptop; Mobile Celeron at 1.5GHz, 1G RAM (!), XP Pro SP2, but puny 45G hard drive with 4G stolen for the OEM's "special backup" material.  The date stamp on the Windows base directory is 17 March 2006, which matches that of the SVI and "Program Files" directories too.

It has Norton Internet Security 7.0.6.17 OEM(90) and Norton Antivirus 2004 10.0.1.13 OEM(90).  That's from the Help in these products; the same Help describes using Add/Remove to uninstall them. 

Attempted uninstall

Both programs are definitely present and running; in fact, one gets nags every few minutes about antivirus being out of date, and firewall being disabled.  A check confirms both to be true; neither Norton nor XP firewall is enabled, and Norton's subscription has expired.

However, Add/Remove shows no Norton entries other than Live Update.  In fact, the expected slew of OEM bundleware are not there.  A lethally-ancient Sun Java JRE 1.4.xx was found and uninstalled.

Start Menu shows an "Internet and security" flyout with icons for Norton Antivirus and Internet Security.  No icons to uninstall these products from there.

What I did find in a "Packard Bell Support" Start Menu flyout, was a Smart Restore center, from which bundleware could be highlighted and installed or uninstalled.  There was an alert to disable Norton's protection before doing this (more on that later), but either way, clicking Uninstall did nothing (no visible UI effect) and clicking OK after that, appeared to install Norton 2004 again.

To be continued...

Good Things Here...

Technorati tags: Malware, maintenance OS

Some folks get it...

http://blogs.technet.com/secguide/archive/2007/07/12/malware-removal-starter-kit.aspx

Using the Windows Preinstallation Environment (Windows PE) in combination with free anti-malware programs, the kit provides you with a low-cost, effective strategy and tool recommendations that you can use to vanquish malware attacks

...while some folks don't:

http://blogs.msdn.com/rflaming/archive/2006/09/20/763960.aspx

From a security perspective, when you get owned running under a Machine-wide account, game is over and you have to flatten the machine to get back to a secure state. 

By "it", I mean the defense-in-depth concept that the battle doesn't end when malware gets into your PC.  Machines get "owned" all the time; the majority of spam is carried by botnets running on such systems, and surveys have indicated a high percentage of PCs are running malware. 

If the only option for such systems is to "just" flatten and rebuild, many consumers will simply shrug and prefer to stay infected.  After all, they tolerate rootkits dropped from audio CDs, DoS (activation) payloads built into their OS, adverts from all over the place, etc. so why should they mind if a smidgen of bandwidth is used to DDoS unpopular entities such as the RIAA, or send out the same spam they get every day, either way?

The problem with "just wipe and rebuild" is not the pessimism that a cleaned PC will really be clean, but the optimism that a rebuilt PC will stay clean.  In reality, both approaches are complex battles that may be lost.

Security Guides Blog

The first link is from SecGuide, who may be the first Microsoft team to offer end users the tools they need to formally manage malware on infected PCs.  They may not be as far down that road as some Bart-based solutions, of which an example is shown in this slide show, but in-house Bart projects are usually too complex to be offered as an off-the-peg solution for end users to download and use.

The SecGuide approach is based on WinPE 2.0, which is now available for end users via the WAIK.  The process of integrating tools into WinPE, and building a WinPE boot disk, is pretty daunting, so I was wondering if combining David Lipman's Multi-AV tool with Bart PE would be easier?

In the big picture, we need to market the clean state against the accepted state of living with resident malware.  A non-destructive cleaning approach is a key element, and it's good to see parts of Microsoft getting this.

Windows Installer

The second link is from Setup Sense and Sensibility, which is a fascinating insight into the Windows Installer and how this has developed in Vista in particular.  The perspective appears to be 100% rooted in the concerns of corporate networking, and centered on per-user permissions and control.

The trouble is, this approach just doesn't fit the outside world of free users and the one or few PCs they use.  There's no "admin" to "do things for" the user; no tight white-list of permitted applications, and the user should have full and unfettered control over the PC.  A single PC may represent the user's entire infrastructure, so there's no "easy way out" of wiping and rebuilding desktop systems while data is safe on the server. 

Moreover, the same user will do multiple different things in the same logon session that should have differentiated rights.  Simply giving all processes the same rights just because they occur in the same logon session is next to useless, as even the most limited user account rights will allow the user's data to be edited, overwritten or trashed.

I've covered aspects of this issue many times, such as the adverse effect of flattening natural obstacles and the janitor account concept.  UAC is a step in the right direction, as for the first time it leverages the user's control over automated processes - the reason it is so "ugly" is because it is so at odds with the assumptions underlying NT's development, i.e. that automation would always be done by "proper" entities and that the user should be swept aside to facilitate such automation.

Malware - Is That All You Ever Think About?

Technorati tags: Malware

Folks could be forgiven for asking:

Why do you care
About malware?

Malware is the bulk of a larger problem which is vendor-pushed code.  Nothing can overwhelm support resources as widespread automatic insertion of bad code can do.

For in-house system administrators, it's a major headache, but for a tech servicing multiple single-PC sites, it can be a disaster.  If you offer an SLA (Service Level Agreement) that is insufficiently escaped by weasel-wording and disclaimers, then one big outbreak can put you out of business... how do you "resolve within 48 hours" when you have 100 sites per tech needing urgent attention within the same hour?

So yes; just as someone interested in completing university studies may switch to soldiery as driven by self-preservation demands, so I have an interest in malware.  And just as a soldier has an interested in keeping his weapons in working order, I have an interest in maintenance OSs such as Bart and WinPE 2.0, as well as the politics that keep these tools out of the hands of those who need them most.

Sharp readers will have noticed my definition of the "larger problem" encompasses automatic OS and antivirus updates, various ad-hoc "update" facilities built into arbitrary programs, Google's "update everything" tool, and codecs "needed" to play arbitrary content. 

All of these break best-practice rules on code changes:

• Do not allow others to change your code
• Log all code changes
• Ensure all changes are reversible
• Ensure changes do not "kick away the ladder"

In essence, the logic behind "code of the day" is broken:

• When our code breaks, it can't be trusted
• This happens too often to manage manually
• So trust us to push more code whenever we see fit

Does not compute.  Yes, I see the need to patch OS and exposed surfaces as soon as possible, but I also see the need to reduce exposed surfaces made of code that is not trivial enough to be relied on as defect-free.

And no, I don't recommend Google's "update everything" tool.