none
64-bit runtime, EWF and NTFS RRS feed

  • Question

  • With XP Embedded, it was always better to use EWF with FAT partitions, due to the presence of NTFS meta data. I guess with NTFS partitions, metadata was not protected by EWF and a power failure could have caused a disk corruption. If the same problem is applicable to WES 7, what file system do we choose for disk partitions for 64-bit runtime when using EWF?
    bg
    Thursday, April 22, 2010 4:21 PM

Answers

  • Hi Boby

    By NTFS meta data,  are you referring to NTFS $ files ($logfile, $Mft etc) ? If yes, I can confirm that EWF has always filtered these and do the same on WES 7 as well.  EWF is a storage volume filter that sits below the file system and will intercept all I/O generated by the file system.

    EWF + NTFS is still the best bet against power loss.

    If you believe you got this information from a Microsoft blog post or MSDN article , please let me know , it would need to be corrected.

    Thanks

    Srikanth

    PS: On the contrary, FBWF will not filter I/O NTFS $ files.


    Srikanth Kamath [MSFT] - This posting is provided "As Is" with no warranties, and confers no rights.
    • Marked as answer by Boby George Friday, April 30, 2010 10:34 PM
    Friday, April 30, 2010 3:32 PM

All replies

  • Hi Boby

    By NTFS meta data,  are you referring to NTFS $ files ($logfile, $Mft etc) ? If yes, I can confirm that EWF has always filtered these and do the same on WES 7 as well.  EWF is a storage volume filter that sits below the file system and will intercept all I/O generated by the file system.

    EWF + NTFS is still the best bet against power loss.

    If you believe you got this information from a Microsoft blog post or MSDN article , please let me know , it would need to be corrected.

    Thanks

    Srikanth

    PS: On the contrary, FBWF will not filter I/O NTFS $ files.


    Srikanth Kamath [MSFT] - This posting is provided "As Is" with no warranties, and confers no rights.
    • Marked as answer by Boby George Friday, April 30, 2010 10:34 PM
    Friday, April 30, 2010 3:32 PM
  • Thank you Srikanth. I did mean somewhere along the line of MFT and such. I cannot clearly remember where I read about EWF and NTFS being a non-preferred option. Thanks for the clear explanation.
    bg
    Friday, April 30, 2010 10:34 PM
  • Wait a minute! EWF doesn't protect the meta data section. A report was sent back in 2004 that showed information was getting through. Are you saying this was fixed?

    -Sean

     


    www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for .NET Step-by-Step
    Saturday, May 1, 2010 12:26 AM
    Moderator
  • Sean -

    There's a simple way to see whether EWF can filter NTFS $ files. Both Perfmon.exe and Resource monitor show I/O to NTFS $ files. When EWF is turned on, all I/O including those to NTFS $ files disappear (since perfmon reporting is done via sector level filter). So it is quite evident that EWF filters NTFS $ files.

    Further, the file system does not write to the storage volume before all the filters (such as EWF, Bitlocker etc)  are instantiated and ready to filter I/O. This guarantee is provided by the file system. So there's no design level issue with EWF that prevents it from filtering NTFS $ files.

    That said, I recollect reading the report you are pointing out. IIRC, it claims that offline comparison revealed changes to $MFT.  Currently, we are not aware of any bugs in EWF during shutdown or startup that leaks writes down to the disk. I am interested in revisiting this case if you wish. Please let me know.


    Srikanth Kamath [MSFT] - This posting is provided "As Is" with no warranties, and confers no rights.
    Saturday, May 1, 2010 4:30 PM
  • It wasn't the simple way that caught me off guard when this was found. Are you saying this is fixed now?

    The test will be to use the forensic software:

    1. Install the image on the system with EWF RAM overlay enabled.
    2. Do a binary capture of the drive
    3. Boot back into the image and perform different operations - go to websites, log into RDP, etc.
    4. Do another binary capture
    5. Compare the captures and there should be no differences

    -Sean

     


    www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for .NET Step-by-Step
    Sunday, May 2, 2010 5:10 PM
    Moderator
  • Hi,

    Has the issue of EWF not filtering all writes on a NTFS partition fixed in WES7?

    --Krishnan

    Tuesday, December 4, 2012 6:23 PM
  • No. It has not been fixed.

    -Sean


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

    Tuesday, December 4, 2012 6:49 PM
    Moderator
  • @Sean

    Yes, its not fixed. I tested by doing a MD5 for the whole disk which had a single NTFS partition with EWF on it. The signature changes after every reboot, I was wondering is there a way to redirect the NTFS meta data to a different disk. That way my OS disk signature will not change every power cycle.

    --Krishnan

    Monday, December 10, 2012 1:45 PM
  • There is no way to move the meta-data. It is part of the NTFS architecture.

    Out of curiosity, try removing all instances of bootstat.dat file and re-test.

    -Sean


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

    Monday, December 10, 2012 5:03 PM
    Moderator
  • @Sean,

    I tested it by removing all instances of bootstat.dat file, there were in total two files (C:\Boot and C:\Windows). In preliminary testing the signature for the boot partition did not change after power cycle but signature of disk did change. I don't know why the signature of whole disk would change; I have a RAM-Reg EWF.

    I am testing it more to be sure about the above results, will keep you posted.

    And thanks for the pointer and the wonderful WES7 book.

    -- Krishnan

    Monday, December 10, 2012 6:26 PM
  • Please read: http://social.msdn.microsoft.com/Forums/en-US/quebeceefs/thread/f50c454b-1ebf-4b0b-92a0-5458ff46e68e

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

    Monday, December 10, 2012 7:04 PM
  • Thanks KNARZ and Sean.

    I experimented with various combinations, before getting into let me briefly explain the setup that I have with me:

    4 GB SD Card - Has single partition, with no un-partitioned space meant for the OS

    8 GB SD Card - Has two partitions (2 GB and 4 GB), rest un-partitioned.

    In my answer file I had EWF (RAM-Reg), after first boot and turning EWF ON I pulled the chip and deleted bootstat.dat from C:\Windows and C:\Boot folders. Put the chip back and power cycled, one thing I forgot to mention in 8GB the partitions are both NTFS. The signature for 4 GB does not change across the power cycles, but signature for 8 GB changed.

    On investigating further this change was happening within the partitioned area of drive in 8GB card which had NTFS file system. Though I could not detect any visible change in windows disk explorer, in order to solve this I re-created partitions in 8 GB to be FAT32.

    This fixes it, now the signature on both the drives do not change across power cycles.

    Earlier I had also tried using EWF(RAM) and it also gives the same result as EWF(RAM-Reg). I performed following tests to be sure that signatures do not change:

    a) Create a file in my C: drive which had EWF turned on.

    b) Deleted a file in my C: drive which had EWF turned on.

    c) Modified a file in my C: drive which had EWF turned on. 

    d) Create a key in registry.

    e) Deleted a key in registry.

    f) Modified a key in registry.

    After each of the above test I checked the signatures and it did not change for both the disks across power cycles. Now, I am left with one test to do that is to be sure that nothing is ever written to the un-partitioned space by the OS.

    Thanks for all the help. 

    Friday, December 14, 2012 3:44 PM