Sunday, March 29, 2009

IT Phone Home: PC Auditing to Go

This will be a slam-down post. As in, I’m slamming down in the pan, frying it up and tossing it on the plate.  Got a busy schedule this weekend, time is a luxury, and I’m a short-order cook.

At work we’ve had an anomaly crop up.  A number of our newest systems have been found to be strangely missing system RAM.   Down to 1 GB from 2 GB according to the factory specs and build information based on system number.

I’m no PI but a roundup of the particulars leads us to a single conclusion.  Unfortunately, because our installation process does not actually involve base-lining every system we install (I know, I know…) I can’t say with 100% certainty that the system put on the desk definitely had all the RAM ordered when it was placed on the desk.  So loss could have occurred anywhere from the factory, through the delivery chain, to the install, to post-install period.

So (being the bright folks we are) we got together and figured out that we needed to document what each and every system we install contained when we touched it and walked away from it. And it needed to be done by the installer.  That way we could be certain what every system had when we put in on the desk, and if something came up missing, what it was and that it happened after the installation.  It would be golden if we could also extract serial numbers of RAM DIMMS, chassis, hard-drives, and other elements without cracking the case open.

Now I can’t speak for all shops, but our install techs are very busy and time is of the essence.  Opening every case and inventorying all the key components could really slow down the process of deploying to staff.

We needed a fast way to make like a panda and eat, shoot and leaf.

The Solution

After a lot of research, we appear to have settled on the retired AIDA32 project software.  A bit more testing and validation is required but we are feeling pretty good with this first-round draft pick for the team.

There are two versions, AIDA32 - 3.93 and AIDA32 –3.94.2.  The biggest difference between them is that the second one supports a server mode that when configured will accept Audit auto-sends from systems when AIDA32 has been set up to run in “client-mode”.  The second one also seems to have slightly better hardware support.

We like this one because it is highly customizable to the degree of specific hardware and Operating System components that can be selected or excluded for reporting.  After much work I configured a custom report that will provide us with a system summary, user account information, motherboard identifiers, system chassis type, RAM DIMM size, counts, and serial numbers, hard drive SMART information, hard drive model and serial number, label of hard drive, workgroup information,  AV information, monitor type and serial number, and network IP configuration info.

That lets us know exactly how the installer configured the system, who it was configured for, where it was configured, and what all was specifically on the system when it was deployed.

Now, to make things even more fun, I’ve been able to package it all up in a single folder that each technician can carry and run from their USB stick.

Then I used it’s batch-file, command-line, custom reporting, and email actions support to allow them to click a single batch file.  That file runs a system audit based on my parameters, packs it up in a text-file, attaches it to an email message and sends it to three of us.  All in the space of about a minute.

So the tech can click it, allow it, and forget it.  We get our reports and audit documentation and the techs suffer through negligible time-loss.

One of the bonus finds was this AIDA32 User Guide (zip) which has great details on configuring the tool as well as all the command-line parameter support.

Bonus Trick

I wanted the batch-file process to be almost seamless, and I found this great tip on how to (kinda) run a batch-file to launch in a minimized/hidden CMD window.

It was a clever trick and some background on what exactly it does can be found in this chock-full-o-nuts post: Antimail : Script recipe of the week: how to copy an opened file.

Between this trick and some AIDA32 command-line fu, it looks to be a perfect match with system auditing information capture at time of installation and a 1-minute drill to the goalposts.

First Runners Up

Here are more free “system auditing” tools that I was familiar with and considered.

However they either provided too much information, or not enough control over the information in the report.  Plus they didn’t have a way to auto-transmit the data, so collection was a bit more involved and technician-dependent.

Belarc Advisor - Free Personal PC Audit – This was the first PC Audit software I ever used at home, years ago.  It still is great but isn’t free for business usage.

SIW | System Information for Windows by Gabriel Topala – Great information. Beautiful GUI. High degree of information provided.  Reporting is good and can be run in batch-modes. Wonderfully versatile but not free for business usage and I couldn’t quite get the granularity of reporting I wanted.

SIV - System Information Viewer – free and provides an insane amount of detailed hardware information. Simply insane in the membrane. A beautiful product that makes the hardware geeks cry.  However it was too much info for our needs.

System Spec- Portable System Information Utility – Really, really nice portable product to audit your system.  Beautiful reports and easy to use.  Completely free.  Probably would have been my choice but didn’t quite allow me the reporting item selection flexibility I was looking for.  It was so close to being perfect it hurt.  Highly recommended, particularly for mom-n-pop system builders and home users.

WinAudit v2.27 - Free Computer Audit Software – Fast fully free (commercial/personal usage) and portable tool that provides nice reports.  I can’t complain much about it.  It does a great job and has a variety of options for outputting reports and getting them to where they need to go.  Email is supported.  I had to pass because I couldn’t quite get the selection of report item includes/excludes nailed down perfectly for my purposes.  Really worth looking into for home users.

Windows System Information Utility by HeidiR -(Download.com) – I’m offering this link at it seems to contain more information on the product than the developer’s own website page.  Pick either one for your download.  I liked this one as well

Network inventory software - Free PC Audit – Free, small, and single exe file portable app.  Sure you can keep the help file and read-me if you want as well.  System scan is a bit slower than some of the other tools.  Reporting is pretty detailed.  You can export the report and

There are some other free and many, many commercial/enterprise system auditing applications out there, but if you are looking for a small, flexible, and portable tool to quickly scan and audit systems either at deployment or post deployment, there is a good chance at least one of these tools will fit your need perfectly.

Cheers.

--Claus

 

 

 

Saturday, March 28, 2009

Windows FE “Live CD” Posts Followup

To get up to speed, please make yourself familiar with these two previous GSD posts:

The first one highlights a Win PE version build that offers forensic folks an alternative to the many Linux forensics “LiveCD” builds.  It contains background information as well as a link for instructions on building.

The second post was an amateur’s attempt to investigate claims that the Win FE disk isn’t, in fact, forensically sound.  I couldn’t find any actual documentation or commentary on the Web that examined this claim at all, so I set about doing my own experiment.  My admittedly limited testing found that booting a particular non-Windows system installation with Win FE did not change the drive hash.

It also allowed me an opportunity (fun excuse) to explore and detail the specific storage-mounting controls as found in the registry which prevented writing to the examined storage volumes.

Feedback from the Forensic Pros

Since then I have received a number of comments from the real forensics pros that have provided additional clarification and explanation about what is going on, along with gentle suggestions for improved validation methods.

I appreciate them deeply as my intention is to understand and document accurately what is going on with the Windows FE build in particular and Windows PE systems in general.

In the interest of sharing this great information, and to accept their honorably offered criticisms (in the sense of the act or art of analyzing and evaluating…) of my Win FE posts, I felt it was my duty to highlight them specifically in this followup post starting with Troy Larson a senior forensics investigator in Microsoft’s IT Security group who left this first of two comments.

Thanks for the write up. I am the creator of Windows FE, and I very much appreciate your testing and write up.

I have tried to document instances where Windows FE might right to disk, as well as why. Basically, Windows FE will write a disk signature to any disk that does not already have a disk signature--that is, generally, non-Windows disks (disks that have not been attached to Windows systems). Windows disks have disk signatures, so that is why you don't see a write activity.

Troy also kindly left this more detailed comment:

… ForensicSoft is quite correct. In fact, I believe I have shared more than a few emails with a person at ForensicSoft. However, I don't consider the issue as fatal to the forensic soundness of Windows FE, but then I take the position that it's how tools are used and not the tool itself that makes for forensic soundness. Windows FE can be used in a forensically sound manner.

Windows FE will write a disk signature to a non-Windows disk. Windows FE writes a disk signature to any disk that doesn't have a disk signature. This is a well documented behavior of Windows, and, as such, is predictable. As predictable, the behavior can be expected and explained by the forensic investigator. Thus, one could use Windows FE on non-Windows disk, and have forensically sound findings--as long as the four bytes at the disk signature location are not at issue. I have seen nothing that indicates that Windows FE writes to any partitioned space--Windows or non-Windows.

I have a great deal of respect for the people at ForensicSoft. I appreciate that they have taken the time to advise the forensic community of a potential issue in Windows FE. Windows FE is a tool that came out of Microsoft's forensics team. It is not a product. As you note, it is a customization of Windows PE v.2.1.

So Troy provides an explanation from his considerable testing work for cases where the disk hash has been observed to change with use of the Windows PF disk.

