Custom Win PE Boot Disk Building: Step Four – Pulling it all together. ~ Bios Password

Hang on. This may be a doozie.

It will (hopefully) wrap up this project.

Summary

The purpose of this ongoing project is to build a Win PE 2.0 based boot-disk, that has a great VistaPE GUI interface (instead of the standard CLI shell) and the PGP WDE drivers injected so we can “liveCD-boot” a PGP WDE system (assuming we have the user’s passphrase). Oh yes, and it has to handle the Dell GX 7xx series USB keyboard drivers.

If you are just joining us, please go back and review the following posts to get up to speed:

Note: I’m serious about this, if you haven’t read and stepped through the previous posts there is a good chance you will be lost. Also, this post assumes you are familiar with working with Microsoft’s ImageX WIM files; mounting them, committing changes to them, etc. If not then there is a good chance I will loose you here.

Mkay?

Onward!

When last we left our intrepid hero…

At the end of the last post, I was poking around in the VistaPE WAIK build WIM file and looking at how it worked.

I had started with the winpeshl.ini file that loads the VistaPE project’s shell replacement.

That was handled by the custom executable vpeldr.exe and it’s configuration file vistape.cfg.

Turns out that the VistaPE project developer, NightMan, has already provided us with all the documentation we need to understand just how that miracle functions:

VistaPE API – Internal functions of VistaPE – VistaPE project page

It’s a good read and I really encourage everyone to take the time to read and understand it. It really is an amazing piece of work from NightMan and he should be fairly recognized for it.

When I opened up my particular vistape.cfg file to review, I found it contained almost all the information I needed to trace out, extract, and then inject the “ripped” contents into my already PGP Injected Win PE 2.0 wim.

Sweet.

WIM Mounting

I’m sure if you are still reading this post, you have already configured your system to allow for the mounting of ImageX wim files. If not, please take a moment to read this earlier post:

Mount ImageX WIM’s via Windows Explorer – Grand Stream Dreams blog

Yes, you can use ImageX to mount your wim files via the CLI, but with all the work we have done and have yet to do, it seems much more efficient for me to work with them from a GUI interface.

For the longest time I preferred the method of adding this quick-mount feature to the Windows right-click shell context: Mounting WIM Images from Windows Explorer - Robert McLaws: Windows Vista Edition

However, I would occasionally get lost with my mount/unmount points and wims in progress and would trip myself up.

Then I graduated up to the ImageX GUI (GImageX) coded by Jonathan Bennett.

The latest version is v2.0.14 released in October 2008 and it is sharp. He actually now has a beta version that supports the upgraded version of ImageX found in the Windows 7 Beta WAIK.

So either way, be prepared. I’m using the GImageX to do my work here.

Bonus Tip: I’m also using the freeware dual-pane/tabbed window explorer alternative FreeCommander not just because I love it but the dual-pane window makes file-copy actions like what we are about to do so much easier than Windows Explorer. There are a lot of other great alternative file managers as well you might want to look into trying. Your call…

Organ Harvesting

I created an empty folder at the root of C: called “mounted_wim” to use as my mounting point for wim files. That was a carryover from my foray into using Robert McLaw’s mounting solution. I’ve kept with it.

I also created another empty folder at the root of C: called “extracted_items”. This is where I am going to temporarily place the files/folders I pull out of the VistaPE WAIK project that I need. You might want to go ahead and make a “system32” folder in there as well while you are at it.

Using whatever your preferred method of wim mounting is, go ahead and mount up the VistaPE wim you created in our Custom Win PE Boot Disk Building: Step Three – VistaPE 12 RC1 Walkthrough step.

If you followed those steps, you should find it in the following location:

C:\VistaPE_WinBuilder_v12RC1\Target\VistaPE-Core\vistape.wim

OK?

Browse to the location you mounted it and copy the following items into your “extracted_items” folder.

Depending on how you roll, you might want to make some notes on a scratch-pad of where stuff came from so you can put it back correctly.

From the VistaPE.wim file we want to copy:

“Program Files” <—the folder and all its sub-contents. Note I just copy this folder as is into the extracted_items folder.

Now browse deeper into the windows\system32 folder and locate and copy the following items into your “C:\extracted_items\system32” folder:

devcon.exe
hw.bat
HWPnp.exe
HWPnP.htm
HWPnPDLL.dll
vistape.cfg
vpeldr.exe
winpe.bmp
winpeshl.ini

Want to explore this particular WIM a moment since we are here? Fine. Just don’t take any more relics this time round.

All done?

Unmount your vistape.wim file from your system.

Stage 1: Transplant the Brains

Now go and this time mount up our previously PGP WDE driver injected Win PE 2.0 WIM file.

C:\winpe_x86\ISO\sources\boot.wim

This time, be sure to mount it “Read and Write” so we can actually make changes to it. (Note: you might want to make a copy of the working original first, just in case you make a mistake!)

Into the C:\mounted_wim\Program Files folder, let’s copy back the sub-folder contents from our C:\extracted_items\Program Files location.

Got em all tucked in? Great!

Now browse to your C:\extracted_items\system32 and copy all those items into the C:\mounted_wim\Windows\System32 folder.

You are doing great!

Tweak the HWPnP module

Now, in previously looking at the vistape.cfg file, I located that it called to a HWPnP.exe file that uses the hw.bat file to supplement it. Research on that file indicates it is a Plug-n-Play helper used in BartPE and VistaPE projects.

The VistaPE WAIK build shows the second line the hw.bat file acts off of is as follows:

HWPnP.exe +all -storage\volume -USB\ROOT_HUB +USB\ /log /p /u /d+ /a

Since I knew the Dell USB keyboard hub controller driver was giving me fits, I decided to err on the side of caution and disable this. This may not actually be needed. It’s up to you.

Open up the hw.bat file and add two colons in front of it to REM it out thusly

::HWPnP.exe +all -storage\volume -USB\ROOT_HUB +USB\ /log /p /u /d+ /a

Save the modified file back.

Dismount that wim and be sure to use the option to “commit changes” so our changes actually get written and applied to the winpe.wim file. This part might take a while to process as the changes are written and the wim file is updated.

Stage 2: Transplant the Lungs

Now, we know from our l33t Win PE 2.0 hacking skillz that any files/folders we add into the C:\winpe_x86\ISO folder will be included on the root of our final boot disk. Right?

So lets work on that next.

Browse back to

C:\VistaPE_WinBuilder_v12RC1\Target\VistaPE-Core

In there, copy the following items:

“Programs” <—the folder and all its sub-contents.
vistape.cfg

And paste them into the following folder.

C:\winpe_x86\ISO

I always be sure I have a copy of the ImageX.exe file copied in there as well. That’s up to you. It makes system imaging and capture so easy.

You can add in other things as well to that folder (once you figure out how much extra space you have) such as portable system utilities and other stuff. Just don’t add anything that modifies or overwrites the things we have already added in there. I prefer to make another subfolder called “utilities” and dump all my special stuff in there just to be safe.

Stage 3-option 1: Sewing it Up (for standard CD disk media)

Go to the Start menu and under All Programs find the Microsoft Windows AIK folder and launch Windows PE Tools Command Prompt, or open a command prompt and type

cd c:\program files\Windows AIK\Tools\PETools.

Then, type

oscdimg -n -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso

(all one line)

An ISO file will be created inside the c:\winpe_86 folder.

With the ISO image file created, you can now burn the image file to CD.

Stage 3-option 2: Sewing it Up (for standard DVD disk media)

I personally stick with the CD sized builds as almost every system we touch (old and new) comes with a CD-ROM drive. Newer systems have DVD-ROM drives, but if I go to service an older system the DVD disk isn’t going to help me.

If you try to burn a DVD sized ISO with the normal instructions above it will error out. You must use the undocumented "-m" argument in your string to force it to build the ISO over the normal CD-sized ISO size. Use the -m switch to override the creation of ISO images larger than 700 MB

In that case (because you got all crazy with adding lots of extra custom utilities and stuff into your C:\winpe_x86\ISO folder) type

oscdimg -n -h -m -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso

(again, all one line).

With the image file created, you can now burn it to a DVD disk. (assuming that the combined file-size isn't larger than the DVD's storage capacity.)

Testing

I ALWAYS pre-test my built boot ISO files in a Virtual PC 2007 session first before burning. That way if I did something wrong I will see it before making coasters.

If all goes well you should see the following (click for a slightly larger view and yes, I know the wallpaper may be a bit different on yours…read on for how to customize that). Note the PGP drivers are working (even though the virtual drive I am using isn’t actually PGP WDE encrypted…).

If it looks good and seems to work cleanly, burn your custom “Win PE 2.0 + PGP WDE driver injected + VistaPE WAIK build ripped + Dell Optiplex USB keyboard driver working” Frankenstein’ish ISO (located as C:\winpe_x86\winpe_x86.iso) to a disk and see what happens on your live systems!

Caveats

Ripping out the core elements of Vista PE WAIK build as I have documented works. But it might make NightMan and other hard-core VistaPE/WinBuilder pro’s groan. I’m also likely leaving some critical bits behind.

So there are some applications that would work fine in traditional VistaPE build that error out and will not run under this GSD project. Be aware of that.

Second, if you go back in and mount the “C:\winpe_x86\ISO\sources\boot.wim” file, make more changes (wallpaper below for example) and re-commit the changes, you will likely notice your boot.wim file size continues to grow. This is not just because you added stuff, even if you “delete” stuff from your mounted/committed wim, it may still grow. That’s because with this method of wim management the changes haven’t been optimized to the wim. You need to actually export your wim file in a different ImageX process to reclaim the space when you have modified it. See this post (and the Google) for more information on that. I normally don’t bother as my final ISO size is still under the limits for a CD burn.

Also, if you compare the vistape.wim used to boot a standard VistaPE WAIK project to the one we did using a (PGP modified) base Win PE 2.0 boot wim you will see close to the following:

