Windows as Maintenance OS

XP as Maintenance OS

I consider a maintenance OS to be the best-practice approach to traditional malware ("viruses", "worms", "trojans") but as at May 2004, not necessary for commercial malware ("spyware" etc.).

I expected that to change when Digital Rights Management (DRM) becames more commonplace. DRM involves user-hostile code that legally operates by stealth; in fact, it may be illegal to document or provide tools for removal thereof.

However, as the commercial malware scene hots up to more closely resemble traditional malware behaviour, I wonder if a maintenance OS will soon be required to manage this even without the DRM factor. In July 2004 I saw a porno dialer (unknown to AdAware 6) that was active in XP's "Safe Mode"; it did nothing when SpyBot 1.3 scanned for malware, but popped itself up when SpyBot did the cleaning pass. So soon, if not already, best-practice may require formal scanning for commercial malware as well.

Can XP maintain itself?

There are those who dispute the need for a maintenance OS, claiming that Windows XP can manage itself. This is clearly absurd in data recovery or bad hardware situations, given XP's propensity to spontaneously write to every hard drive volume it sees, but in this article I'll play "devil's advocate" for the notion that XP could manage malware effectively and safely, if it were further developed with this in mind.

Where malware is concerned, "Safe Mode" isn't. I'd say the requirements for a malware-safe mode would be as follows...

1. Core code is known-good

Most modern malware exists as stand-alone files, but we still see new intrafile infectors that infect the insides of existing code files. When these files are part of the core set, no further integration is required; when the OS runs, so does the malware, no matter how effectively runpoints and integration opportunities are suppressed.

That's why a truly malware-safe mode would have to be known to be free of any internal changes. A dedicated and sealed store of core code might attain this, but is at odds with the need to keep this code patchable. I expect patch spoofing and DoS to become a bigger factor in tomorrow's malware scene.

Even if the core code was kept inviolate, and checked itself for changes before running, malware could simply bonk the code or check data in order to deny access to XP as a hard drive based anti-malware platform.

2. Absolutely ALL runpoints are disabled

Not just the normal system startup axis, but all BHOs, persistent handlers, Desktop.ini, file associations, drivers, etc. Malware can spoof any of these, so all of these have to be suppressed if you suspect you are dealing with active malware.

It's obvious that XP's Safe Mode doesn't adequately suppress potential malware integrations, when even commercial malware can tripwire attempts to clean it in Safe Mode.

3. Absolutely ALL runpoints are listed and manageable

As previous point, with the added requirement that these should be enumerated and manageable across all user accounts from one "safe admin" mode. As it is, we have to rely on Regedit or a variety of 3rd-party reporting and UI-ing tools to manage shell extensions, Layered Socket Providers etc. that MSConfig doesn't display or manage.

I don't see the above as attainable, so I predict the need for a maintenance OS to manage active malware will remain - and as at July 2004, the only serious contender for an NTFS malware cleaning platform is BitDefender Live. But partial attainment of the above would improve Windows management, and may help when the user is unable to cope with the rigor of a maintenance OS.

Even if Windows were to fully attain the requirements to manage itself from a malware perspective, you'd still need a maintenance OS for other purposes, with data recovery at the top of the list.

Back to index