Updating the system through the EWF

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

My XPe device has its disk partitioned into C, D and E drives for OS,
application, and data respectively. C and D are protected by the EWF using a
RAM overlay. The development of my build is in its final stages, I just have
to figure out how I am going to manage updates.

I intend to use SMS to distribute and deploy updates to my device in the
future. The only problem is I can't figure out an easy way to do this with
the EWF in place.

The MS official line (taken from
http://msdn.microsoft.com/library/d...allingupdatesonewf-protectedrun-timeimage.asp)
is to disable the EWF, reboot, apply updates, enable the EWF then reboot
again. This is fine if you are stood there in front of the device, but it is
very hard to manage using SMS! My enterprise will contain 3000 of these
devices so manual updates are not an option.

The other obvious way would be to simply apply the updates then commit the
RAM overlay to disk. This would be my preferred solution as I could build one
simple package which does this. My package could easily be distributed and
applied with SMS. The problem is that any other data sat on the overlay would
get committed to the disk as well. I really don't want this! What if there is
a virus or other rogue data sat on the overlay?

The answer would be to clear the RAM overlay before I applied the SMS
package. I could do this by simply rebooting the device, but then I would
have to get apply the SMS package straight away afterwards to minimise the
chance of rogue data getting onto the overlay.

A better solution (and this is the main point of my post here!) would be to
clear the RAM overlay using the ewfmgr command, but the command can't do what
seems to me to be an obvious task. If I could clear the RAM overlay using
ewfmgr I could build this command into my SMS package; it would be simply
clear overlay, make updates, commit overlay. Simple!
 
Hi!

We are facing a similar issue. We have almost the same architecture
you described. At this point, we have an agent of the target device
retrieve the update from the central server, then it will reboot, apply
the update, commit that changes, then reboot again. It's not elegant
nor is it convienent for devices/customers in the field but it's the
only reliable way that we've been able to accompish this.

It would be great if MS of someone could come up with a utility to
clear any changes in the RAM overlay since last boot!! Then we could
apply an update, commit and reboot only once.

PJC
 
The XPe image I use is very slim, I have have removed many useful components
such as explorer, script host, etc. It runs a custom shell which launches a
GUI application, which provides the functionality of the device. The purpose
of this slim image (and the EWF) is for security, my devices are in public
areas and are used by the public, I don't want any whizz-kids coming along
and doing things on there they aren't supposed to.

The fact that the custom shell is the only thing to run means that I can't
get the device to run anything else on startup. It isn't possible to use an
SMS package to reconfigure the shell application so that it runs an update,
enables the EWF then reboots. The reason I can't do it is that the SMS
package would need to commit the changes to the shell through the EWF before
it reboots. This takes us back to the same problem as before; I don't want to
commit as I the overlay may be 'dirty'.

I suppose I could get my shell to, on booting, check for an update in a
specific position on the writeable partition. If it found such an update then
it could apply it, then enable the EWF, then reboot. Then I would just need
my SMS update to put the necessary files on the writable partition, disable
the EWF then reboot. Its a big work though.
 
Hi PJC. Unfortunately, EWF doesn't work that way - the overlay literally
stores all write activity that would otherwise go to the protected
partition, which includes open file handles and other things that the OS
requires in order to function properly. There isn't a way to clear that
data out of the overlay without shutting down the system.

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Hi Neil,

Like Matt said. There is no way to purge overlay data since those data represent pieces of open filesystem changes in memory. Just
purging them would mean that you might end-up with open file that do not exist anymore or pieces of registry would be gone.

In theory there is a way to expand EWF functionality so that you can access physical data trough virtual volume Z: for instance. By
creating tunnel directly to physical closed FS on disk and avoiding EWF.
Each sector changed in that way would have to be first cached in EWF overlay before it is physically changed. That would allow data
consistency in working windows and by doing that disk data + updated overlay would contain uncompromised data of currently working
system. And on disk you count do all changes necessary. After that you would need to close tunnel and reboot computer.

This option would be fairly complex to make and I guess that interest for it is very low.

Regards,
Slobodan
 
Back
Top