Maintaining Vista from orbit; what mOS?

[cquirke (MVP Windows shell/user)]

Vista is the first NT-based OS to ship with a maintenance OS...

http://en.wikipedia.org/wiki/Maintenance_OS

.... as accessed by booting the Vista DVD (which is when you don't want
to be a victim of large-OEM "Genuine Advantage") and going to the
Repair section, Command prompt.

In addition, WinPE 2.0 availability has been liberalized.

However, in practice, these seem to limit what programs can do, in
terms of "admin rights". Generally, an app that needs "run as admin"
in Vista, won't work in Vista's mOS modes.

That rules out hard drive diagnostics like HD Tune, data recovery
tools that must access the disk below the file system, and most
antivirus scanners. In Vista64, it's worse; without the ability to
host Win32 programs, Vista64's mOS is very limited indeed.


Have folks worked with these contexts, and found solutions?


Coming from years of maintaining XP systems using Bart PE, a Bart
feature that I really appreciate is Paraglider's RunScanner plug-in.

What this does, is bind into whatever is shelled by it, and rfedirect
all registry access from that program to the inactive registry hives
within the HD installation, as if that installation was booted into
effect. This permits registry-aware tools such as MSConfig,
HiJackThis, Nirsoft's integration checkers, Regedit, and a variety of
registry-aware antimalware scanners to operate on the HD installation
without being at risk from malware that may be embedded in that.

This contrasts with the traditional approach of manually binding hives
to HKLM in "normal" Regedit, which results in these hives changing
thier paths. A scanner expecting to find and process HKLM\..\Run is
not going to switch to HKLM\ArbitraryNameOfHive\..\Run instead.


Does anyone know if this functionality is available for Vista?


As Bart stands, it won't access Vista's registry via RunScanner. It's
possible that a "Bart PE 4.xx" will follow to encompass this, or maybe
Paraglider or someone else will do a RunScanner for WinPE 2.0 that
will work with Vista's registry. Or maybe MS will cook something up?

Given how different Vista and XP are, and given that MS WinPE 2.0 is
at last available to mere mortals, perhaps building a "Bart 4" from
the ground up is not the best way to go. Better may be a plugin
framework (as exists on Bart) for WinPE 2.0?


There are a third set of design limitations that makes the mOS
component of the Vista DVD less useful, i.e.:
- a large amount of GUI and code has to be traversed to get there
- it won't let you get there unless it "sees" a Vista installation

Neither of those are good news in the context of suspect hardware,
failing hard drive, corrupted and at-risk file systems, etc. as they
increase the risk of things going wrong and collateral damage.

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[Jimmy Brush]

However, in practice, these seem to limit what programs can do, in
terms of "admin rights". Generally, an app that needs "run as admin"
in Vista, won't work in Vista's mOS modes.

</snip>

While using the Windows Repair Environment you are logged in as SYSTEM,
so this isn't really true - you (and any programs that you run) are
given the full privileges that the system is assigned.

There does seem to be some programs that won't run in WinRE (like
explorer) and there are restrictions, but they don't seem to be related
to privilege issues.

 

[cquirke (MVP Windows shell/user)]

While using the Windows Repair Environment you are logged in as SYSTEM,
so this isn't really true - you (and any programs that you run) are
given the full privileges that the system is assigned.

There does seem to be some programs that won't run in WinRE (like
explorer) and there are restrictions, but they don't seem to be related
to privilege issues.

Thanks, I was wondering about that. The main "test" app I've been
using so far has been HD Tune from www.hdtune.com

What is the relationship between...
- WinPE 2.0
- WinRE
- Vista DVD in mOS mode
....?

As I understand it, they're all WinPE 2.0 derivatives, with WinRE
being a WinPE 2.0 with additional tools (from the DVD's maintenance
section) being built into it. But I'm unclear as to whether the OS
DVD is a full-blown WinPE 2.0, or something "lite".

Also, I'm unclear as to how one integrates apps into WinPE, compared
to how one does this in Bart PE.

In Bart PE, each "plugin" wraps an app, and typically contains:
- an .HTM(L) file that documents the process for the user
- an .INF that integrates the app's code and settings at build time
- an .XML that integrates the app into the nu2menu UI
- a .CMD file that shells the app at runtime (not always needed)

