So, What Is New Concerning Disk Protection?
From a birds eye view the quick facts: The Enhanced Write Filter has undergone an overhaul especially targeted at its configuration and management functionality as well as the accompanying tools.
Then there is a set of new filters: The File Based Write Filter (FBWF) and the Registry Filter. These filters solve quite a lot of the issues EWF was able to satisfy or simply by its architecture not intended to do so.
Let’s have a closer look at the details.
Enhanced Write Filter
The Enhanced Write Filter is a filter driver sitting between the file system and the disk driver. It works on disk sector level and this means that it redirects changed sectors to a new location called an overlay. The filter is not aware of any file system specifics. Due to this, persisting a certain file through it to the underlying image directly (without turning it off) requires the file having a fixed size (claiming always the same sectors on the disk drive). This is the reason for some of the limitations that are experienced using EWF.
EWF’s possible overlay modes come in three flavors disk, RAM and RAM (Reg). While disk overlay is able to generate up to seven overlays on a special overlay partition, the two RAM modes are only capable of holding a single overlay, which is volatile by the nature of the storage medium (RAM). The difference between these two modes is, that RAM overlay, like disk overlay, requires an additional EWF partition on the storage medium to hold the EWF partition table data. This additional partition is not easy to handle, looking at factory install processes as well as maintenance.
Microsoft has introduced another mode to target this problem with Service Pack 2 called RAM (Reg). In this mode the EWF partition table info is stored in the registry instead on a special partition, which simplifies deployment a lot.
However, RAM (Reg), due to its lack of integration into the XPe tools, felt like a kind of secret mode, because getting it to work required quite some manual work by the OS developer.
With the Feature Pack 2007 these times are gone! As shown in figure 1, RAM (Reg) mode is now a first class citizen of the EWF world.
Figure 1. New EWF component configuration settings
This eliminates, for example, the need to build custom components containing the RAM (Reg) registry keys and to disable FBEReg.dll COM registration in the EWF component resources. Additionally there is new functionality available, such as turning of background disk defragmentation to avoid the overflow of RAM overlays.
While building such a configuration, not including system restore, not using a page file as well as fine tuning the write access of the NTFS file system could be added as best practices.
Even HORM can be activated in the EWF component now, saving a lot of manual work on the way to generate the “Golden Image” that can be cloned on the target devices.
|
HORM - Hibernate Once Resume Many
|
|---|
|
Enables a robust boot scenario using a one-time created hibernation file from which the system always boots.
This enables the creation of fast (below 10 seconds are possible!) booting as well as robust devices. Even after power failures these systems come up quick and without damages to the file system (well, it is protected).
HORM requires RAM or RAM (Reg) overlay and can only be configured using EWF. Disk overlay is not possible because the state once persisted in the hibernation file must not get out of sync with the state on the protected partition.
|
Due to the fact that EWF and HORM are tightly related, both now can be managed by the EWF manager command-line utility using the ActivateHORM or DeactivateHorm commands. These changes are also reflected in the new version of the EWF API that enables access to the same functionality as the command-line utility for applications.
File Based Write Filter
The File Based Write Filter acts as a filter driver above the file system driver and therefore has much more capabilities handling files than the sector-based EWF ever had. It uses RAM / RAM (REG) as its only two overlay modes and does not require a special FBWF partition.
From a user mode application’s perspective, the driver running in kernel mode is completely transparent, meaning that no application needs to be aware that it uses FBWF, at any time.
FBWF itself distinguishes two different persistence scenarios: One is “Selective Write Through”, which persists changes of a selected file immediately and transparently to the protected volume and the other is “Selective Commit and Restore”, which commits a file from the overlay to the protected volume. The later, of course, must be initiated somehow, either by an application itself (via the FBWF API) or via the FBWF command-line utility called manually or by script.
Doing a “Selective Restore” means to reestablish the version from the protected volume into the overlay.
And unfortunately, there are some things that can create problems, for example if the application moves files from a protected to an unprotected volume or if the application generates an overflow in the RAM overlay, that might very well come unexpected. These things result in error states that need to be handled.
From a security perspective, applications developers should also be aware that files in the overlay are not encrypted. Additionally, does FBWF only work on NTFS and FAT32. FAT16, FAT12, or Flash file systems are not supported. It is also only able to protect already formatted volumes. Unformatted volumes cannot be detected.
However, the most interesting feature of FBWF is the ability to commit files or directories through the running filter without restarting it or having an eye on the file size as with EWF. This works fine with files that have already been existing before turning on FBWF is turned on, but one has to be aware that committing new or deleted files may cause errors!
To add FBWF functionality, one has to add the File Based Write Filter component to the XP embedded image. Then FBWF can be configured via the component property pages as shown in the following figure.
Figure 2. FBWF component properties
The component settings allow to, turn on/off FBWF after FBA, and choose the type of a dynamically growing or fixed overlay, while also specifying a maximum boundary for the RAM overlay. OS developers then can opt to enable the write protection best practices already mentioned for EWF and of course are able to select which files and/or directories should be protected on which drives.
To configure more than one volume, just specify the intended number of protected volumes and the required property pages will become accessible via the prev/next buttons at the bottom of the page.
In addition to this design-time configuration approach, the selective write through settings can be altered via the FBWF Manager command-line utility and the FBWF API directly from an application.
FBWF manager as well as the API offers access to the following functionalities:
-
Disabling/enabling File Based Write Filtering
-
Setting/querying cache memory usage
-
Setting/querying compression usage
-
Enable/disable write filtering for an entire volume
-
Excluding a file or directory from write filtering.
-
Committing/restoring cache contents to or from the actual file
Figure 3. FBWF Manager command help
While running, FBWF tries to optimize its cache by freeing memory, for example if files get deleted or shrink in size.