This is in line with the information suggestion previously by forensics specialist DC1743 over at his Forensics from the sausage factory: Windows FE saves the day with a Dell Inspiron 530 post made a much more focused response:

Windows FE may write a disk signature to a partitioned disk, if the disk does not already have a signature. The disk signature starts at 0x01B8. The partitioned space—volumes—are not written to.

The read-only switch in Diskpart also writes a byte to the hard drive that makes that hard drive read-only to Windows.

For these reasons the whole device hashing approach may result in differing hash values - however this behavior does not necessarily make the use of Windows FE forensically unsound.

DC1743 also posted a follow-up comment on one of my Windows FE posts:

In respect to the non windows testing I was not sure exactly what was going on with the conv=noerror option. Are you saying that the drive you were testing had read errors?

I guess you may not have access to a hardware write blocker, but if you did, hashing the disk with the installed linux OS whilst connected to one may have given you a better base line. As things stand we are trying to validate one form of software write blocking by using another form of software write blocking in our testing. I appreciate that the methodology may still be sound but it gives the critics more to aim at.

TinyApps Blog author and kind friend Miles offered his knowledgeable perspective as well saying

I would recommend using a hardware write-blocker, especially in forensic cases. I use WiebeTech's Forensic ComboDock:

http://www.wiebetech.com/products/ForensicComboDock.php

I haven't trusted software-only solutions ever since being unpleasantly surprised by disk changes Winternals Administrator's Pak (a Windows-based bootable rescue CD) made to a system without warning.

Lessons Learned

Number One

It seems clear that Windows PE / FE disks will, under particular circumstances, assign (write) a disk signature to a storage device if none is found.  That is the case when non-Windows OS systems are installed on the storage device.

That said, I still have the feeling that more work needs to be done to define and/or provide examples of when those particular circumstances do occur.  For instance, after the above comments were made, I went back to my original test-bed system and after booting it with the Win FE disk, verified that no Windows disk signature was present or assigned despite repeated accessing of the disk from the Win FE disk.  It never showed up.  That would be in line with my hashing matches observed.

Now in this case, my actions were only related to accessing and “off-line” viewing of the disk/contents.  I could see where if Win FE was used to capture an image, then write the image to a sanitized device, Win FE might indeed need to apply a disk signature to the cloned storage device in order to mount it in read/write mode as it put the image on the disk.  Maybe that is where the hashing difference comes in that is being talked about?  Not on the original “suspect” disk being viewed, but when “put” on the duplicate disk.  Maybe not?  I’m still unclear and hope this can be better explained.

Here are some more great links about Windows disk signatures with XP and Vista systems for background information:

Number Two

It is clear to me that probably the only “professionally forensically sound manner” that exists in ensuring that a hard-disk drive (or other storage media) is not corrupted or changed when accessing it by an examiner is to use a physical write-block device attached to said device.

While software-based “write-protected” boot disks have their place, they still take a second-chair to the purpose-specific hardware-based write-blockers.

To respond to a few of the comments, no, I do not have access to a write-block device.  I’m hoping to include one in the supply and material budget for next year along with an updated SATA-drive supported disk-duplicator.  Our slot/bay-based ATA-drive duplicator is gathering dust as most all of our new systems are SATA hardware now.  Use of one in my tests would certainly have provided a greater measure of reliability with testing and results.

Number Three

DC1743’s comment also pointed out another “issue” with my methodology that I hadn’t even considered: did the hard-drive of my test system have sector errors?  I’m not sure, but based on my limited understanding of the different results I saw from the dd MD5 hashing of the drive with and without use of the “conv=noerror” option it appears that could be the case.

Curiously, and not noted in the test, was the fact that I tried local installation of Helix, RAPTOR, and DEFT forensic Linux builds on the test system’s hard drive. All three balked during the drive preparation process, despite my successful manual creation of the ext3 and swap partitions manually in their installers.  Only the CAINE Live CD allowed me to install itself locally with no issues or complaints.   Maybe it is more fault-tolerant somehow.  So something indeed may be going on with that particular hard-drive.  Windows has never complained about accepting an installation.  I’ve added a hard-disk deep sector scan test to my “to-do” list for the coming week, just out of curiosity….and because I hate loose ends!

This highlights the importance of pre-checking and thoroughly testing and certifying the storage media to be used to place a captured image on is free of errors and problems.  It probably is part of the normal forensics procedure to understand if the “evidence” drive also contains any physical surface errors.  Certainly both of these things could, in theory, lead to differences between image hashing which must be accounted for.

The forensic professionals know this already but for sysadmins and the curious this is probably one key part that isn’t nearly as “sexy” as image capture and content analysis itself.  It must however be kept in mind.

I also found that the NIST IT Lab Computer Forensics Tool Testing Program has issued a January 2009 draft paper on Forensic Media Preparation.  While no results are present, it does provide an introduction to one stage of this, drive sanitization, but doesn’t seem to comment regarding verification of drive health and sector errors in particular.  That particular PDF contains some additional links to other papers on media preparation and sanitization that might be worth looking into.

Maybe it isn’t as practical an issue as it seems, but to my unlearned perspective I’m thinking it is something that is addressed at some point in forensic media preparation and usage.

Closing Comments

I still really like the idea of what Windows FE disk builds bring to the table.

Aside from their use to forensic investigators, they could also be deployed by system administrators in mission-critical responses where undisturbed capture of information/data off a target disk must be done delicately and in place without risk of over-writing said information, servers for example.  I can think of a number of cases where this application would be perfect for a Win FE disk and where removal of the target drive or use of a physical write-blocker would be impractical. And “forensic soundness” would be a non-issue.

I’ve learned very early on in IT, that one can never have enough tools, utilities, or options when serving and supporting systems.  Familiarity with the tools and how they work brings more options in responding to particular events and scenarios.

That gets back, full-circle, to the idea that everyone, sysadmins and forensic examiners alike, need to fully understand and validate just what the tools they depend on are doing.  Only in this manner can they successfully defend positions on observations made and actions performed with those same tools.

Most of my Win PE building disks will still be set to allow read/write access to attached storage devices, but now I am well versed in the options that my (now also always present) Win FE disk offers me, and how to make Win FE disks in particular.

Special words of thanks to the friends and professionals who have taken the time to elaborate and expand on my questions and Win FE posts.  You have my gratitude and respect.

--Claus V.

Blocking IE 8 "InPrivate" Mode – Updated

It’s been a while since my post Blocking IE 8 "InPrivate" Mode.

In that post I looked at how IE’8 “InPrivate” web-browsing mode could be blocked or disabled.

It could either via Active Directory policy, or via a registry key.

The registry key technique should work fine for both home and business users interested in it.

I had tested it with a beta version of IE8 in XP, and surmised it should work on Vista, but never got around to validating.

Then a got the following comment the other week on that post:

Hi Claus, we use Vista Home Premium 32 bit and I cannot locate group policy. If I want to disable Inprivate browsing, can I do that by editing thw Windows Registry alone?

Yes.  This registry key “fix” does successfully work on Windows Vista as well as Windows 7 just fine to prevent access (block) InPrivate mode in Internet Explorer 8.

InPrivate-enabled

"InPrivate" Enabled

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Privacy]
"EnableInPrivateBrowsing"=dword:00000001

InPrivate-disabled

"InPrivate" Disabled

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Privacy]
"EnableInPrivateBrowsing"=dword:00000000

In case it isn't clear, I exported the "Computer Configuration" registry key as shown above to indicate the specific key and value needed.

Note that on most home systems the Registry key I mentioned might not exist. So here is the quick and (fairly) safe way to do it.

Right-click on your desktop and select "New"..."Text Document".

You should see one appear on your desktop.

Rename it to something like "IE8SafeMode.reg"  (Note I changed the file extension from .txt to .reg)

Save the change and tell Windows you know you changed the file extension name. OK.

Right-click on the file you just made and select "Edit".

It should open in notepad.

Copy the following text (all three lines) and paste it into that Notepad file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Privacy]
"EnableInPrivateBrowsing"=dword:00000000

Save the file and then close it.

When you double-click the file it will ask you if you want to add those changes into the Registry. Select Yes.

Then reopen IE8 and you should now have InPrivate mode disabled.

To enable it again, just re-modify your file so the last number on the last line is a "1" and not a "0".

Save the file and run it and say "Yes" to add the info to the registry again.

