Repairing Safe Mode (Safeboot)

Here's an example of what happens when you break the "Safe must be boilerplate" rule.

Many folks rely on Safe Mode to tackle active malware, on the basis that malware is less likely to be running if much of the startup axis is avoided when Windows starts up. But Safe Mode is defined in the registry, so anything that gets to run in XP can kill it off - a risk that's always been there, and one that I've highlighted in private forums often enough.

Now that malware is doing what I'd predicted, there's a need to repair the damage when encoutering it in the field. This blogger's article...

http://didierstevens.wordpress.com/2006/06/26/restoring-safeboot/

...describes three ways to do this, but these methods involve running Windows to do so. You may not want to do that, if the plan was to first do malware scans and cleanup in Safe Mode Command Only before allowing ?infected Windows to run.

If you are using Bart PE CDR boot as your initial-contact malware cleanup platform, then you can repair Safe Mode, the XP firewall, and any other registry settings damage in the following generic way; by harvesting settings from previous registry states and merging these into the current registry, before you try to boot the damaged hard drive XP installation.

Understanding Bart registry access

Bart PE is a free utility that builds a bootable subset of XP, from which one can launch many tools written for Windows. A problem with running such tools from a Bart PE CDR boot is that the registry they see will be that of the Bart boot, and not the hard drive installation you are trying to maintain.

Bart integrates tools as "plugins", using .INF-based wrappers that serve to "install" the tool at the time the bootable CDR is compiled. One such plugin is RunScanner, which facilitates transparent access to the inactive registry hives on the hard drive as if they were in effect.

RunScanner patches into the process it's running and redirects all registry calls to treat the designated hives on the hard drive as if they were the active registry. Command line parameters for RunScanner control whether there is to be a delay before this kicks in (so that the program can initialize through the Bart registry first), which hives are to be used, and so on.

Child processes are generally not affected, and that can complicate the use of tools that spawn processes which access the registry, e.g. Nirsoft's RegScanner.

Once you combine RunScanner with Regedit (as a standard Bart build may do automatically), you are in a position to fix registry problems as if you were running the stricken installation - without the risk of actually running that installation!

Binding arbitrary registry hives via Regedit

XP's Regedit allows you to bind arbitrary hive files to HKEY_LOCAL_MACHINE as if they were part of the registry. The hives won't generally be used by the system, but it makes it a lot easier to browse them and export things you'd be interested in.

In Regedit, you'd highlight HKEY_LOCAL_MACHINE and then go File menu, Load Hive - an option that is greyed out as unavailable if anything other than HKLM is selected - and then browse for a hive to bind. You will be prompted for a name to use, and the hive will appear as an extra subtree under HKLM using that name.

You can then browse the added material and export parts as .REG files in the usual way (tips; select "Win9x/NT4 Registration Files" in the type drop-down if you want to save as 8-bit ANSI for easier editing outside XP, and force a .TXT extension to reduce the risk of inadvertent import).

To prepare this material for import into the active registry, you'd have to search-and-replace the name you used when binding the hive to the correct name for the active form. It helps if you use a unique name when binding the hive, to reduce the risk of replacing the wrong stuff!

Finding backup copies of registry hives

The XP registry hive files fall into two types; system and per-user. You won't see them unless your shell is set to show all files and contents of system locations; also, you should not hide file name extensions otherwise you can't tell which are hives and which are .LOGs, etc.

The active system hive files are located in your System32\Config and have file names that have no extension at all, and the names are SYSTEM, SECURITY, SAM, SOFTWARE and DEFAULT.

The active per-user hive files are stored in the base of each user account subtree in "C:\Documents and Settings", plus there is the system user hive in your System32\Config\systemprofile directory. The file name is NTUSER.DAT

Like Win9x, backups of the initial system registry created when the OS is installed is kept as a last-resort fallback. These are held in the Repair directory within your Windows base directory with the same names as the active forms, though for some reason they may appear to have a .BAK extension when seen via Regedit's "load hive" dialog. Similar baseline backup hives are kept in System32\Config as .SAV files, but these may contain less content.

Unlike Win9x, XP does not automatically maintain a set of fresh registry backups. The "last known good" backup merely consists of part of one hive, stored within the same hive file; anything that corrupts the file will thus likely kill the internal backup.

I recommend setting up ERUNT as an overnight weekday Task to create such backups, keeping one for each day of the week by using the relevant ERUNT command line parameters in each Task. If you have ERUNT running in this way, you will have those backups to use, in addition to the ones I'll describe in a little while.

If running, the System Restore process creates fresh registry backups as part of each restore point. This is one reason why it's best not to purge System Restore, even though infected restore points will re-infect a clean system if they are restored. The file names are modified but obvious, and can be found in "C:\System Volume Information\_restore{**}\RP???\snapshot", where ** is an identifier unique to the particular XP installation, and ??? is the number of the restore point. It is by using an installation identifier that XP's SR avoids one installation's SR data overwriting another, as happens with Windows ME's \_RESTORE subtrees.

Note that the System Restore data is the only place where you will find backup copies of the per-user registry hives - an even more astonishing XP fagility than the lack of an independent automatic file-level hive backup facility!

Fixing the Safeboot registry subtree

Safe Mode is defined in HKLM\SYSTEM\CurrentControlSet\Control\Safeboot, where "CurrentControlSet" is a pointer to one of the ControlSet001, ControlSet002 etc. subtrees. When seen via Bart boot, RunScanner and Regedit, no control set is active, so you won't see any CurrentControlSet. In any case, you should operate on each explicit control set rather than just the current one!

The best previous registry hive from which to harvest Safeboot will usually be the SYSTEM (may be seen as System.bak via Regedit) in the Repair directory. Backups of SYSTEM in the RP???\snapshot directories may be more up to date, but if these date from after malware went active, they may be equally damaged or as malicious as what you are trying to fix.

Bind the hive file into Regedit as described previously; I'd use a nice unique name such as "!!ABCXYZ!!" when prompted. Then browse into the ControlSet, highlight Safeboot and go File menu, Export. I'd save as a "Win9x/NT Registration File" with the file name in quotes and using the .TXT extension; then I'd edit the file in Notepad or similar and replace all \!!ABCXYZ!!\ with \SYSTEM\ and save that. By importing that file via Regedit, I'd merge in the Safeboot to the corresponding ControlSet - to do all ControlSets, I'd edit the file accordingly before importing it.

Disclaimer: This stuff involves direct editing of the registry via Regedit using redirection tools from a free 3rd-party maintenance platform. Be careful, keep backups of everything you change, and eyeball to ensure you are in fact seeing the correct registry!