EWF question

[Gereon]

Our deployed image is on a hard disk. It is very important in our product
that the system runs precisely the same image each time, unless we
explicitly tell the system to do otherwise (such as when doing a software
upgrade). In effect, I want to throw the latest overlay of changes away on
every reboot.

In my experiments, it seems like the default in DISK mode is to keep using
the overlay after a reboot (thus running with changes made before the last
reboot), until I tell it to roll back the overlay (and reboot so that the
rollback can occur).

Does that mean my only option is to use EWF in RAM mode? Instead, can I use
DISK mode and set it to discard the overlay on every startup (unless I
explicitly tell it to commit them?)

 

[Slobodan Brcin \(eMVP\)]

Hi Gereon,

Yes you can tell during the each boot that overlay data should be discarded in next boot.

Regards,
Slobodan
PS: Look at product doc for EWF

 

[Gereon]

After looking at the product docs, the method I see for doing this would be
to run

"ewfmgr -all -setlevel=0" (or equivalent) at some point every time the
target started up.

If that is the solution you are referring to, wouldn't there be a window of
opportunity if the machine starts running, discards the overlays so it runs
from the original image, makes changes to an overlay as boot continues, then
resets before the next call to ewfmgr can take place? On the next boot,
wouldn't it use the overlay because the flag didn't get set?

 

[KM]

Gereon,

"ewfmgr -all -setlevel=0" (or equivalent) at some point every time the target started up.

The command you would probably be interested in is "ewfmgr -setlevel=-1" (or just "ewfmgr -restore").

If that is the solution you are referring to, wouldn't there be a window of opportunity if the machine starts running, discards
the overlays so it runs from the original image,

It will discard all the chnages you have made in the current overlay since previous ewfmgr -setlevel=-1 command.
It does not run from original image, per say. It clears up all the changes you made in the current overlay.

makes changes to an overlay as boot continues, then resets before the next call to ewfmgr can take place?

But you do "the next call to ewfmgr" on next boot, right? Therefore you won't miss it becuase of sudden shutdown if it is your
concern.

On the next boot, wouldn't it use the overlay because the flag didn't get set?

It will always use the overlay. You responsibility will be to clean up the changes in this overlay on each boot.

KM

 

[Gereon]

Hi KM,
I understand (now) that I should not say that it ever runs "from the
original image". Instead, it runs from the overlay, which happens to have
been "cleaned up".

My main concern is still that there is a situation out there where a system
will start up and run under the influence of data in an un- cleared overlay.

1. A system starts up clean, from a blank overlay.
2. Modifications occur to the overlay during boot.
3. More modifications occur to the overlay during boot.
4. Later on in the boot process, "ewfmgr -restore" is called.
5. The system runs, then eventually resets.

If a reboot occurs at step 3, won't the system start up using the overlay
with the modifications made at step 2? It won't know to do a restore, since
we never made it to step 4?

 

[KM]

Gereon,

My main concern is still that there is a situation out there where a system will start up and run under the influence of data in
an un- cleared overlay.

1. A system starts up clean, from a blank overlay.
2. Modifications occur to the overlay during boot.
3. More modifications occur to the overlay during boot.
4. Later on in the boot process, "ewfmgr -restore" is called.
5. The system runs, then eventually resets.

If a reboot occurs at step 3, won't the system start up using the overlay with the modifications made at step 2? It won't know to
do a restore, since we never made it to step 4?

Nope. You don't explicitely change the overlay level, do you?
Therefore, regardless of when that sudden restart (shutdown) happended it is also going to call "ewfmgr -restore" on next boot and
thus clean up the overlay.

All the modifiactions in your case go to the same overlay. So as soon as you call "restore" and clean the overlay, you return back
to the original state.

KM

 

[Gereon]

Hi again KM,

I appreciate you taking the time to answer me back, I really do. I think
I'm giving poor examples of what I am concerned about though. So I'll try
again...

1. The system starts up.
2. If a "restore" command is queued, the overlay is cleaned up.
3. During the boot, a driver creates a new file. The changes to the disk
that are required to bring that file into existence go onto the overlay.
4. More modifications occur to the overlay during boot.
5. Later on in the boot process, "ewfmgr -restore" is called, which queues
a request to clean up the overlay on the next reboot.
6. The system runs, then eventually resets.