If this doesn't work, then it is likely your account doesn't have sufficient administrator level permissions to make those changes...

As always, making changes in the Windows Registry carries risks, up to and including nuking your system. However these steps do works on my system fine. Proceed at your own discretion.

Note that InPrivate browsing is disabled by default on systems where Windows One-Care or Windows Family One-Care has been installed.  Or if application of “Parental Controls” settings have been applied to the account.  In those cases, use of the registry keys to “enable” blocked InPrivate mode will be ignored and InPrivate mode can not be enabled.  Conversely, parents wanted to harden the blocking of this mode in IE8 may want to look into those products.

--Claus V.

Sunday, March 22, 2009

A “Suddenly it’s Sunday” Linkfest

Been a chill weekend.

Lavie has been lovingly concerned that I’ve been burning the candle at both ends at work this past week.  She’s pretty correct on that front.

So this weekend I was told in no uncertain terms that I had better relax.  So, uncharacteristically, Saturday found me in my jammies all day long, and mostly in bed; cranking out the past two blog posts and Jonesing on Turner Classic Movies.

Sweet.

Today I paid the price a bit having more catch-up work on the regular household chores, but even Alvis said she hadn’t seen me acting so embarrassing for a long time. (That’s a good thing for me, a bad thing for her.)

So as the girls close out the night (and Spring break) with a round of Jeff Dunham on Comedy Central (they haven’t stopped laughing yet)…I’ve got one more post of assorted links culled from the past two weeks.

Enjoy:

  • Springboard Series Virtual Roundtable: Windows 7 - To the Beta and Beyond – Microsoft hosts a Q&A session with a number of their pros, including Mark Russinovich.  If you don’t have time to spare, read this abbreviated transcript that covers all the major points of the Windows 7 discourse.

  • Engineering Windows 7 : Designing Aero Snap – I found this Microsoft post fascinating as it showed the degree of research and design in conceptualizing and working to delivery of this feature.  Neat stuff and really hard to ‘get right’.

  • Network Monitor 3.3 Beta Available – New version (beta) has been released of Microsoft’s network capture and monitoring tool. Jump the link to get the details on the improvements. While it isn’t near the top of my network capture tool list, I still keep it installed in case I need a “second opinion” on captures.

  • NetworkMiner follow up « SANS Computer Forensics, Investigation, and Response – I do like NetworkMiner for capture analysis and this post highlights an odd (but logical) issue; that sometimes network captures could be filtered by your A/V product and provide an incomplete picture of what is going on.  It’s good to know your tools and what to expect them to provide. This way you can spot when something deviates and needs to be examined more closely.

  • 4sysops - Windows 7 multiple active firewall profiles – Michael drops a great find: Windows 7 firewall brings more granularity to rules.  Specifically he has found that you can assign a different firewall rule to each NIC device on a system.

  • A sneak peek at the Windows 7 Release Candidate | Ed Bott’s Windows Expertise – More Windows 7 feature and screen-shot p0rn.

  • Windows 7 to officially support logon UI background customization - Within Windows – Finally, (almost) native support for changing the Logon background graphics.  Yes you can already do this with Vista and XP but you have to go on the down-low to pull it off.  Windows 7 looks to be much easier to do this.  Prepare for corporate logos on Windows 7 business deployments!

  • Sysinternals Site Discussion : Updates: Process Monitor v2.04, TCPView v2.54, VMMap v1.02, Testlimit v5.01, and Notmyfault – Updates, get ur updates! My picks below:

      Process Monitor v2.04: This update shows file mapping operations in basic mode, adds more translations of error numbers to text, fixes a bug that limited support for more boot log files larger than 4GB, and displays version numbers using the same formatting as Windows.

      TCPView v2.54: Fixes bugs that prevented the display of IPv6 TCP endpoints and the correct display of IPv6 UDP endpoints

      VMMap v1.02: Now shows all image subsections, even if they reside within the same allocation region. It also fixes a bug in image name sorting and makes the UAC elevation smoother on 64-bit Windows.

  • I don’t know what I would do without Nir Sofer and his wonderfully targeted utilities.  He has been hard at work updating oldies-n-goodies, as well has delivered a new tool that has now created a load of reorganizing work on my business system.

  • NirBlog: Utilities updates for this week

    • RegDllView, InstalledCodec, IECacheView: Added 'Explorer Copy' option - Allows you to copy the selected files and then paste them into a folder in Explorer.
    • FileTypesMan: Added support for creating and deleting file extensions.
    • WirelessKeyView: New and safer method to extract the wireless keys of the local machine. Starting from this version, WirelessKeyView uses a new method that extract the wireless keys without any code injection. and Fixed bug - In Vista, if WPA-PSK key contained 32 characters, the key was not displayed in Ascii form.

  • NirBlog: Latest utilities updates in NirSoft

    • AlternateStreamView and ResourcesExtract: Added support for choosing SubFolders depth in scanning.
    • SearchMyFiles:
      • Fixed bug: Base folder combo-box limited the number of characters that you could type.
      • Added option to save/load all search option to .cfg file.
      • Added 'Explorer Copy' option - Allows you to copy the selected files and then paste them inside a folder of Windows Explorer.
      • Added 'Open With' option.
      • Added option to choose the subfolders depth to scan.

  • NirBlog: Extracting multiple attachments from Outlook with OutlookAttachView

    • OutlookAttachView utility can help you do that. It displays the list of attached files in your Outlook's mailbox, and allows you to easily select all attachments that you need, and then extract them into a folder that you choose.  A fast update brought with it a bug fix “that caused OutlookAttachView to fail on scanning sub-folders under main Outlook folders.
      Also added 'Folder Path' column that displays the full path of the folder (For example: Personal Folders\Inbox\Bug Reports).

When I ran the last tool, Outlook Attach View against my Outlook PST file, it found over 6,000 attachments embedded in there.  Despite my efforts over the past two years to strip out all attachments and file them in “real” system folders, there obviously were lots that pre-dated that period.  It works fantastically. Nir has outdone himself with this one!  In addition, Nir has fixed some key bugs in his Outlook .NK2 viewer to now properly handle some unusual field populations.

  • Mark Minasi’s Newsletter #76:  Solving Windows "driver is not signed" problems – Mark outlines how to “sign your own drivers” for Windows 64-bit OS systems.

  • FizzBin - The Technical Support Secret Handshake - Scott Hanselman’s Computer Zen – Scott ponders a “secret codeword” that lets on-line tech support staff know you are a member of the professional IT geek society and can dispense with the “noobie” level of conversation.  The comments are almost better than the post.  Just last week we had a tanked wireless card.  We had troubleshooted it on the user’s system, on a “clean” test-bed system, and then finally repeated on both systems (successfully) with a “known-good-device” that worked perfectly on both systems.  The trouble followed the card.  When we finally got to the company’s tech-support, they wanted to follow the flowchart all over again from square one.  We wasted almost an hour patiently re-working our days of efforts.  Eventually he decided the card must be bad and then authorized a RMA.  Sheesh.

  • On my XP systems I swear by the file-copy performance Supercopier brings.  It lets me jockey files all over the place with speed much higher than Windows offers natively.  However it doesn’t seem to work on my Vista systems.  So I have been playing with TeraCopy and FastCopy. While neither one seems to offer the integration I get from Supercopier in XP systems, they both seem moderately better than Vista’s file-movement native speeds.  Anybody have any other recommendations for a replacement high-speed file copy/move tool on Vista?

  • 300447 Computer Forensics Workshop - Media Preparation And Copying ... (PDF) – Great lecture presentation from a Down Under Aussie Derek Bem on computer forensics.  I found this while digging up tips on using dd for an earlier post.  It’s great stuff and provides a very good overview of tools and techniques specifically in dealing with media.  Download and file this gem away after reading it carefully. Plan to spend some time poking around the Computer Forensics page for the University of Western Sydney that hosts this material. Of particular note are the Interesting Links page and the Online Materials.  Both are chock full of wonderful material.  I so wish my university had offered a degree plan like the one offered there.  Oh how things could have been different…   See also: Lecture 01-Computer-Forensics 30047 notes.  Additional lecture notes can be found here.

  • Forensic Investigation, Analysis, Documentation, and Law – (PDF) - Great SANS paper that covers more ground in the forensics field.  Again, probably nothing that forensics specialists don’t already know for good stuff for sysadmins who need to interface with them. 

  • Microsoft PowerPoint - DD in Windows Forensic - (PowerPoint) – Another good source of material I found while working on my “dd” usage.  Download this one and tuck it away! I also found more useful material on this firewall forensics.pdf page.

