how to encrypt word document in minifilter?

Hello all,
I am developing a minfilter to encrypt some types of files such as .doc, .ppt. The steps processed by my minifilter(while word document are created in cmd)are listed below.
Step1. Intercepting IRP_CREATE in Pre-Create, get the filename tobe created, and create the file by FltCreateFile, add related file info into a self-defined linked list, then write a 4K header flag into the newly created file, and at last change create option to FILE_OPEN, return FLT_PREOP_SUCCESS_WITH_CALLBACK.
Step2. In PRE_READ and PRE_WRITE process, add 4K(since the flag header is 4K bytes) to the offset; (no encryption algorithm has been added)
Step3. In Pre-QueryInformation and Pre-SetInformation, move offset forward 4K as well.

But when I create a word ducument by cmd line, and then save it to a position, an error message will pop up, “The save failed due to out of memory or disk space”, what may cause this problem?

Any suggestion will be highly appreciated!

penjiu@163.com wrote:

Hello all,
I am developing a minfilter to encrypt some types of files such as .doc, .ppt. The steps processed by my minifilter(while word document are created in cmd)are listed below.
Step1. Intercepting IRP_CREATE in Pre-Create, get the filename tobe created, and create the file by FltCreateFile, add related file info into a self-defined linked list, then write a 4K header flag into the newly created file, and at last change create option to FILE_OPEN, return FLT_PREOP_SUCCESS_WITH_CALLBACK.
Step2. In PRE_READ and PRE_WRITE process, add 4K(since the flag header is 4K bytes) to the offset; (no encryption algorithm has been added)
Step3. In Pre-QueryInformation and Pre-SetInformation, move offset forward 4K as well.

First, for an encryption driver you are starting with a difficult
application to test your design. I would start with something much
simpler such as notepad. There are many things you will need to deal
with and get correct before moving into applications such as Word.

For instance, are you updating the information returned in a directory
query? If I remember correctly, Word actually performs directory
enumerations for the specific file and compares the returned information
from that retrieved through the query file info request.

Good luck. There are tons of threads on this topic in the archives.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Hi, Peter. Thank you very much for your reply. Notepad is easy to process relative to word and I’ve succeeded on it.
I’ll follow your suggestion for word again.
Thanks again for your encourage.

penjiu@163.com wrote:

Hi, Peter. Thank you very much for your reply. Notepad is easy to process relative to word and I’ve succeeded on it.
I’ll follow your suggestion for word again.
Thanks again for your encourage.

The other thing to remember is that when Word saves a document it
doesn’t save the content to the .doc file, it saves it to a series of
tmp files and then performs a rename at the end. So if you are
encrypting solely on file extension, be sure to include these other
intermediary files and the target of renames as well.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Thanks for your patience, Peter.
Do you mean I should encrypt .doc file as well as all of .tmp files? right?
Another issue, in directory control, I just process IRP_MN_QUERY_DIRECTORY, is it right ?

I try to filter FileBothDirInformation in IRP_MJ_DIRECTORY_CONTROL today, but found that the EndOfFile and Allocation size is the real size of the file, not including the header length, is it filtered in some other dispatch before entering Dir-Control dispatch?

penjiu@163.com wrote:

I try to filter FileBothDirInformation in IRP_MJ_DIRECTORY_CONTROL today, but found that the EndOfFile and Allocation size is the real size of the file, not including the header length, is it filtered in some other dispatch before entering Dir-Control dispatch?

FileBothDirInformation is not the only one you will need to fiotler. Put
a bp in the dispatch routine and determine which others are filtered.
There is no other directory enumeration call.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Thanks Peter.
Now I com across another problem(sorry). When I create/open a file in pre-create before file system executing the real create process, then I set the file size and write the header flag(4KB length) into the file, writing is successful. But the cache manager now consider the file size as 4KB, how to hide this header to cache manager.
Because if I don’t hide the flag length, the read/write byte offset will not start from 0, but 4KB(Actually, I don’t know why), and if I increment the header flag length on byte offset again, it will lead to incorrect result.

Need your help.

These are all questions all writers of encryption filters must answer. This
also one reason why some encrypting minifilters use a stream to hold that
information and others use a trailer where the data is located at the end of
file. In order to get that chunk of data into the file, the cache manager
has to know the real size of the file when it is processing paging writes.
To get this correct you have to understand how the file system driver
interacts with the cache manager, how it handles non-cached files, and how
the paging path and non-paging path are different.

wrote in message news:xxxxx@ntfsd…
> Thanks Peter.
> Now I com across another problem(sorry). When I create/open a file in
> pre-create before file system executing the real create process, then I
> set the file size and write the header flag(4KB length) into the file,
> writing is successful. But the cache manager now consider the file size as
> 4KB, how to hide this header to cache manager.
> Because if I don’t hide the flag length, the read/write byte offset will
> not start from 0, but 4KB(Actually, I don’t know why), and if I increment
> the header flag length on byte offset again, it will lead to incorrect
> result.
>
> Need your help.
>