If the system makes it to step 6, all is well. But if a reset occurs at
step 4, the system reboots, does NOT clean up the overlay, and arrives at
step 3. Now, the driver faces a situation that is different than before:
the file it is supposed to create already exists from the previous (aborted)
boot attempt. Granted, the driver should handle the situation, but that
doesn't change the fact that the system boot process did not progress the
same as all the other times the machine booted.

So with the EWF running in disk mode, could this scenario occur?

 

[Slobodan Brcin \(eMVP\)]

Hi Gereon,

You are right that if you do not execute step 5 you will leave with garbage :-(
User have option to press F8 during the boot and to discard overlay if system can't boot.

Unfortunately you would need to communicate with EWF driver from your driver and to tell it to discard data on reboot. Or since this
is a undocumented flag in EWF partition you can find it in this raw partition and make your driver to change it on its own very
early in boot process and before doing any change on disk.

Anyhow auto-restore option for disk overlay sound as a simple and reasonable feature to request from MS, so please do that.
http://msdn.microsoft.com/embedded/community/community/feedback/feedxp/default.aspx


Regards,
Slobodan

 

[Gereon]

Thanks both of you (Slobodan and KM). I will make a request to Microsoft as
you suggested. Sorry it took so many passes at it for me to describe my
concerns clearly.

A co- worker actually suggested earlier today that we re- set the EWF
partition with our custom BIOS before XPE boots, which is basically what you
were suggesting. So we have a workaround at least.

 

[Slobodan Brcin \(eMVP\)]

A co- worker actually suggested earlier today that we re- set the EWF

partition with our custom BIOS before XPE boots, which is basically what you
were suggesting. So we have a workaround at least.

Actually one byte would suffice that will tell ewf_ntldr what to do.

Regards,
Slobodan

 

[KM]

Ok. Slobodan has already replied to you and I have pretty much nothing to add here.

Only thing is that with an access to raw data of EWF partition it should really be easy to find the offset of the flag.
I've done similar to RAM based overlay.

Or, you can use ewfinit.dll within your driver code to call EwfSetOverlayPartitionType.
From the BIOS it will certainly be easy to operate with raw data. Or the same code can be done within MBR or boot sector code.

KM

 

[Slobodan Brcin \(eMVP\)]

Hi Konstantin,

Or, you can use ewfinit.dll within your driver code to call EwfSetOverlayPartitionType.

FYI: This can't be done since it is win32 dll file that do not mix well (not at all to be precise) with kernel mode drivers.

Regarding the MBR change that would be my preference also, since including this in BIOS sound a little restrictive.

Regards,
Slobodan

 

[KM]

Oh, you are right. I forgot that is a user mode dll :-(

Konstantin

 

[KM]

Oh, you are right. I forgot that is a user mode dll :-(

I meant it calls user-mode code (kernel32.dll I think).

I only wish to know EWF.sys interfaces.

Konstantin

 

[Slobodan Brcin \(eMVP\)]

Hi Konstantin,

I only wish to know EWF.sys interfaces.

Maybe we should make a request for a short IOCTL codes list?

I'm always considering the possible holes that some service driver can introduce to system. But most other things belong to XPP so
millions of developers test them every day.
What about EWF who ever bothered to look how it works internally and if there are risks in using it.

I could easily reverse engineer all IOCTL codes but what would be a point of wasting few days on that.

Regards,
Slobodan

 

[KM]

Slobodan,

Maybe we should make a request for a short IOCTL codes list?

Good idea.

I'm always considering the possible holes that some service driver can introduce to system
But most other things belong to XPP so millions of developers test them every day.
What about EWF who ever bothered to look how it works internally and if there are risks in using it.

I don't use EWF DISK much in my images but Gereon's scenerio is a good test case that may be a good point for the EWF.sys interface
request.
I think whoever deals with drivers more would want to have the interface available and documented.

I could easily reverse engineer all IOCTL codes but what would be a point of wasting few days on that.

Well.. I think getting IOCTLs is not a big problem but reverse engineering [in]/[out] parameters for custom IOCTLs may take a while.
Just a lot of work with debugger.

And you may not be legally able to use/distribute the hack anyway. :-(

Regards,
Konstantin