From: divya on
problem statement:
A driver has to be written such that when
Input to MS-Word open is given as Z:base 32 encoded string
Here, Z: is the drive which is not existing
base 32 encoded string: path to the encrypted file which is to be
opened;key;iv
the driver has to be called and then decode the encoded string, obtain the
path to the file, key and iv from that and with the help of key and iv,
decrypt the encrypted file and open it.Along with that if any modifications
are done to that opened file, they must get reflected ie., changes done to
the file need to be saved. And when the file is closed, again the content in
it should be encrypted.

My Approach:
I am writing a KMDF non pnp driver using WINDDK 6001.18002.
I have given the symbolic name to the driver as Z:. Using
EvtDeviceFileCreate and EvtFileClose callback functions, I am getting the
open requests made by other applications such as winword - "Z:base32 encoded
string". In the EvtDeviceFileCreate callback, I am able to decode that
encoded string. And using some open source crypto apis i.e., OPEN SSL, I
thought of doing decryption of encrypted file. Now, I dont know how to make
word to open this file.
can anybody please help me in this and also tell me if i'm going in a wrong
direction in attempting the problem.






From: Doron Holan [MSFT] on
you want a file system driver, not a WDM/KMDF driver

d

--

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


"divya" <divya(a)discussions.microsoft.com> wrote in message
news:0D01B1ED-6030-467A-B6BD-ED1C7463B922(a)microsoft.com...
> problem statement:
> A driver has to be written such that when
> Input to MS-Word open is given as Z:base 32 encoded string
> Here, Z: is the drive which is not existing
> base 32 encoded string: path to the encrypted file which is to be
> opened;key;iv
> the driver has to be called and then decode the encoded string, obtain the
> path to the file, key and iv from that and with the help of key and iv,
> decrypt the encrypted file and open it.Along with that if any
> modifications
> are done to that opened file, they must get reflected ie., changes done to
> the file need to be saved. And when the file is closed, again the content
> in
> it should be encrypted.
>
> My Approach:
> I am writing a KMDF non pnp driver using WINDDK 6001.18002.
> I have given the symbolic name to the driver as Z:. Using
> EvtDeviceFileCreate and EvtFileClose callback functions, I am getting the
> open requests made by other applications such as winword - "Z:base32
> encoded
> string". In the EvtDeviceFileCreate callback, I am able to decode that
> encoded string. And using some open source crypto apis i.e., OPEN SSL, I
> thought of doing decryption of encrypted file. Now, I dont know how to
> make
> word to open this file.
> can anybody please help me in this and also tell me if i'm going in a
> wrong
> direction in attempting the problem.
>
>
>
>
>
>
From: Eugene Mayevski on

> can anybody please help me in this and also tell me if i'm going in a
> wrong
> direction in attempting the problem.

As said, you need a virtual file system driver. Why not take a ready to use
solution, such as Callback File System ( http://www.eldos.com/cbfs/ ) and
avoid writing your own driver?

--
With best regards,
Eugene Mayevski
http://www.eldos.com/ - security and virtual storage components

From: Rod Widdowson on
What you have described is often referred to as a layered file system. This
is a significant undertaking - it combines the complexity of writing a
filter with the complexity of writing a filter, with the advantage that a
lot of the pain associate with either is replaced by just needed to add
code. Allow about 12 months if you are an experienced driver writer

No matter whether you reflect into user mode or not you should expect to
have some issues with your interaction with Cc Manager. Finding and fixing
these is liable to take up a fair whack of time

There is a k-mode kit out there which is available in source which might
help. But it isn't cheap.


--
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790

From: Maxim S. Shatskih on
> I am writing a KMDF non pnp driver using WINDDK 6001.18002.

You need a FltMgr's minifilter instead.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com