This should keep you busy for a bit!

Cheers!

Claus V.

Saturday, March 21, 2009

Windows FE: Forensically Sound?

Do mine ears hear a challenge?

Windows FE has been gaining a bit of attention lately across the forensic blog-o-sphere.

My interest primarily in Windows PE, as well a secondary interest in Windows forensics (as applied to sysadmin tasks) got me digging for more details on the rare object.

Eventually I pulled out enough information to make the following GSD post:

Turns out it has become popular in its own right and has been cross-linked at a number of other blogs.

As I have been reading these other posts with enjoyment, I’ve noticed the following comment made on many of them, including on my own post.

Windows FE is not a "forensically sound" Windows boot disk. You can prove this by booting any non-Windows system with Windows FE and take a hash of the drive(s) before and after booting with Windows FE.

At the time I didn’t have the opportunity to test this statement out, or research what was going on that made Windows FE builds not able to write to the booted system’s physical storage devices.

My response to the comment was open and respectful:

@ ForensicSoft - No, I was not aware of the claim that Windows FE still modifies the system even when "read-blocked" with the required registry tweaks.

Is this only for "non-Windows" system off-line booting or does it apply also to Windows system off-line booting?

I haven't had the time to build my own Win FE boot disk, but it's on my considerable "to-do" list.

I'll have to take your advice and run a hash test as you suggest.

Thank you for sharing.

Forensics specialist DC1743 over at his Forensics from the sausage factory: Windows FE saves the day with a Dell Inspiron 530 post made a much more focused response:

It is easy to take issue with sweeping statements.

Windows FE may write a disk signature to a partitioned disk, if the disk does not already have a signature. The disk signature starts at 0x01B8. The partitioned space—volumes—are not written to.

The read-only switch in Diskpart also writes a byte to the hard drive that makes that hard drive read-only to Windows.

For these reasons the whole device hashing approach may result in differing hash values - however this behavior does not necessarily make the use of Windows FE forensically unsound.

Finally, John Sawyer posted a followup article an earlier Windows FE post also expressing some openness to the idea that maybe Windows FE might not be as forensically sound as claimed:

Tool Validation: Trust, But Verify - Evil Bytes Blog - Dark Reading

I received a lot of great feedback after my Friday post about WinFE, the bootable Windows Forensic Environment. The biggest question was whether it really is treating the drive as read-only. In my closing, I said I'd do more testing than just building the CD and making sure it booted up in my virtual machine environment. As security professionals and forensic investigators, don't you all validate your tools before using them?

By this time I was sufficiently in enough doubt that Windows FE (when properly built) didn’t change the physical drive it was used on I actually posted a comment about that doubt on a fresh Windows FE blog post by Liquidmatrix Security Digest: Shattered Dreams… and a welcome community.

As soon as I hit “Comment” I knew I had to stop and validate, or risk the error of spreading false information if not borne out.

So I decided to do an admittedly limited pair of tests to see if I could validate the original claims.

The Claim and Test Methodology

The claim itself against Windows FE easily defines the tested goal:

Windows FE is not a "forensically sound" Windows boot disk. You can prove this by booting any non-Windows system with Windows FE and take a hash of the drive(s) before and after booting with Windows FE.

So here were my goals:

  1. Build my very own Windows FE “forensic environment” boot disk based on Win PE 2.0.
  2. Prep a target Windows system to be used as the focus of my “incident” test.
  3. Use a forensic (non-Windows based) LiveBoot CD to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
  4. Use the Windows FE boot disk to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
  5. Reuse the same boot-disk in Step 3 to re-hash the target system one more time (to see if the Win FE boot changed the drive).
  6. Compare results.
  7. Sanitize (zero-out all sectors) of the target physical system used in Step 2.
  8. Install a “non-Windows” operating system on the target system’s physical drive.
  9. Use a forensic (non-Windows based) LiveBoot CD to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
  10. Use the Windows FE boot disk to “off-line” boot the target system and obtain an MD5 hash of the physical hard-disk.
  11. Reuse the same boot-disk in Step 3 to re-hash the target system one more time (to see if the Win FE boot changed the drive).
  12. Compare results.

If at the end of steps 6 or 12 I find that a different MD5 hash has been generated, then Windows FE fails and the claim that “booting any non-Windows system with Windows FE” is correct.

If they pass, that, to the extent of these particular tests, the statement is false.

The Test: Step 1

Following the information exactly on building a Windows FE disk that I found and posted in my previous Windows FE post, in no time flat I had quickly and easily prepared and burned my Windows FE disk.  Note: my version was build on the Vista SP1 WAIK version.  Use of a different version may provide different test results.

In preparing the disk, I also included George M Garner Jr.’s Forensic Acquisition Utilities as I would need a tool on there (dd.exe) to calculate the MD5 hash off Windows FE booting.

As an fairly experienced Win PE builder, this was simple to build, including making the two registry changes needed (as claimed) to prevent write-back access to the physical drives of the booted system.

5. In regedit, go to the HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\MountMgr key, and if the NoAutoMount dword does not exist, create a dword named "NoAutoMount" with a setting of 1. If the key already exists, change the setting to 1 if it is any other value.

6. Next, go to HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\partmgr\Parameters and change the SanPolicy setting to 3. (If the Parameters key does not exist, create it.) At this point, the registry in the mounted .wim file is set to boot and operate without mounting volumes or modifying media.

The rest is just standard Win PE building stuff.  More on why those two registry tweaks are so critical later…

Disk in hand I was ready for the next steps.

Target System Prep: Windows OS

I selected a standard Dell Optiplex 745 business-class system that has dual cores, 1 GB RAM, and a single SATA 80 GB drive.

I booted the system with one of my many Win PE boot disks.

I then ran DISKPART, selected DISK 0, and ran the CLEAN ALL command which as documented, zeros out all the sectors of the focus drive.

For good measure, I then used one of my many sector viewers to inspect the disk to verify there was nothing left and it was zeroed out.

I then used DISKPART to create a primary partition, set it active, assign a drive letter and format it under NTFS.

I then applied a standard machine XP Professional image using ImageX, booted the system when done, completed the sysprep process and got it in a “usable” state.

I shut the system down.

Ready for Windows OS system hashing! 

I next needed to take a MD5 hash of the Windows system using a non Windows FE boot disk.

There are lots of great and freely available Linux forensic-focused boot CD’s to use for this task. In the end I chose to play with DEFT (Digital Evidence & Forensic Toolkit) which is a Xubuntu Linux-based Computer Forensics live CD.  The more I use it the more I find stuff to like.  I used the DEFT version 4 beta build for my tests.

Using a CD-tray needle, I opened the CD tray door and placed the DEFT boot CD in it (to avoid any possibility of accidently getting the Windows OS loaded) and booted the system.

Once booted and the DEFT-GUI loaded, I used their Dhash GUI tool to generate a MD5 hash of the physical hard drive, reported by DEFT as sda.  (Dhash reference links: Dhash - DEFT wiki, Dhash - DEFT Linux, and Dhash 1.1 DEFT Linux)

I captured the following MD5 hash:

4e3efe13706b83007770035d0829589e

I shut the system down, inserted the Windows FE disk and rebooted the system.

Once up on the CMD window, I used DISKPART to verify I could see the physical drive (I could) and then browsed into the Win FE disk’s \WinFE folder I created and put the FAU tools into.

I used the dd.exe tool with the following command: (Note: both George M Garner Jr.’s FAU documentation as well as these dd.exe tips from Alexander Geschonneck helped me.)

dd.exe –v if=\\.\PhysicalDrive0 of=NUL –cryptsum MD5

When completed it outputted the following MD5 hash:

4e3efe13706b83007770035d0829589e

I then shut down the system and again rebooted with DEFT LiveCD and used Dhash to rehash the drive one more time to verify Win FE hadn’t changed/modified the physical drive.

4e3efe13706b83007770035d0829589e

It had not.

Test Observation #1

Based on this test, it appeared clear to me that when properly built, a Windows FE boot disk did not modify the physical hard-drive contents of a Windows-based OS system on that drive.

So far so good, but that isn’t being challenged in the comments.