C:\VistaPE_WinBuilder_v12RC1\Target\VistaPE-Core\vistape.wim Size = 102.86 MB
C:\winpe_x86\ISO\sources\boot.wim Size = 187.11 MB

NightMan and all have worked hard on the original VistaPE WinBuilder project to remove many files/folders and other items from the standard Win PE 2.0 WAIK wim file that are not necessary or needed to work in his project. That’s why the size is so much smaller.

But in doing so, something caused the Dell Optiplex 7xx “USB Keyboard Hub” and related HID drivers from loading.

This method works around that.

I haven’t tested it on other systems, just those that I and my team service and support. It might work just fine on other hardware system configurations with that same issue. It might not. I don’t know.

If you take the time to do all this and find it does help you load previously unavailable USB keyboard devices on your own particular system, please leave a note in the comments so others (and myself) will learn of your success.

As always, what works for me and our systems, may not for you. Your mileage may vary.

Also, I’ve got at least one more related post in this series planned to address coming developments I have found with future VistaPE/WinBuilder projects as well as Win PE 3.0 in general.

So stay tuned for that.

Optional Tweaks and Tips

As I mentioned before, if you want to kick things up a notch, add in some additional portable applications, and fire them up off via PStart you can add a modified version of this to your startnet.cmd file before you pack up your customized wim: (via RunOnceEx from CD by Alanoll)

wpeinit
cmd.exe
For %%i IN (D E F G H I J K) DO IF EXIST %%i:\cd-specific_filename SET CDROM=%%i:
%CDROM%\PSTART\PSTART.EXE

Also, if you want to add a sexy custom desktop wallpaper (please comply with any work-rules if you distribute such builds in your workplace and use something tamer) just find your image (I prefer to use 1024x786 sized), and convert it to a BMP format file and save with the name “winpe.bmp” and place back in your custom wim’s windows\system32 folder overwriting the original one we extracted from the VistaPE WAIK built wim.

I have also discovered that if you want to plug in a USB storage device to your Win PE booted system it doesn’t always pick up the new drive.

Open a cmd session and run the command “DiskPart” then do a “list disk”,

That is usually sufficient for the OS to scan for any drives and mount what it detects.

Refresh your windows explorer tool (in this build it would be Cubic Explorer) and you should see it now just fine.

Tomb Raiding using the PGP WDE drivers and pgpwde.exe

Remember, one of the other reasons I needed to go through all this pain and learning was to be able to boot one of our PGP WDE encrypted systems “off-line” with a VistaPE’ish Win PE boot disk and use the PGP injected drivers to access the “on-the-fly” decrypted contents of the drive rather than taking hours (or more) to do a full off-line drive decryption using the stock PGP WDE recovery boot-disk (and see this PGP link on how to use), before being able to access the contents with a traditional boot-cd.

Our hard work and dedication has now given us a much more flexible and powerful tool!

Boot the PGP WDE system with our custom boot disk.

Of course, you will need to know the user’s PGP WDE passphrase for on-the-fly file/system access and recovery to work….

Open up a CMD session.

The basic commands I use are as follows

pgpwde –enum
pgpwde --disk 0 –status
pgpwde --disk 0 --auth -p “xxxx” (NOTE: put passphrase in “ “ if separated with spaces.)
pgpwde -h

The first one “enumerates” the system disks and volumes.

The second one shows the status of any pending WDE encryption/decryption activities. This might tell you if WDE was initialized and is x% completed.

The third command is the money-shot. This is what our tomb-raiding has been working towards. It allows you (with the user’s PGP WDE passphase) to decrypt the drives “on-the-fly” from the Win PE 2.0 environment so you can recover the files from a non-bootable system if the OS has crashed (or for other reasons). The trick to this one is that if the user’s PGP WDE passphrase has spaces in it, you must enclose it all in quotations marks.

I haven’t tested to see if this will take a PGP WDE recovery token and if so, what impact that might have. In our cases (so far) the user is present and can provide us with their passphrase. If they have disappeared and their passphrase is not available, then you would need to try a PGP WDE recovery token instead. I’ll let you know if I try it and it works.

There are many, many more powerful PGP commands and arguments for the pgpwde.exe executable. Do the fourth command to list them all. Then search the Google for some powerful and undocumented ones as well.

Either on a live PGP booted system or a LiveCD PGP injected system, the pgpwde.exe command line tools are very good to know and be familiar with if you support such systems.

Final Warning: You must inject and use the PGP WDE drivers/tools specific to the version of PGP WDE deployed on your system(s). Failure to do so might seriously muck things up! Mkay?

Whew!

Thanks for sticking with me. I hope this helps someone (or two).

I also suppose if you had the VistaPE USB system keyboard sensing issue but didn’t need the PGP WDE drivers, you could just skip over that step and not do that. The rest should work fine.

Wicked Cool and Sexy, isn’t it?

Just like I promised….

Cheers!

--Claus V.

Bios Password

Saturday, February 7, 2009

Custom Win PE Boot Disk Building: Step Four – Pulling it all together.

0 comments:

Post a Comment

Popular Posts

Categories

Blog Archive

About Me