Hi everybody,
I’m developing an encryption minifilter.
The case is that: when I saved the docx file, before closing the file, I used Winhex for viewing the file content and saw that the file content was encrypted. But after closing the file, the files was restored to the original file content, which is non-encrypted.
I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of Word Document. I wonder that did I miss some others IRP_MJ_WRITE for completing the saving file operation? If I missed, what is the process of the saving file operation?
Thanks for all your helps.
I can fully see the merit of Don Burn’s stand on these questions lately 
(Search the list)
xxxxx@gmail.com wrote:
Hi everybody,
I’m developing an encryption minifilter.
The case is that: when I saved the docx file, before closing the file, I used Winhex for viewing the file content and saw that the file content was encrypted. But after closing the file, the files was restored to the original file content, which is non-encrypted.
I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of Word Document. I wonder that did I miss some others IRP_MJ_WRITE for completing the saving file operation? If I missed, what is the process of the saving file operation?
Thanks for all your helps.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Thanks for your quick reply, Dejan.
I’ve searched with “Don Burn Write Operation” but it has a lot of threads.
Would you please recommend for me some keywords?
Thanks you.
OMG 
Let me not derail the thread any more…
Office writes to a temp file, then renames that file to the original file name during a Save operation. That is
why you do not see writes to the file which you think you should.
Dejan.
xxxxx@gmail.com wrote:
Thanks for your quick reply, Dejan.
I’ve searched with “Don Burn Write Operation” but it has a lot of threads.
Would you please recommend for me some keywords?
Thanks you.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Hi Dejan,
I knew that, and I actually encrypted the temp files. When it finish and the file was still opened, I used the Winhex for checking the file content, it was encrypted. But when I closed the file ( after saving operation had done), Winhex showed the original content, I mean the non-encrypted content.
Then you have a fundamental flaw in the en/decryption.
Are you:
- handling only IRP_NOCACHE I/O?
- handling both read and write?
- handling all temp files? (they can be in the same folder, Temp folder, temporary internet files folder and some other places even). ProcMon/FileMon will tell if you did
- detecting and handling error conditions? (during testing, things like allocation failure probably won’t occur, but buffer overruns/underruns could)
Dejan.
xxxxx@gmail.com wrote:
Hi Dejan,
I knew that, and I actually encrypted the temp files. When it finish and the file was still opened, I used the Winhex for checking the file content, it was encrypted. But when I closed the file ( after saving operation had done), Winhex showed the original content, I mean the non-encrypted content.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Thanks for your quick reply.
I’ve already handled only IRP_NOCACHE I/O, both read and write, and all the temp files (used FileSpy).
I’ll check for the last situation you said.
Thanks a lot.
Oh, BTW… are you sure the hex editor accesses the file the same way both times? (perhaps one time it accesses
it directly on the disk, bypassing your filter completely, and the second time it accesses it via the file system,
so it sees the data in the cache instead the on-disk data?)
xxxxx@gmail.com wrote:
Thanks for your quick reply.
I’ve already handled only IRP_NOCACHE I/O, both read and write, and all the temp files (used FileSpy).
I’ll check for the last situation you said.
Thanks a lot.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Umm, at the second time, I also tested when I stopped my minifilter.
Nothing is encrypted 
Do i need to handle others IRP like CLEANUP or CLOSE?
On Thu, Mar 8, 2012 at 9:04 PM, Dejan Maksimovic wrote:
>
> Oh, BTW… are you sure the hex editor accesses the file the same way
> both times? (perhaps one time it accesses
> it directly on the disk, bypassing your filter completely, and the second
> time it accesses it via the file system,
> so it sees the data in the cache instead the on-disk data?)
>
> xxxxx@gmail.com wrote:
>
> > Thanks for your quick reply.
> > I’ve already handled only IRP_NOCACHE I/O, both read and write, and all
> the temp files (used FileSpy).
> > I’ll check for the last situation you said.
> > Thanks a lot.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Regards,
Nhat
Hoang Xuan Quang Nhat
Faculty of Information Technology
University of Science - Vietnam National University HCM
Yahoo: suwax
Skype: hxquangnhat
Phone number: 0935.594.945
No. Unless you use a block-based cipher, in which case you need to
handle the last chunk of the file differently, but that is a different
issue from the one you are facing.
The question that bugs me is why does hexview see the file as
ciphertext at all? Are you providing different views to different
applications? If your mini-filter is running and the hex editor sees the
file as ciphertext, that is the time when your filter fails (presuming
that hexview accesses the file directly, which you can confirm via
FileMon/ProcMon)
Once your filter is stopped, it does not mean the cache for the file
is purged. The data in the cache would still be the cleartext data. (you
are allowing a possible data corruption to occur here)
Dejan.
Nhat Hoang wrote:
Umm, at the second time, I also tested when I stopped my minifilter.
Nothing is encrypted
Do i need to handle others IRP like CLEANUP or CLOSE?On Thu, Mar 8, 2012 at 9:04 PM, Dejan Maksimovic
> wrote:
>
> >
> > Oh, BTW… are you sure the hex editor accesses the file the same
> way
> > both times? (perhaps one time it accesses
> > it directly on the disk, bypassing your filter completely, and the
> second
> > time it accesses it via the file system,
> > so it sees the data in the cache instead the on-disk data?)
> >
> > xxxxx@gmail.com wrote:
> >
> > > Thanks for your quick reply.
> > > I’ve already handled only IRP_NOCACHE I/O, both read and write,
> and all
> > the temp files (used FileSpy).
> > > I’ll check for the last situation you said.
> > > Thanks a lot.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Given that Office already has a strong encryption mechanism, why do you
feel it is necessary to duplicate it?
joe
Hi everybody,
I’m developing an encryption minifilter.
The case is that: when I saved the docx file, before closing the file, I
used Winhex for viewing the file content and saw that the file content was
encrypted. But after closing the file, the files was restored to the
original file content, which is non-encrypted.
I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of
Word Document. I wonder that did I miss some others IRP_MJ_WRITE for
completing the saving file operation? If I missed, what is the process of
the saving file operation?
Thanks for all your helps.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Haven’t we satisfied this argument before? If you work on a per-file
encryption product, your customers are going to want to encrypt all kinds of
things. Office files happen to be one of the things that people want to
protect, so there’s an expectation that you’ll be able to encrypt those as
well as anything else (e.g. CAD files, any files on external devices, etc.)
via some central management facility.
Office also happens to be a hideously complicated piece of software that has
a somewhat unexpected I/O pattern, hence the repeated questions about it
(and anyone with battle scars from working on a data transformation filter
probably has at least a shred of sympathy for these folks). Now, if you want
to argue that these people should really be doing their homework before
posting here, I’m all for it. However, this isn’t an O/S architectural
issue, it’s a bug in the filter’s design or implementation. In my book,
working around a bug in your code by dropping support for a major
application suite is, well, kind of a big decision. By that logic it’s not
worth encrypting anything on NTFS volumes because there’s already EFS (and
good luck selling that product!).
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntfsd…
Given that Office already has a strong encryption mechanism, why do you
feel it is necessary to duplicate it?
joe
Hi everybody,
I’m developing an encryption minifilter.
The case is that: when I saved the docx file, before closing the file, I
used Winhex for viewing the file content and saw that the file content was
encrypted. But after closing the file, the files was restored to the
original file content, which is non-encrypted.
I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of
Word Document. I wonder that did I miss some others IRP_MJ_WRITE for
completing the saving file operation? If I missed, what is the process of
the saving file operation?
Thanks for all your helps.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Totally unrelated purpose.
xxxxx@flounder.com wrote:
Given that Office already has a strong encryption mechanism, why do you
feel it is necessary to duplicate it?
joe> Hi everybody,
> I’m developing an encryption minifilter.
> The case is that: when I saved the docx file, before closing the file, I
> used Winhex for viewing the file content and saw that the file content was
> encrypted. But after closing the file, the files was restored to the
> original file content, which is non-encrypted.
> I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of
> Word Document. I wonder that did I miss some others IRP_MJ_WRITE for
> completing the saving file operation? If I missed, what is the process of
> the saving file operation?
> Thanks for all your helps.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
If you have implemented your filter correctly, it will encrypt any file.
Office files will just be a special kind of file. You seem to think that
Office is presenting some kind of special problem. If you think this is
so, then your filter driver design is wrong. It has to work correctly on
any kind of file, with any kind of I/O pattern, under all conditions you
can imagine, including memory-mapped files.
Key here is that if you are trying to pretend to be “smart” and encrypting
only certain kinds of files, or files from what you think you have
discovered to be managed by particular programs, or work in some fantasy
world where you think files are read and written sequentially, then you
are going to have problems. A file encryption filter must assume that any
byte subsequence of the file can be read or written at any time. If you
are using some kind of block encryption, you will need to round such
requests down to the nearest block bounary, read that block in, convert it
to plaintext, make the change, and re-encrypt that block. You have not
indicated what kind of algorithm you are using. Since you focused on
Office files, there seemed to be no point to doing an Office-specific
encryption, because for Office, it is already built in. If you are doing
general encryption, see the above constraints. Any byte subsequence,
anywhere, any time, not negotiable. And I have no idea of the implications
for memory-mapped files, but I remember Tony Mason talking about all the
problems that this introduces in one of his lectures at a Windows
conference. Let us say that as an experienced driver writer (I wrote my
first device driver 47 years ago, although I didn’t know it should have
been called a “device driver”), that his knowledge was so broad, and so
deep, that I would never, ever undertake to work on a file system driver
of any sort, because I simply would not have any idea how to cover all the
complex cases that arise. Note that in my past, I actually had such deep
knowledge in non-Windows systems, and it took me years to acquire it. So
I recognized most of the techniques he described (he was describing how to
implement a compressed, encrypted file system, where the compression can
change the size of the unit of information. So he implemented what I
would recognize as IBM’s indexed file technology that I worked on in the
1960s. Note that this is distinctly nontrivial; I’ve built a couple
applications that implement this and it is very much not straightforward,
if you want to maintain any illusion of efficiency).
So if your filter driver doesn’t work right, you need to consider how it
is implemented. It just might be wrong.
joe
Totally unrelated purpose.
xxxxx@flounder.com wrote:
> Given that Office already has a strong encryption mechanism, why do you
> feel it is necessary to duplicate it?
> joe
>
> > Hi everybody,
> > I’m developing an encryption minifilter.
> > The case is that: when I saved the docx file, before closing the file,
> I
> > used Winhex for viewing the file content and saw that the file content
> was
> > encrypted. But after closing the file, the files was restored to the
> > original file content, which is non-encrypted.
> > I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of
> > Word Document. I wonder that did I miss some others IRP_MJ_WRITE for
> > completing the saving file operation? If I missed, what is the process
> of
> > the saving file operation?
> > Thanks for all your helps.
> >
> > —
> > NTFSD is sponsored by OSR
> >
> > For our schedule of debugging and file system seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Was this actually meant for me? (I don’t see how it relates to your or my post)
xxxxx@flounder.com wrote:
If you have implemented your filter correctly, it will encrypt any file.
Office files will just be a special kind of file. You seem to think that
Office is presenting some kind of special problem. If you think this is
so, then your filter driver design is wrong. It has to work correctly on
any kind of file, with any kind of I/O pattern, under all conditions you
can imagine, including memory-mapped files.Key here is that if you are trying to pretend to be “smart” and encrypting
only certain kinds of files, or files from what you think you have
discovered to be managed by particular programs, or work in some fantasy
world where you think files are read and written sequentially, then you
are going to have problems. A file encryption filter must assume that any
byte subsequence of the file can be read or written at any time. If you
are using some kind of block encryption, you will need to round such
requests down to the nearest block bounary, read that block in, convert it
to plaintext, make the change, and re-encrypt that block. You have not
indicated what kind of algorithm you are using. Since you focused on
Office files, there seemed to be no point to doing an Office-specific
encryption, because for Office, it is already built in. If you are doing
general encryption, see the above constraints. Any byte subsequence,
anywhere, any time, not negotiable. And I have no idea of the implications
for memory-mapped files, but I remember Tony Mason talking about all the
problems that this introduces in one of his lectures at a Windows
conference. Let us say that as an experienced driver writer (I wrote my
first device driver 47 years ago, although I didn’t know it should have
been called a “device driver”), that his knowledge was so broad, and so
deep, that I would never, ever undertake to work on a file system driver
of any sort, because I simply would not have any idea how to cover all the
complex cases that arise. Note that in my past, I actually had such deep
knowledge in non-Windows systems, and it took me years to acquire it. So
I recognized most of the techniques he described (he was describing how to
implement a compressed, encrypted file system, where the compression can
change the size of the unit of information. So he implemented what I
would recognize as IBM’s indexed file technology that I worked on in the
1960s. Note that this is distinctly nontrivial; I’ve built a couple
applications that implement this and it is very much not straightforward,
if you want to maintain any illusion of efficiency).So if your filter driver doesn’t work right, you need to consider how it
is implemented. It just might be wrong.
joe>
> Totally unrelated purpose.
>
> xxxxx@flounder.com wrote:
>
>> Given that Office already has a strong encryption mechanism, why do you
>> feel it is necessary to duplicate it?
>> joe
>>
>> > Hi everybody,
>> > I’m developing an encryption minifilter.
>> > The case is that: when I saved the docx file, before closing the file,
>> I
>> > used Winhex for viewing the file content and saw that the file content
>> was
>> > encrypted. But after closing the file, the files was restored to the
>> > original file content, which is non-encrypted.
>> > I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file of
>> > Word Document. I wonder that did I miss some others IRP_MJ_WRITE for
>> > completing the saving file operation? If I missed, what is the process
>> of
>> > the saving file operation?
>> > Thanks for all your helps.
>> >
>> > —
>> > NTFSD is sponsored by OSR
>> >
>> > For our schedule of debugging and file system seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Thanks for all your replies.
Office is just something I choose to begin with minifilter (notepad already) and I think I’ll learn a lot when implementing a minifilter for Office.
I’ll dig down my minifilter to fix the error.
Thanks again.
It was meant for the OP.
joe
Was this actually meant for me? (I don’t see how it relates to your or
my post)xxxxx@flounder.com wrote:
> If you have implemented your filter correctly, it will encrypt any file.
> Office files will just be a special kind of file. You seem to think
> that
> Office is presenting some kind of special problem. If you think this is
> so, then your filter driver design is wrong. It has to work correctly
> on
> any kind of file, with any kind of I/O pattern, under all conditions you
> can imagine, including memory-mapped files.
>
> Key here is that if you are trying to pretend to be “smart” and
> encrypting
> only certain kinds of files, or files from what you think you have
> discovered to be managed by particular programs, or work in some fantasy
> world where you think files are read and written sequentially, then you
> are going to have problems. A file encryption filter must assume that
> any
> byte subsequence of the file can be read or written at any time. If you
> are using some kind of block encryption, you will need to round such
> requests down to the nearest block bounary, read that block in, convert
> it
> to plaintext, make the change, and re-encrypt that block. You have not
> indicated what kind of algorithm you are using. Since you focused on
> Office files, there seemed to be no point to doing an Office-specific
> encryption, because for Office, it is already built in. If you are
> doing
> general encryption, see the above constraints. Any byte subsequence,
> anywhere, any time, not negotiable. And I have no idea of the
> implications
> for memory-mapped files, but I remember Tony Mason talking about all the
> problems that this introduces in one of his lectures at a Windows
> conference. Let us say that as an experienced driver writer (I wrote my
> first device driver 47 years ago, although I didn’t know it should have
> been called a “device driver”), that his knowledge was so broad, and so
> deep, that I would never, ever undertake to work on a file system driver
> of any sort, because I simply would not have any idea how to cover all
> the
> complex cases that arise. Note that in my past, I actually had such
> deep
> knowledge in non-Windows systems, and it took me years to acquire it.
> So
> I recognized most of the techniques he described (he was describing how
> to
> implement a compressed, encrypted file system, where the compression can
> change the size of the unit of information. So he implemented what I
> would recognize as IBM’s indexed file technology that I worked on in the
> 1960s. Note that this is distinctly nontrivial; I’ve built a couple
> applications that implement this and it is very much not
> straightforward,
> if you want to maintain any illusion of efficiency).
>
> So if your filter driver doesn’t work right, you need to consider how it
> is implemented. It just might be wrong.
> joe
>
> >
> > Totally unrelated purpose.
> >
> > xxxxx@flounder.com wrote:
> >
> >> Given that Office already has a strong encryption mechanism, why do
> you
> >> feel it is necessary to duplicate it?
> >> joe
> >>
> >> > Hi everybody,
> >> > I’m developing an encryption minifilter.
> >> > The case is that: when I saved the docx file, before closing the
> file,
> >> I
> >> > used Winhex for viewing the file content and saw that the file
> content
> >> was
> >> > encrypted. But after closing the file, the files was restored to
> the
> >> > original file content, which is non-encrypted.
> >> > I made the decrypting in the PostWrite of IRP_MJ_WRITE for tmp file
> of
> >> > Word Document. I wonder that did I miss some others IRP_MJ_WRITE
> for
> >> > completing the saving file operation? If I missed, what is the
> process
> >> of
> >> > the saving file operation?
> >> > Thanks for all your helps.
> >> >
> >> > —
> >> > NTFSD is sponsored by OSR
> >> >
> >> > For our schedule of debugging and file system seminars visit:
> >> > http://www.osr.com/seminars
> >> >
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> > http://www.osronline.com/page.cfm?name=ListServer
> >> >
> >>
> >> —
> >> NTFSD is sponsored by OSR
> >>
> >> For our schedule of debugging and file system seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >
> > –
> > Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> > http://www.alfasp.com
> > File system audit, security and encryption kits.
> >
> >
> >
> > —
> > NTFSD is sponsored by OSR
> >
> > For our schedule of debugging and file system seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer