Saturday, April 07, 2012

What is a Maintenance OS

What is a Maintenance OS?

Often it's unsafe to operate Windows for various reasons:
  1. There is active malware infection
  2. The file system is corrupted
  3. The hard drive may have problems
  4. Other hardware may be flaky
  5. Other running tasks may get in the way
  6. Direct hardware access is required
In these situations, you need a maintenance Operating System (mOS).  The tasks you'd use this for would fall into these broad categories:
  1. Data recovery and file system repair
  2. Management of active malware
  3. Any tasks requiring Windows to be "under anesthetic"
  4. Hardware diagnostics and firmware updates
Features of mOS are: 
  1. It does not automatically write to the hard drive 
  2. Does not depend on hard drive contents to be the same
  3. Does not run any code from the hard drive whatsoever
  4. Allows direct access to hardware
  5. Requires only a small subset of hardware to work perfectly
The traditional mOS for Windows 9x has been DOS mode, but this is no longer up to the task in the XP era:
  1. Cannot read post-FAT file systems e.g. NTFS
  2. No longer supports full range of hardware
  3. Limited memory management
  4. Modern developers may lack DOS skills and tools
  5. Licensing issues with respect to XP Home
So while one can keep XP within reach of DOS mode maintainability by comparing FAT32 vs. NTFS, hard drives over 137G etc., XP really needs a new mOS! Depending on whether you use the home or identity-based security model, you may need to limit or suppress access from a mOS.  The question then arises as how to do this:
  1. Home vs. Pro differentiation
  2. Content-determined lock-out (flag or password)
  3. Content-determined lock-in (flag or password)
XP Home is intended for stand-alone consumers accustomed to the "home" security model, so the mOS should default to running unless locked out by some sort of HD content; in fact, as malware can spoof this, I'd prefer to see XP Home as always accessible via mOS. XP Pro is intended for business use, where it may be preferable to lose maintainability if it removes the physical access hacking risk that a mOS might pose.  If the HD is inspected for content that will lock out the mOS if present, then the risk of being locked out due to hard drive corruption is smaller than if particular content was required to allow mOS access. 

Some mOS softwares are:
  1. Microsoft PE bootable XP
  2. Bart's PE Builder
  3. Various bootable Linux
  4. Driver-assisted DOS mode
  5. Non-OS environments e.g. RC, ReadNTFS
Microsoft PE builder: This would be the obvious choice, but Microsoft's licensing terms make this available to so few users (basically, only large PC factories) that it's unlikely software vendors will develop tools to run on it.  Even as a DSP (Delivery Service Partner, i.e. small-volume PC builder) and MSDN subscriber, I do not have access to this tool, and so it goes for most field techs who would be the market for data recovery and anti-malware utilities that need a mOS.

Bart's PE builder: This is a 3rd-party utility that creates a bootable XP CDR, and it's free for download (requiring your XP installation CD-ROM to build the boot CDR).  In the absence of an offering from Microsoft, this could become the de facto mOS standard, but it remains to be seen whether software vendors will write for a quasi-OS platform that exists outside Microsoft's fence.  Some Windows programs already run within Bart's PE, as long as a suitable plug-in wrapper is used.

Linux boot disks: Unlike NT, Linux can already function as its own mOS, with boot disks ranging from diskettes (such as that used to host MemTest86) through USB flash drives to CDRs.  Some Linux distros are tailored for this, e.g. Knoppix (a CDR-based Debian Linux).  However, even Linux advocates are skeptical about the safety of writing to NTFS via reverse-engineered drivers.There's been some progress there, though, and now BitDefender Live - available as one large download - comes close to a turnkey solution by fusing these three initiatives:
  1. CDR-based Knoppix (Debian Linux)
  2. Captive NTFS read/write support
  3. BitDefender antivirus
The process of getting up and running with this involves:
  1. Downloading the Torrent stub for the ISO
  2. Downloading and installing the Torrent downloader
  3. Setting up off-HD copies of NTFS driver files
  4. Getting antivirus updates
  5. Setting up these updates so the CDR can use them
There's something deeply ironic about having to learn Linux in order to salvage and maintain NT, but there you are. Driver-assisted DOS mode NT (including Win2000 and XP) does not contain DOS or a DOS mode, but you can use one from a Win9x OS or download a free DOS from www.bootdisk.com. If you avoided NTFS, you can use DOS mode as-is to formally scan for viruses and clean them, delete or rename-away files, or copy off data.  But DOS mode doesn't support Long File Names (LFNs), so you will need 3rd-party tools if you wish to preserve these. I find free Odi's LFN Tools to be useful. These are a set of non-TSR external commands that replace Command.com's internal file management commands with LFN-aware alternatives, such as LMD, LDel, LRen, LDir, LCopy etc.  LCopy is particularly powerful, as it can copy over an entire volume via syntax such as...LCopy  D:\*  C:\BadHD  /A  /S

There are free and fee TSR drivers that enable DOS mode to read NTFS, available from the www.systeminternals.com web site.  However, these don't support LFNs, and won't work with add-on TSR LFN drivers or Odi's LFN Tools, which would otherwise allow LFN preservation in DOS mode. The free TSR takes up around 300k of conventional DOS memory (i.e. double that used by the old DriveSpace 3 compression support), which doesn't leave much room to run anything else. F-Prot for DOS can run under these conditions, but will fail to scan entire NTFS volumes as the NTFS driver fails to recurse the full directory tree properly.  In any case, the free NTFS driver is read only, so a DOS antivirus would be unable to clean anything.

The fee TSR takes a different approach by acting as a wrapper for the hard drive installation's own NTFS code. This may improve the depth and version-compatibility of NTFS support, but also means that corruption or infection of the relevant hard drive code can pose problems. One can use a free non-TSR utility to view and copy off subtrees from NTFS volumes under DOS mode, though once again, LFNs will be lost. 

ReadNTFS takes a while to scan each directory and has to rescan these anew if you retrace your steps; you can't select multiple items to copy off, but you can select a directory and it will copy everything that contains.

Recovery Console: The Recovery Console can be booted from any complete, non-OEM-crippled XP CD-ROM.  It is a useful grab-bag of canned fixes for several problems, but it is not an OS; you cannot run external programs from it at all.  Unless you have set certain registry values in advance, it cannot see volumes other than C: and cannot copy anything from C: to some other disk; even if you do set the relevant values, it cannot copy via wildcards such as *.* In addition, it has to recognize a viable XP installation on the hard disk, and match that installation's (typically null) password before you can do anything. These limitations make Recovery Console useless for detecting malware, and tedious for managing malware identified via some other method. For data recovery, it ranges from totally useless to very tedious; at best, you can use it to copy individual files by name, one at a time.  Unlike ReadNTFS, it cannot copy off entire subtrees.

No comments:

Post a Comment