Thanks for reply…
Do you mean that using a header flag is impossible or inproperly?
But as I know, only NTFS has the charactar to hold such info in a stream.

That is why this is so difficult. It is much easier except for the lack of
alternate data streams (ADS) in that the source code for fastfat is
available to assist you in understanding how to do it. This knowledge will
help some for NTFS, but they are different and you might want to consider
having another method for NTFS. Some have used headers and found ways
around the issues, but there are some that cannot be solved except by
implementing a full file system. Look at the OSR kit for data modification.
Having code written by people who have source code access to Windows can
eliminate many problems.

wrote in message news:xxxxx@ntfsd…
> Thanks for reply…
> Do you mean that using a header flag is impossible or inproperly?
> But as I know, only NTFS has the charactar to hold such info in a stream.
>
>

penjiu@163.com wrote:

Thanks for reply…
Do you mean that using a header flag is impossible or inproperly?
But as I know, only NTFS has the charactar to hold such info in a stream.

Getting this correct, whether you use a header or a trailer is difficult
but not impossible. You need to track two sets of sizes, the real size
of the file on disk and the size of the file reported to callers from
user mode. You need to deal with mapping these requests accordingly
because as you indicated you will be retrieving offsets in the IO
pathways, both paging and non-paging, which use the ‘fake’ file size and
this needs to be adjusted to the real file size before passing it down
to the underlying file system.

There are some very difficult cases such as file extension writes where
you need to adjust the size of your file on disk to accommodate the new
data as well as your header. And you need to do this before the paging
IO comes in since you cannot extend a file during paging IO.

There are lots of gotcha’s in writing an encryption filter driver but it
is possible with enough persistence and time.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

So grateful!
As Peter said to track two sets of sizes, I have another question, should I hide the header length to cache manager? Because I really do create file operation and write the header into the file before passing IRP_MJ_CREATE to underlying file system, the underlying file system only opens the tagged file which I have created. So the values of Allocation size and Filesize in FCB structure that constructed by file system have involved the the length of header. As is known, cache manger and file system share this FCB, so cache manager knows the actual file size, which leads to incorrect logic in the following process.?
In my minifilter, I only care about nocahed io and paging io in read/write callbacks, is it right? Should I process cache io or even fast io to fake the file size ? I am confused about this for a few days.

penjiu@163.com wrote:

So grateful!
As Peter said to track two sets of sizes, I have another question, should I hide the header length to cache manager? Because I really do create file operation and write the header into the file before passing IRP_MJ_CREATE to underlying file system, the underlying file system only opens the tagged file which I have created. So the values of Allocation size and Filesize in FCB structure that constructed by file system have involved the the length of header. As is known, cache manger and file system share this FCB, so cache manager knows the actual file size, which leads to incorrect logic in the following process.?
In my minifilter, I only care about nocahed io and paging io in read/write callbacks, is it right? Should I process cache io or even fast io to fake the file size ? I am confused about this for a few days.

You need to report to CM and MM the fake file size so the section
created in the cache reflects the size of file reported to the user.
Hence the data in the cache will NOT contain your header.

You will need to track the cached IO write requests in order to
correctly update the file size in the case for write extension. Since
you cannot update the file size during paging IO, you need to recognize
the case where the file is extended and it needs to accommodate the
length of your header as well.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

To avoid all these complication, we have used stream cipher algorithm. We are using 16 byte block algorithm and for rest of the unaligned bytes we are using stream cipher algorithm. http://en.wikipedia.org/wiki/Stream_cipher

This way you can avoid shadow files, tracking of FileSize and saving the padded data. this technique is working really well for us. Yes the drawback is its little slow to encrypt the last unaligned block, but most of the real time application i.e. DBs, they always write aligned data.

xxxxx@gmail.com wrote:

To avoid all these complication, we have used stream cipher algorithm. We are using 16 byte block algorithm and for rest of the unaligned bytes we are using stream cipher algorithm. http://en.wikipedia.org/wiki/Stream_cipher

This way you can avoid shadow files, tracking of FileSize and saving the padded data. this technique is working really well for us. Yes the drawback is its little slow to encrypt the last unaligned block, but most of the real time application i.e. DBs, they always write aligned data.

Key management becomes more difficult as well without any per file
specific information.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

You give me light, Peter. I’ll try it soon.
Reporting fake size to CC and MM, do you mean that I should change the file size before any read/write operation ? How to report this fake length to CC and MM?

BTW, Peter, you mean that cc doesn’t reference the filesize info in FCB and maintains its own filesize structure, isn’t it ? So we should report filesize info to cc and mm?

“Key management becomes more difficult as well without any per file specific information.
Pete”

I totally agree with that. You need different technology for key management if you don’t have file specific information. In my case, we have our patented Key management software/server, which is huge help. This is reason we are able to eliminate file specific information.

Once a server is introduced to manage critical information, something will become relatively easy, I think.