locked
Standard 7 EWF versus XPE EWF Issue RRS feed

  • Question

  • I have a requirement to perform a CRC upon the OS drive of my Embedded OS.

    Reading the physical disk, we verfiy the OS disk is the same between boots via a HASH routine using a Key located upon a serially connected device.

    This application works fine in XP Embedded with the OS disk formatted in FAT32 using the EWF. After we finish an image, I could turn on the EWF and record the HASH signature and then forward upon each boot the application performs the HAS and it will be the same every boot every time without issue.

    Under WES7, I am unable to get this to work. After extensive testing here I have found the following.

    It appears that something is often making a disk write to WES7 while the EWF is turned on. I could well be writing to the raw disk space unformated and not the logical drive protected itself. But, something is writing to the physical disk.

    I can boot and for period of time sometimes 3-5 minutes perform the HASH over the OS disk with the EWF on and I will get the same HASH value informing me that the disk has not changed. Then, for whatever reason with the box sitting idle the next check will fail due to a write having been made in the interim during the idle state.

    Question(s):

    1) WES7 doesn't support read-only boot media such as CD-ROMS where XPe did. Is this because WES7 must make writes to the disk as mentioned above even in the EWF on state in order to operate?

    2) I have gathered WES7 doesn't support FAT32 format, only  NTFS, is it inherently reqquired that NTFS make journaling writes behind the scences to the OS disk?

    3) If this is something that can be easily solved via some setting or registry edits it has eluded us here thus far

    Any help is much appreciated.

    We are dealing with an industry requirement for the OS verification and would like to upgrade from XPe to WES7 - thanks

    Monday, October 1, 2012 7:40 PM

Answers

  • Alright,

    This only took 1 week of serious real working here.

    Thanks to all for help with this issue. Each comment was much appreciated and contributed to the solution

    Here is how to pass a CRC verification upon your SSD boot drive that is running your WES7 image.

    1) Delete BootStat.dat from the C:\Windows directory

    2) Delete the hidden copy of  BootStat.dat that resides upon the C:\BOOT folder, inside the "FONTS" folder

    Make sure your build settings are:

    3) EWF RAM mode (RAM Reg will not work)

    4) ProtectBCDPartition = True

    5) RegistryFilter = NONE, you can't allow anything to be written to the registry period.

    6) BitLocker - OFF (Must be off)

    All indications are the above mentioned NTFS versus FAT32 issue has been solved by the Windows Embedded development team as nothing is being written to disk with the above settings.



    • Marked as answer by .NetRebel Monday, October 15, 2012 6:55 PM
    • Edited by .NetRebel Monday, October 15, 2012 7:04 PM
    Monday, October 15, 2012 6:55 PM

All replies

  • To answer your questions:

      • WES7 is too big to fit on a CD-ROM, and it would be too slow to boot for most applications.
      • FATvs.NTFS - correct WES7 can only boot from NTFS partition.

    Try removing the bootstat.dat file from the image before you do the hash check. This file is being written too on every boot before EWF has loaded. It can be found in c:\Windows, but it might be in another location. If the file is missing, Windows will ignore the operation to write to the file. The validation check should work.                  

    -Sean


    www.annabooks.com / www.seanliming.com / Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

    Monday, October 1, 2012 8:40 PM
  • Thanks Sean,

    I have previously tried the removal of the bootstat.dat file and with it removed I am still getting something changing my OS disk.

    Did a complete search to make sure I did in fact have it deleted before turning on the EWF. Tested this several times.

    We are reading the physical disk below the write filter and and checking it byte by byte and are able to detect a change.

    Currently, we are working upon a test project to CRC every file on a EWF protected image and are going to do a compare upon reboot as to what if anything has changedon any file to identify the change. This will hopefully tell us if it is a file change in the OS or something being written the unpartitioned part of the physical disk possibly by the OS we are guessing, wondering, thinking

    Appreciate the information on the CD/DVD option, we were just wondering if no READ-ONLY disk boot support might somehow be tied to this issue

    The first thing I did here after finding the issue was buy a EMPhase S3 Sata Flash disk with a write protection switch to try and boot that way. (The easy way out was the plan), but no luck with booting while the write protect switch was on. 

    Monday, October 1, 2012 9:06 PM
  • hm...  is Last Access Time Stamps at least disabled?

    http://msdn.microsoft.com/en-us/library/ms940846(v=winembedded.5).aspx

    Maybe it will help if you bcdedit /deletevalue the custom elements:
    http://www.geoffchappell.com/notes/windows/boot/bsd.htm

    btw: I really credit this guy very damn much!


    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

    Monday, October 1, 2012 9:47 PM
  • Much Thanks for this information

    I can say we have not tried either of these points and this is new ground to explore

    I am going to spend the day on this tommorow (again) and will update after I try both of these

    Monday, October 1, 2012 9:52 PM
  • Update on this issue,

    I triple checked the bootstat.dat file and it is not on the image anywhere. We did delete it before enabling EWF and the issue is still present but no bootstat.dat is present upon the sealed image. After reviewing the above link, I realized it was a method of altering the write state of bootstat.dat and thus deleting the file was something tried before.

    The additional suggestion of Last Access Time Stamps, I checked this and it was disabled in the image also.

    Working upon related tests here and will update 

    Tuesday, October 2, 2012 3:45 PM
  • Update on this issue,

    We are working to complete today a test app to check all the files upon the WES7 OS image, record the data to an external data drive, and then between boots while the EWF is on. The app will enable a file compare to see what if any file has changed.

    A related note, we have received information that an alternative method of performing a file validation check works with the above mentioned bootstat.dat file removed. Based upon this we are looking at going this alternative way for issue resolution.

    As mentioned, we previously read the physical disk byte by byte and were able to confirm under XP Embedded nothing upon the disk changed.

    We have generally been told this method doesn't work under WES7. For reasons unknown at this time, but it appears something is being written to the reserved raw unformatted space allocated with an install of WES7. Working here to try and confirm this and will update.

    Regarding the alternative acceptable method that can be used. 

    In this method of file verfication, the PC is booted to a temporary read-only drive C:. This drive simply runs a file verfication app. The App checks all the files upon a target boot WES7 drive D: Upon verifying the files haven't changed upon the target boot drive D:(WES7), the app exits upon C: and initiates the boot of WES7 upon drive D: with the EWF on.

    The difference here is that the OS files upon D: are verified, but the raw unformatted disk space reserved by the install of WES7 are not checked in the byte by byte manner we were currently doing.

    A new challenge will be how to initiate a boot of WES7 upon D: by an App at exit, upon a temporary initial drive as mentioned above. Should anyone reading this have any information upon how to script this or any insight, please do share.

    I will update this as progress is made.


    • Edited by .NetRebel Monday, October 8, 2012 12:10 PM
    Monday, October 8, 2012 12:06 PM
  • Update on this issue,

    I  have found part of my issue. I was using a win app tool to enable/disable the EWF of my single drive for testing.

    I  found where the "System Reserved" partition was defaulted to EWF disabled, while I was enabled on my  "C:" partition correctly.

    Enabling both partitions ofcourse is required, I did so and I am now able to run my HASH calculation which reads the physical disk and obtain the same HASH value several times while the image is running.

    To be clear, I boot. I run and get a HASH. I can drag files around,  go online, test the EWF in every way, then run the HASH and get the same value.

    The problem now is isolated to after a reboot. Upon reboot, I am getting data written somewhere to the physical disk.

    I get a new HASH value between each boot of the system. That HASH will stay the same during that interval the PC is running,but upon shutdown and reboot I get a new value.

    Possibly, I now feel like I have possibly a much simpler issue to address where for some reason my EWF is making a commit of the EWF data to the protected volume between reboots. Or alternatively, something is just writing to the protected volumes at boot.

    I did remove the bootstat.dat file mentioned above and it is not upon the system.

    Next, going to try and find anything that could be written to the protected volume at shutdown or boot and try to eliminate that.

    Wednesday, October 10, 2012 11:46 PM
  • Update,

    I  ran a 12 hour test last night and was able to get the same HASH during the entire interval before shutdown.

    The prior problem I had regarding periodic writes during operation has beeen solved with the above fix whereby I was not EWF enabled upon the system created "System Reserved" partition.

    Seems the issue is strightly with reboot/shutdown.

    It is acting like my EWF data is being committed to the protected volume with every reboot. I used the -enable command on the EWFMGR, I am trying to ascertain is the -enable command inherently performs a commit of EWF data upon every reboot. If it does then this is my problem.

    Originally, I thought this was an issue inherit to NTFS maybe versus FAT32. I dont think that is the case now and we are looking at more typical configuration issues that could be related to data being written at boot or shutdown.

    Thursday, October 11, 2012 1:51 PM
  • Still working, but cant't getover the issue yet.

    Current test configuration here has ruled out many sources of disk writes.

    Using EWF RAM mode eliminates previous writes to the registry

    Deleted  BootStat.dat

    EWF enabled for both "System Reserved" partition and "C:" partition both

    I believe at this point the issue may be related to this infor I found regarding NTFS

    NTFS versus FAT

    When thinking about security, NTFS is an easy choice. The only occasion where FAT is an option, is when using Compact Flash as storage in combination with the Enhanced Write Filter (EWF). In this case the journal for an NTFS partition resides outside of the partition itself. This means that EWF will not be able to redirect writes to the journal into an overlay because it protects the partition only. Therefore these journal writes hit the flash storage. The good thing is that modern flash devices use techniques such as wear-leveling to significantly increase the impact of write cycles for this storage and make failures related to journal writes very unlikely. Devices using FAT file system in this scenario do not have a problem, because it does not write a journal at all.

    Friday, October 12, 2012 11:00 PM
  • Alright,

    This only took 1 week of serious real working here.

    Thanks to all for help with this issue. Each comment was much appreciated and contributed to the solution

    Here is how to pass a CRC verification upon your SSD boot drive that is running your WES7 image.

    1) Delete BootStat.dat from the C:\Windows directory

    2) Delete the hidden copy of  BootStat.dat that resides upon the C:\BOOT folder, inside the "FONTS" folder

    Make sure your build settings are:

    3) EWF RAM mode (RAM Reg will not work)

    4) ProtectBCDPartition = True

    5) RegistryFilter = NONE, you can't allow anything to be written to the registry period.

    6) BitLocker - OFF (Must be off)

    All indications are the above mentioned NTFS versus FAT32 issue has been solved by the Windows Embedded development team as nothing is being written to disk with the above settings.



    • Marked as answer by .NetRebel Monday, October 15, 2012 6:55 PM
    • Edited by .NetRebel Monday, October 15, 2012 7:04 PM
    Monday, October 15, 2012 6:55 PM
  • ProtectBCDPartition = True is not needed if you are not using BitLocker.

    -Sean


    www.annabooks.com / www.seanliming.com / Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

    Monday, October 15, 2012 7:40 PM
  • Thanks - I actually was wondering on that one

    My answer file validation didn't flag it so I just left it that way

    Appreciate all the help

    Monday, October 15, 2012 9:30 PM
  • I know it's been a while on this, but I've found this article incredibly helpful as I'm trying to accomplish something similar.  Thanks for providing your progress and though process; that short circuited a lot of my thinking.

    I was wondering two things:

    1) what software were you using to generate the checksum/hash/crc of the hard disk?

    2) did you come to understand why EWF RAMReg mode does not work, but RAM mode does?

    Thanks again to you, Sean, and Knarz for your efforts!

    Erik


    Erik

    Friday, August 23, 2013 5:22 PM
  • Hi, I'm also curious about the software you use to generate the checksum/hash/crc of the hard disk.
    Tuesday, December 10, 2019 4:13 PM