One of the nice things about WinPE 2.0 is that the whole OS runs in
RAM, so you can eject and change the CD or DVD. It also detects USB
sticks on the fly, whereas Bart detects only at boot and then
"remembers" them, so you can't hot-swap.

This suggests a strategy of building Bart mOS CDRWs for use in XP and
older (it boots in as little as 64M RAM) and then integrating some
sort of cross-link from WinPE 2.0 to the Bart front-end.

The problems are:
- Bart's nu2menu doesn't work properly from WinPE 2.0
- deep integration applied via Bart plugins won't be there for WinPE
- WinPE file set appears to lack several dependencies Bart provides

The last observation is from apps that do not add "deep" files or
settings via their plugins (i.e. files added to System32, registry
entries), and yet lack certain resources when launched from WinPE.

As it stands, I can use Bart on Vista systems, as long as I don't need
to do anything that requires registry access. But in case of new NTFS
features etc. I'd like to migrate to WinPE 2.0 as mOS, or at least the
mOS from which I can launch tools on the Bart disk.

--------------- ----- ---- --- -- - - -

Error Messages Are Your Friends

 

[Jimmy Brush]

What is the relationship between...

- WinPE 2.0
- WinRE
- Vista DVD in mOS mode
...?

As I understand it, they're all WinPE 2.0 derivatives, with WinRE
being a WinPE 2.0 with additional tools (from the DVD's maintenance
section) being built into it. But I'm unclear as to whether the OS
DVD is a full-blown WinPE 2.0, or something "lite".

From what I understand, Windows PE is simply Windows Vista running in
"mini NT" mode. I believe any windows installation can be launched in
this mode, its just a matter of passing a flag to the bootloader, but I
may be wrong on that.

In this regard, it is kind of like safe mode, where Windows changes its
core behavior based on a startup flag.

WinRE (Windows Recovery Environment) is an actual Windows installation
in the form of a WIM file that gets booted by the DVD (or the hard drive
if you install it) in mini NT mode.

Also, I'm unclear as to how one integrates apps into WinPE, compared
to how one does this in Bart PE.

You do this by editing the WIM file for your windows installation that
you are going to use as a recovery environment using the Microsoft
Automated Installation Toolkit.

You can grab the standard WinRE WIM off of the install DVD and customize
it using the AIK.

These sites have some good info:

http://technet.microsoft.com/en-us/windowsvista/aa905120.aspx
http://blogs.msdn.com/winre/archive/2006/12/12/creating-winre-using-waik.aspx
http://blogs.msdn.com/winre/

The last observation is from apps that do not add "deep" files or
settings via their plugins (i.e. files added to System32, registry
entries), and yet lack certain resources when launched from WinPE.

As it stands, I can use Bart on Vista systems, as long as I don't need
to do anything that requires registry access. But in case of new NTFS
features etc. I'd like to migrate to WinPE 2.0 as mOS, or at least the
mOS from which I can launch tools on the Bart disk.

I'm not familiar with BartPE, but I imagine the technical challenges are
the same.

Sine the Windows Repair Environment is an in-memory installation of
windows, when you run a program from that environment, it is actually
running on that in-memory installation, and not the target installation
of Windows you are trying to fix.

The recovery tool you are running from inside winre will have to be
general purpose in nature (for example, disk tools), or specially made
to modify the target installation of Windows, as in the case of a
program that needs to modify the registry. It will have to be smart
enough to load the correct target registry and modify it, because if it
just modifies the normal registry (HKEY_LOCAL_MACHINE, for example), it
will be modifying the registry for the in-memory windows installation,
and not the target.

 

[cquirke (MVP Windows shell/user)]

From what I understand, Windows PE is simply Windows Vista running in
"mini NT" mode. I believe any windows installation can be launched in
this mode, its just a matter of passing a flag to the bootloader, but I
may be wrong on that.

I haven't seen much documentation on integrating tools into WinPE.

I'm using WAIK (as part of BDD 2007) and like it; I made some notes as
I went along here...

http://cquirke.spaces.live.com/

....and most of that is bogged down with initial difficulties getting
WAIK (as I think it was pulled to be fixed for a while).

