On Wed, 27 Jun 2007 00:08:00 -0400, Jimmy Brush <jb@mvps.org> wrote:
>> 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.
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.
>> 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.
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/w.../aa905120.aspx
>http://blogs.msdn.com/winre/archive/...sing-waik.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
>------------ ----- ---- --- -- - - - -
Linear Mode