Recall, the comment poster claimed that the non-forensics issue is found “…by booting any non-Windows system with Windows FE…” (emphasis mine).

On to test challenge stage 2.

Target System Prep: Windows OS

Using the same test system Windows was loaded onto, I booted the system with one of my many Win PE boot disks.

I then ran DISKPART, selected DISK 0, and ran the CLEAN ALL command which as documented, zeros out all the sectors of the focus drive.

For good measure, I then used one of my many sector viewers to inspect the disk to verify there was nothing left and it was fully zeroed out.

This time I needed to install a non-Windows system on the drive.  For this I chose the Linux-based forensic CAINE Live CD.  I’m also finding a lot to like in this forensics distro as well.

It has an option to do a local install which I selected.  During the setup process I created a ex3 partition as well as a swap partition.

When done I booted into the system proper, off the hard-disk, mucked around a bit to generate hard-drive changes, and then shut the system down.

Ready for non-Windows OS system hashing! 

I next needed to take a MD5 hash of the CAINE non-Windows (Linux) system using a non Windows FE boot disk.

I again used the same DEFT live CD.  

Using a CD-tray needle, I opened the CD tray door and placed the DEFT boot CD in it (to avoid any possibility of accidently getting the CAINE system loaded) and booted the system.

Once booted and the DEFT-GUI loaded, I used their Dhash GUI tool to generate a MD5 hash of the physical hard drive, reported by DEFT as sda. 

I captured the following MD5 hash:

71649687fa1f7b64462da2d6ac6c7bee

I shut the system down, inserted the Windows FE disk and rebooted the system.

Once up on the CMD window, I used DISKPART to verify I could see the physical drive (I could) and then browsed into the Win FE disk’s \WinFE folder I created and put the FAU tools into.

I quickly used the dd.exe tool with the following command:

dd.exe –v if=\\.\PhysicalDrive0 of=NUL –cryptsum MD5

When completed it outputted the following MD5 hash:

99de7237675a4f61ee529e3d74173391

Oh my gosh!

The Windows FE disk did appear to now issue a different hash on the drive by booting a non-Windows OS with it.

Could it be true after all?

A Pregnant Pause of Silence and Study

I then shut down the system and again carefully rebooted with DEFT LiveCD and used Dhash to rehash the drive one more time to verify Win FE had indeed changed/modified the physical drive.

71649687fa1f7b64462da2d6ac6c7bee

Amazingly, that was the same MD5 that I captured from DEFT pre Windows FE boot.

I shouldn’t have gotten that if Windows FE had changed the disk.

Something was up.

I shut down and rebooted again with Windows FE.

I paid closer attention this time as I re-ran the dd.exe MD5 hash.

dd.exe –v if=\\.\PhysicalDrive0 of=NUL –cryptsum MD5

This time, I noted that before it started the Hashing, it was waiting for a response from me if I wanted (Y/N) to apply the “conv=noerror” parameter first.

I have to confess I didn’t notice that before.

I referred back to George M Garner Jr.’s Forensic Acquisition Utilities documentation page and specifically the part about dd.exe as follows below under “Specific Remarks #7”:

The default block size for DD is 1 MiB.  The handling of “bad blocks” (“conv=noerror”) is new.  Traditional versions of DD skip “bad blocks” in increments equal to the block size.  If the block size is larger than the sector size of the device, data will be lost.  The alternative is to set the block size equal to the device sector size.  But that is usually quite slow.  The new version of DD uses the specified block size until a “bad sector” is encountered, at which point the block size drops back to a value equal to the device sector size.  The larger blocks size is resumed once the “bad block” is passed, until the next “bad block” is encountered.

Ah!

The first time on the non-Windows OS test in Win FE I now recall answering “N” and thus got the hash 99de7237675a4f61ee529e3d74173391.

This time I answered “Y” to the use “conv=noerror” option.

I captured the following MD5 hash:

71649687fa1f7b64462da2d6ac6c7bee

Same as the original pre- Windows FE boot using DEFT.

For good measure I then shut down Windows FE, and rebooted with the DEFT LiveCD one more time and Dhashed sda one more time.

And I captured the following MD5 hash:

71649687fa1f7b64462da2d6ac6c7bee

Windows FE Experiment Conclusions

Based on my specific system and configuration testing validation, I can comfortably make the following statements:

  1. When properly booted and used, the DEFT forensic LiveCD does not appear to modify or change the physical hard-drive of a Windows-based OS.
  2. When properly created, booted, and used, a Windows FE (PE 2.0 Vista SP1 base) forensics LiveCD does not appear to modify or change the physical hard-drive of a Windows-based OS.
  3. When properly created, booted, and used, a Windows FE (PE 2.0 Vista SP1 base) forensics LiveCD does not appear to modify or change the physical hard-drive of a Linux-based non-Windows OS.
  4. When properly booted and used, the DEFT forensic LiveCD does not appear to modify or change the physical hard-drive of a Linux-based non-Windows OS.

Granted, this was one series of tests, on one particular hardware system configuration using XP professional and Linux OS’s.  Other non-Windows OS’s and/or hardware configurations might produce different results.

But it looked good for me.

While not a forensics investigator and just a sysadmin in the trenches, Windows FE seems to sufficiently answer my questions on whether or not it can off-line boot a system without making changes to the storage media (hard-drive) of the system.  It can.

Forensics examiners and investigators who have give legal testimony when using Windows FE could and should perform similar independent testing to validate their particular system/OS combinations first.

The Rest of the Story.

All this was a lot of geeky fun for me.

I haven’t used the commercial forensics tool in question noted in the comments as being “..the only forensically sound write-blocked Windows boot disk in existence.”

It might indeed be a great and fantastic product.  I haven’t used it so I can’t say, particularly for real forensics usage.  I can understand why they would be proud of their product and all the efforts they have put into development.  I can’t blame them for wanting to share their pride with others, and differentiate it from other forensics products.

But like forensics specialist DC1743 said, the comment claim was a pretty sweeping one.  And it didn’t hold true in my test.

The commentor issued a challenge to test their statement for accuracy.  I did and found it a bit wanting after test validation.

As I mentioned before, John Sawyer hit it on the head when he reminded all forensics experts (and lowly sysadmins as well) that we all have a duty to test the tools we use. Tool Validation: Trust, But Verify - Evil Bytes Blog - Dark Reading

Fortunately for all of us, there are a lot of fantastic forensic tools out there to pick from. Commercial ones and non-commercial ones alike.  Each have their own sets of strengths and weaknesses.

The Two Keys of Windows FE

This whole exercise wasn’t enough, however.

I wanted to see if I could find a bit more information on the particular (and only) registry keys that were modified in building the Windows FE disk and what differentiated them from a regular Windows PE disk.

Turns out there just isn’t a lot of public documentation on these keys, but I did find some juicy bits anyway.

(Note: SAN stands for “storage area network” in these cases.)

HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\MountMgr key, and if the NoAutoMount dword does not exist, create a dword named "NoAutoMount" with a setting of 1

This control setting (under default) tells the storage mounting manager (when booting a system) to add and automount storage disks to the system. From the second link noted above.

The SAN policy determines whether a newly discovered disk is brought online or remains offline, and whether it is made read/write or remains read-only. When a disk is offline, the disk layout can be read, but no volume devices are surfaced through Plug and Play (PnP). This means that no file system can be mounted on the disk. When a disk is online, one or more volume devices are installed for the disk.

This enumeration supersedes the NoAutoMount registry key, which can be found under the following registry path:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Mountmgr\NoAutoMount

The value of this key is a REG_DWORD value that is set to 0x00000000 to enable the Windows automount feature or a nonzero value to disable it. If the automount feature is enabled, Windows automatically mounts the file system for a new basic volume when it is added to the system and then assigns a drive letter to the volume. In system area network configurations, disabling automount prevents Windows from automatically mounting or assigning drive letters to any new basic volumes that are added to the system.

…and as described in “normal language” as provided by David Shen –MSFT in the third link above:

We can verify the status of Automatic mounting of new volumes by looking at the value of the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MountMgr\NoAutoMount

If the value is set to 1: This indicates that Automatic mounting of new volumes is Disabled.

If the value is set to 0: This indicates that Automatic mounting of new volumes is Enabled.

Now for the second key.

HKEY_LOCAL_MACHINE\winfesystem\ControlSet001\Services\partmgr\Parameters and change the SanPolicy setting to 3