I've mounted .WIM as file system, and added files to it that way, but
I haven't integrated registry changes etc. and haven't done much with
the rather peculiar WIM manager. What's strange there is the
arbitrary weighting of what settings are exposed to be changed, which
still seems very OEM orientated.

It's like selling cars with the option of specifying leather, corduroy
or canvas seats but hard-wiring these to lime green, clashing with a
hardwired purple body shell. What you want to set, isn't exposed.

WinRE (Windows Recovery Environment) is an actual Windows installation
in the form of a WIM file that gets booted by the DVD (or the hard drive
if you install it) in mini NT mode.

These folks have a blog that details how to do this, i.e. build a
WinRE boot disk from materials used to build WinPE disks. I haven't
actually followed the process though, just read through it.

You do this by editing the WIM file for your windows installation that
you are going to use as a recovery environment using the Microsoft
Automated Installation Toolkit.

I have yet to build those skills ;-)

You can grab the standard WinRE WIM off of the install DVD and customize
it using the AIK.

That's interesting...

These sites have some good info:

http://technet.microsoft.com/en-us/windowsvista/aa905120.aspx

http://blogs.msdn.com/winre/

The middle one's new; I don't remember that - thanks! Good links...

I'm not familiar with BartPE, but I imagine the technical challenges are
the same.

Yep, tho solved differently...
- Bart boots and runs off disk, WinPE throws into and runs from RAM
- so Bart can run in less RAM than WinPE (64M vs. 512M)
- but if you eject the dfisk in Bart, you die
- so WinPE lets you swap optical disks, and ?writre to them
- Bart determines USB storage at boot time, WinPE "sees" on the fly
- both can do networking, but:
- Bart is built from a baseline SP code set, so hard to patch
- WinPE has firewall, Bart does not
- Bart has a UI menu, can support alternate GUI shells; WinPE is CLI
- Bart has a wealth of community plug-ins, WinPE lacks this support

Sine the Windows Repair Environment is an in-memory installation of
windows, when you run a program from that environment, it is actually
running on that in-memory installation, and not the target installation
of Windows you are trying to fix.

That's the crux, benefit, and curse of off-HD mOS:
- live behaviour watchers (e.g. rootkit scanners) aren't relevant
- static file watchers (e.g. file-scanning av tools) work well

The recovery tool you are running from inside winre will have to be
general purpose in nature (for example, disk tools), or specially made
to modify the target installation of Windows, as in the case of a
program that needs to modify the registry. It will have to be smart
enough to load the correct target registry and modify it, because if it
just modifies the normal registry (HKEY_LOCAL_MACHINE, for example), it
will be modifying the registry for the in-memory windows installation,
and not the target.

Registry access is a challenge met in two ways:

1) Binding remote hives

This generic ability is built into NT, at least since XP, and any mOS
derived from these OSs that includes Regedit.

It allows you to run Regedit, bind inactive hives from the HD, and
interact with these. However, the registry's logical key paths will
not be the same, so automated interaction (e.g. exporting and
importing .REG files) has to take this into account.

2) RunScanner

RunScanner is a plugin for Bart, that AFAIK has no equivalent in
WinPE. You'd use it as you'd have used a LoadHigh directive in DOS,
or more properly, how you might use Command /C, Command /K or Start
commands to run a target within some sort of wrapper.

As a wrapper, RunScanner intercepts the wrapped program's registry
access and redirects it transparently to the inactive hard drive hives
as you or RunScanner's logic have designated.

This allows tools that use registry (e.g. scanners that will detect
and fix registry settings along with loose malware files they may
discover) to operate from Bart as if the infected code base was booted
and active, even though this is not the case. That's a HUGE win!

Unfortunately, it looks as if on this score in particular, the WinPE
folks haven't begun to ask the questions Bart has already answered.

Caveat: Driver and Service information appears to derived from runtime
state, rather than registry settings. That means any system
integration tools that report these things, will prolly "see" the Bart
booted session and not the HD installtion, even if that tool has been
shelled by the RunScanner plugin.

------------ ----- ---- --- -- - - - -

The most accurate diagnostic instrument
in medicine is the Retrospectoscope