Encryption and Filters between WM2003 and WM5

Posted by: Sue Loh


It seems that a common need people have is to encrypt all the data on a device, or as much as they can.  I've seen some confusion over whether it's possible at all, how to do it, and what's different between WM2003 and WM5.  Really this answer isn't very specific to encryption.


As you know, in WM2003 we had the object store, and there was no way to put a filter on it.  So OEMs developed solutions that used hacks to encrypt the object store.  They figured out where in RAM the object store lived, and saved/restored an encrypted version of it from some other storage.  ISVs didn’t have that option (unless maybe if they were super hackers) but some ISVs did stuff like mount a file system driver (NOT a filter) where all the data on that file system was encrypted.  In this case the solution was, “don’t use the object store for anything you want to protect.” 


In WM5 there is no object store and it’s possible to mount a filter on the persistent store, BUT filters have to be specified in the registry at the time the persistent store is mounted, and the persistent store is mounted during boot before the full system registry is loaded, so as a result the filters have to be specified in the “ROM hive,” the static mini-registry that’s used to bootstrap the full system.  So – and it pains me to say this – ISVs still can’t put a filter driver on top of the persistent store.  L  OEMs now have the option, but ISVs do not.


So, in summary:

  • WM2003 OEM: with hacks they could encrypt the object store, with a filter they can encrypt removable storage

  • WM2003 ISV: filter drivers can encrypt removable storage, and a file system driver can mount a new encrypted directory that’s only a subset of the file system

  • WM5 OEM: with a filter driver they could encrypt everything

  • WM5 ISV: same as WM2003

I sure hope we can come up with a better ISV solution for this in the future, but perhaps you can understand the difficulty.  We would either have to make a way to delay-load a filter after a file system driver is already mounted (which is really tough, especially if there are already file handles open) or somehow know about the filter before the persistent store is mounted (at which point -- where would you store that information??).  It's a chicken-and-egg problem, and I wouldn't count on it being solved anytime soon.


Comments (13)

  1. Garry Trinder says:


    Why not create a special folder named Encrypted?

    Any files and folders stored under there will be encrypted on the device. Any access to files and folders in Encrypted will force the user to enter a password.

    Either the user or ISV’s could use it.



  2. ce_base says:

    Thanks, Steve. That’s a great suggestion.

    An ISV could implement a custom Auto-Load File System Driver to encrypt data and mount it as a folder off the root directory. This wouldn’t technically filter the root file system, but is likely a very workable solution.

    For details on mounting Auto-Load file systems, take a look at my post on file system registry settings:


    This method will work on both WM2003 and WM5.


  3. Matthew says:

    Andrew, perhaps you mean it SHOULD work on both PPC2003 and WM5.

    Loading a file system driver on WM5 is a bit more complicated than on PPC2003. So far we have been unable to get that little part of the solution working.

  4. jz says:

    Sue, great article!

    I do can do filtering for object store and for installable filesys on 2003/2005. For object store, through hacking, did it at API level (before filesys makes the decision what FILE API to use: FSMGR API or kernel direct file API). This is not the perfect solution I want.  For encryption purpose, filter driver level hooking is acceptable, even though not perfect. You see, for object store, the hooking I have is even above the filtering driver level.  Really want to change it.

    Could you please give us more detail explanation for the following sensences?

    " BUT filters have to be specified in the registry at the time the persistent store is mounted, and the persistent store is mounted during boot before the full system registry is loaded"

    Would you mind telling us (1) "the name of the mounted persistent store" and (2) the block device driver name  for the "persistent store"

    Appreciate it!

  5. jz says:

    …I mean for ISV

  6. ce_base says:

    For WM5 devices, persistent storage is mounted as the root file system in place of the ObjectStore, so it actually has no mount name. The name of the block driver backing persistent storage is dependent on the particular device because the OEM controls this component.

    However, having this information is still not going to help an ISV install a filter on the root file system. It is a bit of a chicken-and-egg problem: you need the root file system mounted in order to read the full registry, and you need the full registry in order to read modified settings when mounting the root file system. Same goes for the filter DLL: if it isn’t in ROM, then we need to mount the root file system to get at it.


  7. jz says:

    Andrew, thanks for your answer.

    IF (big IF) AFTER mounting & booting, the object store is NOT different from other installable file system(store). Then it should not be that hard to hook it! (for 2003, the object store/RAM file system is totally different from normal installable file system, as you know)

    I know, normal filter dll is loaded during booting process. But it’s not that hard to add a new filter dll AFTER booting on demand(by hacking the data structure created by filesys inside filesys.exe, essentially insert a new one into the hooking chain). So if object store (after booting) is NOT treated differently, then this scheme should work too, even though you can not hook it from time 0.

    I still suspect that the object store is treated very differently after mounting? is that true? unfortunately, i am almost blind as far as WM5 is concerned: no kernel debugger like PB’s

    Just one more question directly related to your answer: even though the backing block driver is provided/controled by OEM, HOW does filesys.exe to find it’s name? I guess the emulator (WM5) is controled by you guys :), would you mind telling us about this case?

    Appreciate it!

    How does

  8. Igor Shakhov says:


    How can I load my filter after booting process?

    jz, you say "by hacking the data structure created by filesys inside filesys.exe, essentially insert a new one into the hooking chain", but how can I do it?

  9. ce_base says:

    WM5 provides no mechanism to post-load a file system filter driver on a file system that is currently mounted. It would be dangerous to hack a new filter driver into the chain because you’ll have to deal with file handles that were opened prior to installation of the filter. That doesn’t mean it can’t be done, but it is definitely not supported or suggested.

    Your best bet for determining the block driver backing the root file system is to use the CeGetVolumeInfo API:


    Pass "" as the volume name, and it will return to you the storage device and partition names in the output CE_VOLUME_INFO structure.


  10. jz says:


    thank you very much for your info! i was wondering who is using the RAMDISK! it’s the object store! "Flash Disk" 🙂 Also, i guess the replication filter is trying to persistent stuffs.

    Igor, Andrew is right. Unless you want to filter object store, there is no other reason to do this kind of hacking. It’s dangerous and not for faint of heart. It is very painful to make it right, and it can not be explained in a short comment. Stay with the flow is always safer, is it?

  11. Igor Shakhov says:

    Yes it is, but I just want to filter object store.

    This task is very a urgent for me now. But solving of this problem I not yet find.

  12. ce_base says:

    I just want to post a quick clarification because there seems to be confusion over "ObjectStore" versus "Persistent Storage:"

    The ObjectStore is the root file system on Windows Mobile 2003 (and earlier) PocketPCs. The ObjectStore is a large chunk of RAM set-aside for storage. The RAM is battery-backed, so it appears to persist until your battery dies. There is no Microsoft supported way of filtering the ObjectStore file system. There may be 3rd party solutions.

    There is no ObjectStore on WM5 devices. Instead, these devices mount persistent storage as the root file system. Because of this change, battery-backed RAM is no longer necessary and your data will persist even after your battery dies. The only Microsoft supported way to filter persistent storage is by using an in-ROM file system filter, which cannot be installed by an ISV. Again, there may be 3rd party solutions.


  13. Igor Shakhov says:

    Thanks, Andrew. Your clarification is very helpful.

    I just would to filter object store on WM5 devices. And the thought struck me that somebody here to prompt me any solution of this task.

    For previous your post I have question.

    For using CeGetVolumeInfo I must inslude storemgr.h to my project and link storeapi.lib with it. But this library did not found on my hard disk though I have installed wm5 SDK and wm2003 SDK. May be this library provided with Platform Builder?

Skip to main content