This key appears to control how the Windows system processes the partition manager configuration when loading the system and any SAN (storage area network) devices it finds while booting.

From the first link:

  1. Locate and then click the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PartMgr

  2. In the details pane, examine the value of the Start registry entry. To start PartMgr when the computer starts, this value must be 0x00000000.
  3. Exit all programs, and then restart the computer.
Note The following table lists the service startup types that are available in Windows.

Startup type
Hexadecimal value

Boot
0x00000000

System
0x00000001

Automatic
0x00000002

Manual
0x00000003

Disabled
0x00000004

Typically, device drivers are set to use a startup type of Boot or System. Typical Windows services are set to use a startup type of Automatic or Manual.

And from the second link:

The functionality of Storage Area Network (SAN) enables a server to mount disks and other storage devices automatically from other computers.

By configuring the SAN policy on a Windows image, you can control whether or not disks are automatically mounted, which disks can be mounted, and you can disable automatically mounting disks.

Configure the SAN policy on Windows PE

For Windows PE images that are available in the Windows OPK and the Windows AIK, the default SAN policy is to mount available disks automatically. This might reduce the performance of Windows PE if there are many available disks in the SAN environment.

SAN policy number     Description

1   Mounts all available storage devices. This is the default value.

2   Mounts all storage devices except those on a shared bus.

3   Does not mount storage devices.

This is getting deeper than the typical Windows OS sysadmin waters I swim in, so I’m open to hard-core Windows OS registry pros to correct me or provide additional supportive explanation on what’s going on here.

But basically, it seems based on these links, that by making the registry changes specified when building the Windows FE disk, it prevents the automounting of attached storage media (disks) to a system during the Windows (PE/FE) boot process, and forces any mounting that needs to occur to be done manually (by the system operator).

If this is correct, and these two Windows Registry keys are set correctly, then it seems that in most cases, the Windows PE (FE) OS boot shouldn’t care what OS is loaded on the system and the drives remain unmounted and unattached from the Win PE (FE) boot OS system.

You can see them and browse them, but they remain “unmounted” devices and not accessible unless manually attached and mounted to the Win PE (FE) system using DISKPART.

Or so it seems.

Whew.

Who knew testing and validation could be so educational and fun!

Cheers and best regards to all computer forensics developers and expert examiners alike!  My late grandfather (retired F.B.I. Special Agent) would be proud of your collective efforts.

I know I sure am.

--Claus V.

GSD How To: Dual Boot Windows 7 on Vista via VHD file

I love and depend on virtual machines to test software and system configurations.

In most cases, it is sufficient for my testing purposes.

One drawback of this is that it isn’t a “true” test of the operating system’s performance since the hardware used is being virtualized via software.

There are lots of guides around the net as well as utilities that can assist you in configuring a system to “multi-boot” different OS versions off the hardware, but these can be a bit challenging to set up for average folks.

Recently, while I’ve been playing with Windows 7 Beta in Virtual PC 2007 sessions, I’ve been itching a bit more to try the performance on real hardware, but I haven’t wanted to commit to wiping one of my systems entirely clean first.  Nor did I want to fuss with a pure Vista/W7 “dual-boot” configuration as they traditionally are done.

Instead, I knew that Windows 7 brings with it an exciting new feature, that is perfect for this particular case; it supports booting a system from a VHD file.

However, I’ve got a slight issue.  Windows 7 uses updated bootloader files to make that happen.  Windows Vista uses similar files, but those versions don’t support VHD booting.

I don’t want to install Windows 7 to be able to boot a VHD of Windows 7; that kind of defeats the intended purpose for me.  Most all the guides on doing this only describe how to pull it off that way. No, what I want to do is to keep my local Vista install intact, and somehow boot into a VHD of Windows 7…thus running it “live” on the real system hardware instead of on virtualized hardware.

Can it be done?

Yep.

I’ve had to pick at a number of posts to spin this thing together.  Credits for source material in all their fantastic goodness at the post end but up front, prime props and hat tips go to Aviraj Ajgekar and Adrian Kingsley-Hughes. I’ve copied some of their steps because they were so good, I had little to add.

You will need a couple of things first:

Ensure you have a copy of a Windows 7 beta setup DVD handy. You can use the ISO file itself to get started however you will need the burned DVD at some point.

I also found it helpful to use my WinPE 3.0 custom boot disk.  This is optional, but could be handy.

And you will need a Vista-installed system.

Warning: proceed at your own risk. You might tank your Vista system if not performed correctly.  I recommend practicing on a Virtual PC VHD with a Vista install first a few times.  What has worked fine for my on my system might be an issue for you. The screen shots included in this post were obtained from a walkthrough of these steps as performed in a Virtual PC session with the free Microsoft Vista IE App Compat VHD as the primary OS.

Step One: Extract the key Windows 7 system boot files.

We need two key files from a Windows 7 system to get things started on our Vista system.

They are the BootMgr file located on the root of the Windows 7 system as well as the BCDEdit.exe file from the Windows 7 Windows\System32 folder.

There are a couple methods you can use to get them:

  • from an already installed Windows 7 system,
  • from a virtual Windows 7 installed system,
  • extract them from the Windows 7 DVD/ISO.

The first one is easy, assuming you are running as an “administrator” and have enabled the ability to show hidden and system files, you could just copy them to a USB stick.

The second method is a bit more tricky.  Virtual PC does not support USB devices, so you will have to change the settings to allow it to mount a local “real” system folder, then copy them into there so you can off-load them to a USB stick.

For both of these options you basically can follow the following steps:

From the Windows 7 desktop, open an elevated command prompt with Administrator Privileges and type the following commands.

C:\windows\system32>xcopy /h /y bcdedit.exe f:\   

(Note: In this case, F: is the external USB stick.  /H - Copies hidden and system files.  /Y  suppresses prompting to confirm you want to overwrite an existing destination file.)

C:\>cd\

C:\>xcopy /h /y bootmgr f:\

If you can’t find the second file,even as an elevated admin, you will have to use a Vista or Windows 7 boot DVD to boot the system and then do a Shift-F10 to get a sufficiently elevated command prompt to access it.

The third option is involved, but I found it easy as well.  On your Vista system, use an application that allows you to mount the Windows 7 beta setup DVD ISO as a drive letter.  I used SlySoft Virtual CloneDrive as it is a free and stable tool.

Once the ISO is mounted, you will find the bootmgr file on the root of the drive. Copy it to your USB drive and you should be able to do so using a file manager that has been set to show hidden/system files.

Then using ImageX, go into the mounted ISO directory structure and mount the \sources\install.wim file. 

Once mounted, browse into the folder you set as your mounting folder and look in the Windows\System32 folder for the BCDEdit.exe file.  Copy it to your USB drive.

Then go back and dismount both the WIM file and the ISO file in turn.

Got em both?  Good.

Step Two: Back up the original Vista boot file versions

Now it gets a bit scary.

First you want to make backup copies of the Vista versions on your Vista system:

Boot your Vista system and once on your desktop, open an elevated command prompt with Administrator Privileges and type the following commands.

C:\windows\system32>cd\

C:\>xcopy /y /h bootmgr bootmgr.sav

Press f after prompted

C:\>cd Windows\System32

C:\windows\system32>xcopy /y /h bcdedit.exe bcdedit.sav

Press f after prompted

Step Three: Replace the original Vista boot file versions with Windows 7 versions

Now it gets a bit scary.

We must replace the Vista versions of BootMgr and BCDEdit.exe which do not support VHD based booting source with the Windows 7 ones we copied earlier, which do. 

You may use a WinPE 3.0 boot disk or your Windows 7 Boot DVD and Boot into Windows Recovery Environment.  This is important as WinPE 2.0 and the Vista setup DVD don’t have the updated Windows 7 version of DiskPart that we will need. 

Insert the USB drive you have copied the Windows 7 versioned files onto into the system as well.

If you use a standard WinPE 3.0 disk, you should be greeted with the CMD window.

If you are using a Windows 7 setup disk then boot the system from the chosen disc. Once the Windows installer is up and running, choose your language and once you’re on the Install now screen, press SHIFT+F10 to bring up a Command Prompt.

Open the Elevated Command Prompt and type the following commands.

C:\>attrib bootmgr –s –h –r                    

(Note:  in this case C: is the local Windows Vista OS Partition and the attribute command with –s –h –r changes the System, Hidden and Read Only attributes of our target file.)

C:\>e: 

