文件加密标识 －OSR经典对白

文件加密标识 －OSR经典对白

");//--><script language="JavaScript" src="http://ads.zndev.com/adjs.php?n=174997347&amp;what=zone:4&amp;exclude=,&amp;referer=http%3A//www.baidu.com/baidu%3Fword%3DOSR%25BE%25AD%25B5%25E4%25B6%25D4%25B0%25D7%26tn%3Dmyie2dg" type="text/javascript"></script>

  第一篇
FS Filter Driver question
________________________________________
Dear NTDev folks,

We are writing a FileSystem Filter Driver, that mangles the contents of
a particular file, such that:
1) the content is Mangled on Write, and
2) Unmangled on Read.

Our Mangling actually increases the size of the file, and we also insert
our own header data in the beginning of the file.

However we still want to present the "correct" file-length to the client
programs (e.g. they shouldn't know that the data is actually mangled
before it's stored in the file).

We have been able to do this, to some degree, by handling the Read/Write
IRPs, and modifying the length fields in the QueryInformation IRPs (for
both File Information, and Directory Listings).

However, we are worried that interactions between the underlying
FileSystem Driver, and the Cache Manager may expose the real length of
the file in some cases (e.g. through the FileSize field in the
FSRTL_FCB_COMMON_HEADER structure stored in the FsContext field of the
FileObject), or cause other problems.  We are not able to find a good
discussion on Data Modifying filter drivers in the IFS kit documentation
or in the "Windows NT File System Internals" Book by Rajeev Nagar.

FileSystem Filter Drivers that do non-length-preserving Encryption or
Compression must face the same issues that we are coming across.  We
would really appreciate it if you folks could shed some light on how the
cache manager may affect FileSystem Filter Drivers that mangle the
content of the file such that the actual file length changes, or if you
could suggest some resources where this information is available.

Re: FS Filter Driver question
________________________________________
Why put the "header" at the beginning?  It is the most difficult place to put it
and maintain any semblance of obfuscation.  Put it at the end and give yourself
enough space to permit expanding it easily.  I would recommend that the last
128, 256, 512, etc bytes be the "header/trailer".  If expansion becomes required
later, you can expand downwards from that fixed part of the header that will let
you know the file is yours.

The following are questions you need to answer before you design your solution:

1.    Can the file be accessed in "mangled" form by any program, at any time? 
Backup?
2.    Can the file be modified by any of the Microsoft Office programs?
3.    Why do you care if one program "knows" the file size if wrong?  What can
be revealed?



Re: FS Filter Driver question
________________________________________
I don't see any problem with FCB's FileSize having bigger value than what
you report through other interfaces.
However, I must agreed with David that having header at the beginning of
the file is not the best solution. The only significant advantage
I can see is that you simplify handling of file expansion (only
considering that header has fixed size). However you gain a lot of
complications
trying to keep the header out of the cache, dealing with
FileObject->CurrentByteOffset for sequential files (these are just from
the top of my head).
So, unless there are particular reasons why you want to have your header
at the beginning of the file, I would suggest to put it at the end or even
strip it completely from the file and keep it somewhere else.

Regards,

Vladimir



Re: FS Filter Driver question
If you're on NTFS you could consider keeping it in an alternate stream in the file.


Re: FS Filter Driver question
________________________________________
Hi David, Vlad, Peter,

Thanks so much for your helpful suggestions.

- We keep the fixed-size header data in the file for our own informational
purpose, and this header is not necessarily related to the content-mangling
algorithm (with which we mangle the actual contents of the file).

- Even if we don't keep the header in the beginning of the file, doesn't the
problem of trying to hide it from the Cache Manager still exist?
(we currently do adjust the FileObject->CurrentByteOffset for certain IRPs to
skip the header, and we keep the header in the beginning for only the reasons
that Vlad mentioned).

- Also, let's assume that we keep no header in the file, our mangling algorithm
still increases the length of the file (similar to an encryption algorithm), if
the Cache Manager is able to read the "increased size" of the file, but then it
is not able to get all the data (because we are un-mangling and giving it the
actual data (which is smaller in size)), will that cause problems?

- The files we mangle can be binaries or data files, e.g. MS Office Programs can
certainly use them as documents, or DLLs. (if our driver is loaded, these files
will be read correctly, if our driver is not loaded, then the file will be seen
as containing garbage data).

- Lastly, we need to be agnostic of File System types (i.e. we can't rely on
NTFS features, which would have been nice :-) ).


Re: FS Filter Driver question （Tony Mason － DDK MVP）
________________________________________
The only way I've seen this work is to construct a filter that works much
like the compression support for NTFS - that is, your "filter" integrates
into the cache manager and then creates different file objects which it
sends to the underlying FSD.  The version YOU maintain in the cache has the
right length/size information, which is what will be used by application
programs.

Then your "filter" calls the underlying FSD to obtain the data (in mangled +
offset) form.  That the file size underneath you is different doesn't
matter.

Of course, when you are done what you have is more like a stacked file
system than a filter - these are the most complex filters that I've seen,
and I think are harder to develop than a file system.

Re: FS Filter Driver question
________________________________________
Ways to keep the header out of the cache are conceptually different for those two cases. In case if header is at the end you may not even care if it gets into the cache (unless you don't want to expose its content). And event if you don't want anybody to see what is in it, you can simply get its valid content in the read completion routine and then fill the buffer with some garbage. But if you have the header at the beginning you can't afford it to get cached at all because in this case you will end up screwing actual file content when file gets memory mapped. I’m not saying it is impossible. I just think that avoiding this problem will give you more headaches than supporting file expansion with the header at the end.


Re: FS Filter Driver question
________________________________________
Tony: Isn’t “shrinking” bigger file into cache significantly different than expanding smaller file? Since in this case CM will allocate enough pages to fit actual file content? And what does it mean “filter" integrates into the cache manager”? Do you mean that filter will initialize (and whole 9 yards) FO that it receives in the create dispatch and use actual FS just to read/write mangled file? Or there is something else?



                                    第二篇




On Fly encryption filter driver

I am developing a file system filter driver on windows 2000, which does on fly encryption and decryption. I would like to know what is best method to mark the file for encryption. My plan is to add a header information to the encrypted file so that the filter driver will use this information to identify the encrypted file when it is read or written to the disk. Does this solution have any side-effects ? One more issue I have identifed is with temporary files that are created by applications like MS-Word, Visual studio. For example, if an encrypted word document is opened with MS-Word, it creates a temporary document with the same contents and when the document is saved it deletes the original document and renames the temporary document to the orignal name. Since the temoprary document is not marked for encryption its contents will NOT be in encrypted format and when it is renamed to orginal document it is still unencrypted. But the user thinks that the original document is encrypted and hence it is a bug. Is there any solution for this ?


Re: On Fly encryption filter driver
________________________________________
> I am developing a file system filter driver on windows 2000, which does on
> fly encryption and decryption. I would like to know what is best method to
> mark the file for encryption.

Sideband data in the registry, INI file or such.

> My plan is to add a header information to the encrypted file so that the

This will require major effort in dealing with 2 concepts of file sizes.

The encryption filter which adds a header or changes the file size if not a
filter, but more like a complete FSD (which its own FCBs, own file sizes and
Cc/Mm interaction) built on top of another FSD.

For a simple filter, avoid changing the file size and avoid adding headers.