(Note:  in this case E: is our USB stick.  You might need to check to make sure what your USB stick is showing up as.  Note as well that depending on where you copied it onto the USB stick, you might have to add additional file directory information.  The examples below assume both Windows 7 files were copied to the root of the USB stick.)

E:\>xcopy /y /h bootmgr c:\bootmgr

E:\>xcopy /y /h bcdedit.exe c:\windows\system32

image

(Note: in the above screen-shot I took, I made a slight change in the instructions above and had pre-copied the Win7 boot files to a C:\win7 folder on my Vista system.  That’s why those commands vary slightly from the ones provided above.  Adjust accordingly.)

Step Four: Create the VHD file we will be installing Windows 7 into

We are committed now!

Note: Adjust the MAXIMUM value as needed but note, you better have enough free space on your local hard drive to support it!  I would recommend somewhere between 15000 and 25000 to create an (approximately) 15 GB to 20 GB VHD partition to install Windows 7 into.  Choose your VHD location wisely.  I put mine on the local system hard-drive root.

We should still be in the Windows 7 CMD prompt box so type the following commands.

DISKPART

CREATE VDISK FILE = "c:\win7.vhd" MAXIMUM = 20000

SELECT VDISK FILE = "c:\win7.vhd"

ATTACH VDISK

CREATE PARTITION PRIMARY

ASSIGN LETTER = G

FORMAT QUICK LABEL = Windows7

EXIT

This just created the VHD file of primary partition into which we will next install Windows 7.

image

(Note:  In the above example I first tried to assign drive letter = X but that would not work as X was already assigned as the RAM disk used by the Windows 7 Setup DVD boot.  That’s why I switched to “G” instead"!)

Step Five: Install Windows 7 into the VHD file

Type Exit again to get out of the command prompt and return to the Windows 7 installer Wizard.

Continue with the installation steps as normal and when prompted, choose “Custom install” so we can tell it where to place it.

When prompted by the “Where do you want to install Windows” if all is well, you should now find a Disk1 reporting in as Windows7 free space = to approximately what you selected for the MAXIMUM amount in the preceding step.

Select that one and continue on.

image

You may see a warning of sorts about Windows7 not being able to be installed to (or boot from) that disk.  Just ignore it and after selection, hit “next” and continue with the installation process.

Step Six: Boot Windows Vista or Windows 7

After you reboot, you should see the Windows Boot Manager prompt you to select Windows Vista or Windows 7 to boot into.

image

Select Windows 7 to boot into your Windows 7 VHD and run off the real hardware.

Select Windows Vista to boot into your original Windows Vista installation.

Cool!

image

Note in the above screen shot, the “primary” hard-disk shows up as drive letter D: with all the files\folders accessible while the Windows 7 VHD file “win7.vhd” becomes the “new” drive C:.

Remediation

I haven’t had to “roll back” to Vista only, but basically you will use the techniques listed here to simply restore the original Vista versions of the boot files you made (you did follow that step right?) over the Windows 7 versions after rebooting the system with the Windows 7 DVD again.  You shouldn’t have to reuse diskpart to detach the VHD.

Note also that even though you replace the bootmgr and bcdedit.exe files back to the original Vista versions, a reboot will still show that Windows7 is listed along side the original Vista install.

To remove that out, you will have to also (from the Shift-F10 elevated command prompt with either a Vista Setup DVD, Windows 7 Setup DVD, or a Win PE 2.0/3.0 boot disk, run a bcdedit.exe command.

This is what I did on mine, but you need to be careful it is accurate for yours.

Run bcdedit.exe first to list the boot stores and figure out which one Windows7 is reporting as.  In my case it was {default}.

So to remove Windows7 from the boot configuration data store list I issued the following command:

bcdedit /delete {default}

Rerunning the bcdedit command showed all was back to normal and the Vista boot store information had been updated as the default (and only) OS boot choice again.

A reboot and all was restored to the normal Vista only booting.

Then once you are up and running Vista alone again, delete (if desired) the Windows 7 VHD file you created if you feel you no longer need it.

For more tips on Vista/Windows7 boot configuration management tool BCDEDIT (as well as an incredible GUI alternative EasyBCD) see these links:

Additional Reading and Credits

I found the following posts very informative about both the VHD booting support feature of Windows 7 as well as how to apply this to a Vista installed system.  I recommend reading and understanding them first before you set off to follow this post.

They also contain great screen-shots of much of this process, as well as few variants of the technique I outlined here.  You might find things more clear after reviewing them as homework before life-fire application of this hack.

And once again, I strongly encourage you to try this out on a Vista VHD file in Virtual PC first, to make sure you can follow and successfully pull off these steps.  It’s easy to practice until you are sure of yourself before taking on your “real” Vista installation.

Now get out there and have some fun, and see the difference in system performance between Vista and Windows 7 on your real desktop or laptop system!

Cheers.

--Claus V.

Sunday, March 15, 2009

Custom WinPE Building: Post-Script and PE 3.0

I hope everyone enjoyed and found something of interest in the recent custom PE boot-disk building series I posted recently.

The purpose of that project was 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 I could “liveCD-boot” a PGP WDE system (assuming we have the user’s passphrase).  And it had to handle the Dell GX 7xx series USB keyboard drivers.

However, there were a few extra links and tips that didn’t directly pertain to my focus and I decided to leave out.  You might want to be aware of them so I’m sharing them now.

This thread has a tip in it offered by “ctmag” that claims when followed, it resolves the USB keyboard pickup issue in VistaPE builds.

add the following lines at the end of the [Process] section of 04-additional.script

CODE

DirCopy,"%BootSRC%\Windows\inf","%TargetDir%\Windows"
DirCopy,"%BootSRC%\Windows\system32\drivers","%TargetDir%\Windows\system32"
DirCopy,"%BootSRC%\Windows\system32\driverstore","%TargetDir%\Windows\system32"
FileDelete,"%TargetDir%\Windows\inf\*.pnf"
DirDelete,"%TargetDir%\Windows\inf\BITS"
DirDelete,"%TargetDir%\Windows\inf\RemoteAccess"

it will need some more space on the disc and also in RAM, but it fixes the USB Mouse/Keyboard issue and it also fixes a bug where when you booted from an USB drive the USB drive was not visible (only the X drive was visisble..)

Because I was able to get my USB keyboard issues going with my custom method, and had to do the extra work for PGP driver injection, I never went back to try this out.  If you aren’t messing with PGP drivers and only doing VistaPE building, it might be a faster fix.

Another thing I didn’t do (but aggravates others) is to take out the “"Press a key to boot from CD” prompt with the PE boot disk.  I leave it in, as from time to time a technician will leave a boot disk behind in a user’s system and leave the site.  Next time the user boots (if this is removed) they end up on a WinPE or Linux desktop and it confuses the fire out of them.  This check allows the system to continue booting to the main OS if a key isn’t pressed.

However, if it annoys you and you want to just boot directly from the CD to the WinPE environment, then do this:

if you don't want to be prompted to boot from the WinPE 2.0 CD or DVD, delete the bootfix.bin file from the \ISO\boot folder before creating your WinPE 2.0 CD/DVD.

Easy enough.

This new VPELDR file seeks to get around some of the hardware detection and pickup issues the “stock” VPELDR has.  With the exception of the USB keyboard, I’ve not had any issues so I haven’t tried it.  Swapping out the stock for the new one seems to cause other potential issues.  However, if you have a driver that is giving you the blues in WinBuilder/VistaPE building, you might want to try it. Note, VistaPE/WinBuilder 12 will have some new tricks that will surpass this interim tweak, so if things are good-enough, just make a note and leave it alone for now.

Yes.  If you haven’t figured it out by now, WinPE 3.0 is based on the Windows 7 WAIK.  Just like WinPE 2.0 was/is based on the Vista WAIK.

So what I did (being the curious dude I am) was to re-follow all the steps in my custom WinPE building project, even down to the PGP WDE driver injections.

Only this time I used the WIM source file from the Win7 WAIK kit instead.

Everything went smoothly.  No errors at all.

When I was done, I created my Custom WinPE 3.0, PGP WDE injected driver and VistaPE enhanced ISO file.

Worked absolutely-fricken-perfect!

So now instead of a Vista SP1-based WinPE 2.0 custom boot disk tool, I’m now using a Windows 7 (beta)-based WinPE 3.0 custom boot disk tool.

Wicked cool!

How I got the key guts needed for the Windows 7 WAIK PE 3.0 building work and am using them on my XP/Vista systems under the Windows Vista RC1 WAIK install…well it’s not rocket-science, but it will have to remain a post for another day.

Cheers!

--Claus V.

Sunday, March 08, 2009

GSD’s Weekly Briefs…the clean ones

image

cc photo credit Augapfel on flickr

This “Spring Forward” time change is going to eat my lunch tomorrow morning.

OK kiddo’s  Here you go.  The GSD Link Briefs of the Week.

Light on comments.  Maybe that will keep em from riding up too much in the tender places…

All must reads for folks doing incident response due to suspected malware.  Lots of great tips and techniques to use.  Each case is different, but having an organized response plan makes these things easier to take apart.

  • Microsoft Malware Protection Center : FakeXPA – The Journey Continues – As noted by Harlan this baddie is pretty interesting.  The Microsoft team pick it apart pretty good with technical information.

  • Ask the Performance Team : Netbooks and Windows 7 – I’ve heard that a PC maker is suing Intel over the “netbook” term as trademarked.  But it does look like W7 design bodes well for good performance even in the hardware challenged arena of netbooks and micro-laptops.  That’s a good thing for older system performance as well.  I like Vista and it seems to run OK on our laptops, but I’m really feeling performance could be much snappier still.  I might get bold and try to dual-boot it with a VHD boot of Windows 7 so I can really get a sense of the true hardware performance it could offer.

  • Ask the Performance Team : The Case of the Unsigned Printer Drivers and .NET 3.5 Service Pack 1 – Not quite as good as a Mark Russinovich special, but still good troubleshooting information.

  • 4sysops - Windows 7’s Problem Steps Recorder – Good peek into this helpful tool for remote troubleshooters.

  • 4sysops - Windows 7 new manageability features – Michael’s got a nice rundown of some more advanced features of W7 that system administrators may be curious to know.

  • NK2View - (freeware) – Nirsoft utility update - View/Delete/Edit Outlook .NK2 AutoComplete Information.  New version supports backup/restore of the file itself.  Something previously not quite possible.

  • Panda USB and AutoRun Vaccine - (freeware) - Panda Research Blog provides a two-stage tool.  Stage one locks down your entire system from auto-run exploit.  Stage two renders any USB drive that the tool is applied to “inoculated” against infection by an auto-play vectoring malware infection.  Read carefully before applying.  Some could be “permanent” (at least without reformatting the removable device).  See also these related AutoRun security posts: Grand Stream Dreams: USB Security: AutoRunGuard, Encryption ..., Microsoft Security Advisory (967940): Update for Windows Autorun (fixes the not-quite working completely patch), as well as AutoRun Eater - (freeware) – This neat security utility provides a different take.  It runs in the system tray full-time and monitors execution of autorun files when devices are inserted or executed.  Upon discovery it first performs an analysis. If a suspicious pattern is found, it blocks execution, tosses up a dialog window, and presents the suspicious code.  Then it allows the user to block or ignore execution.  Amazingly clever.  Certainly not a cure-all, but it might very well provide a first and easy to use line of defense for non-technical users as well as experienced system administrators who don’t want to use some of the tougher/lock-down methods against blocking all autorun executions.

  • Quickpost: /JBIG2Decode Trigger Trio « Didier Stevens blog, and S√Ľnnet Beskerming - An Interesting Result for JBIG2 PDF Vulnerability, followed up by Inside Exploited PDF from the Threat Researcher’s blog.  These are primarily discussing the latest Adobe Reader vulnerability - This has been simmering for a while but security researcher Didier Stevens (who specializes in PDF formats) found something very serious.  Quoting from Didier’s first link: "Under the right circumstances, a Windows Explorer Shell Extension will read the PDF document to provide extra information, and in doing so, it will execute the buggy code and trigger the vulnerability. Just like it would when you would explicitly open the document. In fact, we could say that the document is opened implictly, because of your actions with Windows Explorer."  That could be a biggie considering the pervasiveness of PDF documents.  Malicious PDF's as a vector attack have been around for a long time, as readers of Didier's blog know. However this one seems to be particularly potent as the mal-crafted file doesn't need to even be launched.  Furthermore, many have moved to the great (and free) Adobe Reader alternative Foxit Reader. However, if Adobe Reader is installed on the system also, the vulnerability still actively exists. You currently appear to have to entirely uninstall the Adobe Reader from your system...

I'm not suggesting folks should run out and do that...but at least for now, keep a close eye out on these developments as many AV vendors still are not detecting this new threat. Hopefully Adobe will be responding with a fix soon.

Didier suggests using Nir Sofer’s freeware Shell Extension manager to disable this feature for now.  Or you could also use Sysinternals Autoruns to display and disable this handler. For this PDF handler, look in the tab “Explorer” under the following section:

“HKLM\Software\Classes\Folder\Shellex\ColumnHandlers”.

Search for the PDF Shell Extension and disable it.

Finally, you might want to take a look at the advice in the Do you use Adobe Reader? post also at the awesomely good Threat Researcher blog.  Good stuff to know for Adobe Reader fans.  I’ve walked away impressed enough to add this blog to my RSS feed list.

  • PortableApps.com Platform 1.5 Released - (freeware) – New app launcher build from the first-place I go to find portable tools that work flawlessly on my Windows USB stick.  Many new features and tweaks.  Check it out.

  • FreeCommander - (freeware) – The very best-est (IMHO) freeware multi-paned file manager there is, hands down.  Period.  No more discussion.  The only file manager I use at work and home on my personal systems.  Anyway, new version release came out for some enhancements, feature adds, and stability fixes.  2009.02.  You can get in in an installer based setup file, or if you know where to look, portable versions are available as well.  Scroll that page to the very bottom to find the simple zip file versions.

  • Mozilla rethinks the behavior of new browser tabs – download squad – You think?  What with the new Safari 4 beta favorites page, Chrome’s favorite page, Opera’s favorites page, all these multipage pages makes Firefox look a bit late to the party.  So Mozilla thinks it needs to the bloat-creep by doing one as well.  See next link…

  • New Tab Page: Proposed design principles and prototype – Mozilla Labs.  Bloat-creep/feature-creep.  I’m wondering if it isn’t all the same thing…

  • NewTabURL :: Firefox Add-ons – This is my response.  I use this Add on and love it.  It is perfect with customizing new-tab content launching.  While I do feel Mozilla should provide just a bit more default customization options to new tab handling, too much is a bad thing.  NewTabURL  allows you to set new tabs to open to your home page, blank page, or current page, it also allows you to specify your own default URL to open up to. Want to go even more custom? Create your own HTML page, image or other stuff and point to it instead! For example I can use the format file:///%drive-letter%:/filename.whatever and open that in blank tabs. On my system, I have it set to use the following link: http://bighugelabs.com/flickr/random.php . I have coupled that with some editing (redaction) of page elements with the Remove It Permanently :: Firefox Add-on and now each time I open up a blank page, I am gifted with a random selection of images from flickr.  Of course….that is on my home machine only.  I end up getting some NSFW images from time to time that I couldn’t tolerate at work.  So for there I have to go with something a bit different.  Finally, NewTabURL can be set to open up a URL if it finds one in the clipboard contents. Very handy when you find a non-hyperlinked address browsing and copy it. Instead of manually opening a blank tab, pasting it into the address bar and launching it, this extension can handle it automagically!

  • Next Firefox version bumped to 3.5, another beta to come - Mozilla Links.  OK.  Get a move on.  I’m still waiting for the next 3.1 beta release 3 to come out.  I tried the nightly version in a testing package I use, but it didn’t render the NewsFox RSS feed reader extension I use very nicely.  So I’m sticking with the stable 3.1 beta 2 release still for now.

I had hoped to get through a number of additional posts this weekend, but it was too sunny, Alvis was at her Grandparent’s house, and the chores and quality time spent with Lavie were just too important to pass up camped out on the laptop all weekend long.  Had some Apple Safari issues as well as a rouge VIPRE definitions update that locked up our desktop system until resolved.  Those took an unexpected amount of time.

Lavie and I even managed to escape on a “date-night” Saturday.  Sure it was just down to the local Chick-Fil-A, but we did score a bar-height table complete with fresh flowers and a view over the sparking and romantic lights of the local Lowe’s store in the strip center.

Romance is where you make it happen for yourselves kids….

Cheers!

--Claus V.