because my encrypted filter,winzip can't handle .zip file

OSR_Community_User · March 31, 2005, 12:44am

my encrypted filter will add some info in the tail of a file,and I will
provide transparent service.
every application software works well: notepad,word,IE,etc.
But,winzip can’t work well,when winzip unzip a .zip file,it will report
error.
Why?
According to my analyze,my encrypted filter don’t care those IRP that get
filesize before the file is opened.Of course,I care those IRP that involved
with filesize,for instance,QueryInfomation,Read,etc.The cause I don’t care
these is speed.
So,Winzip get the filesize before it open the .zip file.And,it take the
filesize as the real filesize in sequent handle.Is that the cause?

I want to get a code like winzip for handing .zip file.I get some codes,but
they all get the filesize by the file handle(the file is opened).So,they
work well with my filter.
But the question is : I can’t get a code that will report error just like
winzip,so ,I can’t say,I have finded the cause winzip can’t works well with
my filter.

Is anybody meet the problem?

ÓëÁª»úµÄÅóÓÑ½øÐÐ½»Á÷£¬ÇëÊ¹ÓÃ MSN Messenger: http://messenger.msn.com/cn

OSR_Community_User · March 31, 2005, 1:23am

Of course anybody has experienced the same problem
Your analysis is correct, WinZip really does it that
way. First - it gets the file size from the directory
info (using FindFirstFile), then opens the file
and gets the size again. And because the file sizes
do not match, it considers the file invalid.

BTW, this behavior can be observed from time to time
in another software too. An example is the integrated
CD burning in Windows XP explorer. Nero will also
complain if you encrypt at least one file that is
to be burnt to CD/DVD.

L.

Neil_Weicher · March 31, 2005, 7:56am

Ladislav is right - but it is worse than that. A lot of the compression
software, including many of the ActiveX compression controls, do it the same
way. There is no way around it without enormous kludges.

Neil

----- Original Message -----
From: “Xiong ZiJan”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, March 31, 2005 12:43 AM
Subject: [ntfsd] because my encrypted filter,winzip can’t handle .zip file

my encrypted filter will add some info in the tail of a file,and I will
provide transparent service.
every application software works well: notepad,word,IE,etc.
But,winzip can’t work well,when winzip unzip a .zip file,it will report
error.
Why?
According to my analyze,my encrypted filter don’t care those IRP that get
filesize before the file is opened.Of course,I care those IRP that involved
with filesize,for instance,QueryInfomation,Read,etc.The cause I don’t care
these is speed.
So,Winzip get the filesize before it open the .zip file.And,it take the
filesize as the real filesize in sequent handle.Is that the cause?

I want to get a code like winzip for handing .zip file.I get some codes,but
they all get the filesize by the file handle(the file is opened).So,they
work well with my filter.
But the question is : I can’t get a code that will report error just like
winzip,so ,I can’t say,I have finded the cause winzip can’t works well with
my filter.

Is anybody meet the problem?

OSR_Community_User · March 31, 2005, 2:01pm

I can’t believe somebody even thinks about workarounds for this kind of “problems”. Filter driver has to be transparent and preserve consistent file system view no matter what application does. This is a task for driver verifier and WHQL process if developers aren’t disciplined enough; driver which does something like this “for speed” should never pass.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Neil Weicher[SMTP:xxxxx@netlib.com]
Reply To: Windows File Systems Devs Interest List
Sent: Thursday, March 31, 2005 2:55 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] because my encrypted filter,winzip can’t handle .zip file

Ladislav is right - but it is worse than that. A lot of the compression
software, including many of the ActiveX compression controls, do it the same
way. There is no way around it without enormous kludges.

Neil

----- Original Message -----
From: “Xiong ZiJan”
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, March 31, 2005 12:43 AM
> Subject: [ntfsd] because my encrypted filter,winzip can’t handle .zip file
>
>
> my encrypted filter will add some info in the tail of a file,and I will
> provide transparent service.
> every application software works well: notepad,word,IE,etc.
> But,winzip can’t work well,when winzip unzip a .zip file,it will report
> error.
> Why?
> According to my analyze,my encrypted filter don’t care those IRP that get
> filesize before the file is opened.Of course,I care those IRP that involved
> with filesize,for instance,QueryInfomation,Read,etc.The cause I don’t care
> these is speed.
> So,Winzip get the filesize before it open the .zip file.And,it take the
> filesize as the real filesize in sequent handle.Is that the cause?
>
> I want to get a code like winzip for handing .zip file.I get some codes,but
> they all get the filesize by the file handle(the file is opened).So,they
> work well with my filter.
> But the question is : I can’t get a code that will report error just like
> winzip,so ,I can’t say,I have finded the cause winzip can’t works well with
> my filter.
>
> Is anybody meet the problem?
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Neil_Weicher · March 31, 2005, 2:50pm

When I say it would take an enormous kludge that means “don’t do it.” You
might be able to get away with this kind of thing in Windows 9x but not in
NT.

----- Original Message -----
From: “Michal Vodicka”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, March 31, 2005 2:01 PM
Subject: RE: [ntfsd] because my encrypted filter,winzip can’t handle .zip
file

I can’t believe somebody even thinks about workarounds for this kind of
“problems”. Filter driver has to be transparent and preserve consistent file
system view no matter what application does. This is a task for driver
verifier and WHQL process if developers aren’t disciplined enough; driver
which does something like this “for speed” should never pass.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on
behalf of Neil Weicher[SMTP:xxxxx@netlib.com]
> Reply To: Windows File Systems Devs Interest List
> Sent: Thursday, March 31, 2005 2:55 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] because my encrypted filter,winzip can’t handle .zip
file
>
> Ladislav is right - but it is worse than that. A lot of the compression
> software, including many of the ActiveX compression controls, do it the
same
> way. There is no way around it without enormous kludges.
>
> Neil
>
>
> ----- Original Message -----
> From: “Xiong ZiJan”
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, March 31, 2005 12:43 AM
> Subject: [ntfsd] because my encrypted filter,winzip can’t handle .zip file
>
>
> my encrypted filter will add some info in the tail of a file,and I will
> provide transparent service.
> every application software works well: notepad,word,IE,etc.
> But,winzip can’t work well,when winzip unzip a .zip file,it will report
> error.
> Why?
> According to my analyze,my encrypted filter don’t care those IRP that get
> filesize before the file is opened.Of course,I care those IRP that
involved
> with filesize,for instance,QueryInfomation,Read,etc.The cause I don’t care
> these is speed.
> So,Winzip get the filesize before it open the .zip file.And,it take the
> filesize as the real filesize in sequent handle.Is that the cause?
>
> I want to get a code like winzip for handing .zip file.I get some
codes,but
> they all get the filesize by the file handle(the file is opened).So,they
> work well with my filter.
> But the question is : I can’t get a code that will report error just like
> winzip,so ,I can’t say,I have finded the cause winzip can’t works well
with
> my filter.
>
> Is anybody meet the problem?

OSR_Community_User · April 1, 2005, 12:33am

Well, believe or not, a workaround is necessary. The good solution
(b the means of FS design) is to get the real file size on query directory.
But because third party data modification filters don’t have the confort of
“encrypted” or “compressed” attribute (like NTFS has), the process of
querying file state is much slower than testing a bit in the attributes
entry.

You certainly can imagine what will this process do with e.g. Explorer
performance, if every query directory will be followed by file open
and read a few bytes from it.

So good compromise is necessary here.

L.

Don_Burn_1 · April 1, 2005, 11:34am

I’ve got a customer looking for something similar. They want an encryption
type scheme where some applications trigger a decrypt (and therefore a
smaller size file), but other applications for instance explorer just get
the file encrypted. I can see similar problems here, any comments or
suggestions on this would be appreciated.

This list will probably see a bunch of posts from me, I’ve done filesystems
and redirectors, but never a comercial filter. Definitely a different
world.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, believe or not, a workaround is necessary. The good solution
> (b the means of FS design) is to get the real file size on query
> directory.
> But because third party data modification filters don’t have the confort
> of
> “encrypted” or “compressed” attribute (like NTFS has), the process of
> querying file state is much slower than testing a bit in the attributes
> entry.
>
> You certainly can imagine what will this process do with e.g. Explorer
> performance, if every query directory will be followed by file open
> and read a few bytes from it.
>
> So good compromise is necessary here.
>
> L.
>
>

OSR_Community_User · April 1, 2005, 11:49am

I’m giving a talk at DDC about our experiences building our “Data
Modification Kit” - a toolkit explicitly written to provide robust
support as a framework for encryption and compression drivers. One key
aspect of this is choosing to provide different views of the file to
different callers.

The approach we’ve used is that you present two different views - as if
they were two different files at least from the OS perspective. We make
this work by implementing as a layered file system, so we control the
caching of the clear data.

Changes via one layer must invalidate the other of course, so you do
have some extra work to do to ensure consistency (it is the same file)
but the bifurcated view approach does work well - although at the cost
of added complexity. Of course that is why we’ve been building this
toolkit - to make this easy for others to implement this functionality
without being forced into solving some of the hard problems (and let me
note that supporting compression is actually much harder than
encryption, and we’re able to support both of them.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, April 01, 2005 11:34 AM
To: ntfsd redirect
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

I’ve got a customer looking for something similar. They want an
encryption
type scheme where some applications trigger a decrypt (and therefore a
smaller size file), but other applications for instance explorer just
get
the file encrypted. I can see similar problems here, any comments or
suggestions on this would be appreciated.

This list will probably see a bunch of posts from me, I’ve done
filesystems
and redirectors, but never a comercial filter. Definitely a different
world.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, believe or not, a workaround is necessary. The good solution
> (b the means of FS design) is to get the real file size on query
> directory.
> But because third party data modification filters don’t have the
confort
> of
> “encrypted” or “compressed” attribute (like NTFS has), the process of
> querying file state is much slower than testing a bit in the
attributes
> entry.
>
> You certainly can imagine what will this process do with e.g. Explorer
> performance, if every query directory will be followed by file open
> and read a few bytes from it.
>
> So good compromise is necessary here.
>
> L.
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Neil_Weicher · April 1, 2005, 11:58am

Don - I suspect this is not exactly what you are looking for, but we
actually created our own compression-encryption mechanism. Encrypted files
don’t compress well otherwise. Let me know if you want more info. - Neil

----- Original Message -----
From: “Don Burn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, April 01, 2005 11:33 AM
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

I’ve got a customer looking for something similar. They want an encryption
type scheme where some applications trigger a decrypt (and therefore a
smaller size file), but other applications for instance explorer just get
the file encrypted. I can see similar problems here, any comments or
suggestions on this would be appreciated.

This list will probably see a bunch of posts from me, I’ve done filesystems
and redirectors, but never a comercial filter. Definitely a different
world.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, believe or not, a workaround is necessary. The good solution
> (b the means of FS design) is to get the real file size on query
> directory.
> But because third party data modification filters don’t have the confort
> of
> “encrypted” or “compressed” attribute (like NTFS has), the process of
> querying file state is much slower than testing a bit in the attributes
> entry.
>
> You certainly can imagine what will this process do with e.g. Explorer
> performance, if every query directory will be followed by file open
> and read a few bytes from it.
>
> So good compromise is necessary here.
>
> L.
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@netlib.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · April 1, 2005, 12:05pm

Tony,

This doesn’t seem to appear on the preliminary schedule, do you have a
time slot? With my luck this will be while I am giving my talk at WinHEC.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Tony Mason” wrote in message news:xxxxx@ntfsd…
I’m giving a talk at DDC about our experiences building our “Data
Modification Kit” - a toolkit explicitly written to provide robust
support as a framework for encryption and compression drivers. One key
aspect of this is choosing to provide different views of the file to
different callers.

The approach we’ve used is that you present two different views - as if
they were two different files at least from the OS perspective. We make
this work by implementing as a layered file system, so we control the
caching of the clear data.

Changes via one layer must invalidate the other of course, so you do
have some extra work to do to ensure consistency (it is the same file)
but the bifurcated view approach does work well - although at the cost
of added complexity. Of course that is why we’ve been building this
toolkit - to make this easy for others to implement this functionality
without being forced into solving some of the hard problems (and let me
note that supporting compression is actually much harder than
encryption, and we’re able to support both of them.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, April 01, 2005 11:34 AM
To: ntfsd redirect
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

I’ve got a customer looking for something similar. They want an
encryption
type scheme where some applications trigger a decrypt (and therefore a
smaller size file), but other applications for instance explorer just
get
the file encrypted. I can see similar problems here, any comments or
suggestions on this would be appreciated.

This list will probably see a bunch of posts from me, I’ve done
filesystems
and redirectors, but never a comercial filter. Definitely a different
world.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, believe or not, a workaround is necessary. The good solution
> (b the means of FS design) is to get the real file size on query
> directory.
> But because third party data modification filters don’t have the
confort
> of
> “encrypted” or “compressed” attribute (like NTFS has), the process of
> querying file state is much slower than testing a bit in the
attributes
> entry.
>
> You certainly can imagine what will this process do with e.g. Explorer
> performance, if every query directory will be followed by file open
> and read a few bytes from it.
>
> So good compromise is necessary here.
>
> L.
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · April 1, 2005, 12:15pm

I just conferred with the Powers That Be here that this will be Tuesday,
8:30 am.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, April 01, 2005 12:04 PM
To: ntfsd redirect
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

Tony,

This doesn’t seem to appear on the preliminary schedule, do you have
a
time slot? With my luck this will be while I am giving my talk at
WinHEC.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Tony Mason” wrote in message news:xxxxx@ntfsd…
I’m giving a talk at DDC about our experiences building our “Data
Modification Kit” - a toolkit explicitly written to provide robust
support as a framework for encryption and compression drivers. One key
aspect of this is choosing to provide different views of the file to
different callers.

The approach we’ve used is that you present two different views - as if
they were two different files at least from the OS perspective. We make
this work by implementing as a layered file system, so we control the
caching of the clear data.

Changes via one layer must invalidate the other of course, so you do
have some extra work to do to ensure consistency (it is the same file)
but the bifurcated view approach does work well - although at the cost
of added complexity. Of course that is why we’ve been building this
toolkit - to make this easy for others to implement this functionality
without being forced into solving some of the hard problems (and let me
note that supporting compression is actually much harder than
encryption, and we’re able to support both of them.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, April 01, 2005 11:34 AM
To: ntfsd redirect
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

I’ve got a customer looking for something similar. They want an
encryption
type scheme where some applications trigger a decrypt (and therefore a
smaller size file), but other applications for instance explorer just
get
the file encrypted. I can see similar problems here, any comments or
suggestions on this would be appreciated.

This list will probably see a bunch of posts from me, I’ve done
filesystems
and redirectors, but never a comercial filter. Definitely a different
world.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, believe or not, a workaround is necessary. The good solution
> (b the means of FS design) is to get the real file size on query
> directory.
> But because third party data modification filters don’t have the
confort
> of
> “encrypted” or “compressed” attribute (like NTFS has), the process of
> querying file state is much slower than testing a bit in the
attributes
> entry.
>
> You certainly can imagine what will this process do with e.g. Explorer
> performance, if every query directory will be followed by file open
> and read a few bytes from it.
>
> So good compromise is necessary here.
>
> L.
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · April 1, 2005, 12:19pm

How could I guess, that is when my presentation is!

Don

“Tony Mason” wrote in message news:xxxxx@ntfsd…
I just conferred with the Powers That Be here that this will be Tuesday,
8:30 am.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, April 01, 2005 12:04 PM
To: ntfsd redirect
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

Tony,

This doesn’t seem to appear on the preliminary schedule, do you have
a
time slot? With my luck this will be while I am giving my talk at
WinHEC.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Tony Mason” wrote in message news:xxxxx@ntfsd…
I’m giving a talk at DDC about our experiences building our “Data
Modification Kit” - a toolkit explicitly written to provide robust
support as a framework for encryption and compression drivers. One key
aspect of this is choosing to provide different views of the file to
different callers.

The approach we’ve used is that you present two different views - as if
they were two different files at least from the OS perspective. We make
this work by implementing as a layered file system, so we control the
caching of the clear data.

Changes via one layer must invalidate the other of course, so you do
have some extra work to do to ensure consistency (it is the same file)
but the bifurcated view approach does work well - although at the cost
of added complexity. Of course that is why we’ve been building this
toolkit - to make this easy for others to implement this functionality
without being forced into solving some of the hard problems (and let me
note that supporting compression is actually much harder than
encryption, and we’re able to support both of them.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, April 01, 2005 11:34 AM
To: ntfsd redirect
Subject: Re:[ntfsd] because my encrypted filter,winzip can’t handle .zip
file

I’ve got a customer looking for something similar. They want an
encryption
type scheme where some applications trigger a decrypt (and therefore a
smaller size file), but other applications for instance explorer just
get
the file encrypted. I can see similar problems here, any comments or
suggestions on this would be appreciated.

This list will probably see a bunch of posts from me, I’ve done
filesystems
and redirectors, but never a comercial filter. Definitely a different
world.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, believe or not, a workaround is necessary. The good solution
> (b the means of FS design) is to get the real file size on query
> directory.
> But because third party data modification filters don’t have the
confort
> of
> “encrypted” or “compressed” attribute (like NTFS has), the process of
> querying file state is much slower than testing a bit in the
attributes
> entry.
>
> You certainly can imagine what will this process do with e.g. Explorer
> performance, if every query directory will be followed by file open
> and read a few bytes from it.
>
> So good compromise is necessary here.
>
> L.
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

David_J_Craig · April 1, 2005, 12:57pm

There are two solutions to this problem. You can allow or prevent access to
the ‘file(s)’ in different modes - encrypted or plaintext - at the same
time. You can write it so that if an authorized program has the file open
in plaintext mode and an application attempts to open it in encrypted mode
that second application get a failure on create. The converse will have to
be true also. I would just fake a file not found or access error to the
second program. If this is not acceptable to your client, then you will
find that Windows does not support multiple caches, so writing your own
filesystem is required. You might be able to fake being a filesystem while
actually filtering other filesystems, but it sure won’t be easy to keep the
views straight. Memory mapped will be an interesting challenge, but it can
probably be done. Plan for lots of time as it will take several man-months.

I guess another question is how do you know that an application of some name
is the ‘real’ application? Key management is another problem.

“Don Burn” wrote in message news:xxxxx@ntfsd…
> I’ve got a customer looking for something similar. They want an
> encryption type scheme where some applications trigger a decrypt (and
> therefore a smaller size file), but other applications for instance
> explorer just get the file encrypted. I can see similar problems here,
> any comments or suggestions on this would be appreciated.
>
> This list will probably see a bunch of posts from me, I’ve done
> filesystems and redirectors, but never a comercial filter. Definitely a
> different world.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
>
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> Well, believe or not, a workaround is necessary. The good solution
>> (b the means of FS design) is to get the real file size on query
>> directory.
>> But because third party data modification filters don’t have the confort
>> of
>> “encrypted” or “compressed” attribute (like NTFS has), the process of
>> querying file state is much slower than testing a bit in the attributes
>> entry.
>>
>> You certainly can imagine what will this process do with e.g. Explorer
>> performance, if every query directory will be followed by file open
>> and read a few bytes from it.
>>
>> So good compromise is necessary here.
>>
>> L.
>>
>>
>
>
>

Don_Burn_1 · April 1, 2005, 1:02pm

Yeah, I know about the “real” application problem and have educated the
customer. They are trying to insist on a password prompt triggered by the
create, I’ve suggested this is not viable approach.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“David J. Craig” wrote in message
news:xxxxx@ntfsd…
> There are two solutions to this problem. You can allow or prevent access
> to the ‘file(s)’ in different modes - encrypted or plaintext - at the same
> time. You can write it so that if an authorized program has the file open
> in plaintext mode and an application attempts to open it in encrypted mode
> that second application get a failure on create. The converse will have
> to be true also. I would just fake a file not found or access error to
> the second program. If this is not acceptable to your client, then you
> will find that Windows does not support multiple caches, so writing your
> own filesystem is required. You might be able to fake being a filesystem
> while actually filtering other filesystems, but it sure won’t be easy to
> keep the views straight. Memory mapped will be an interesting challenge,
> but it can probably be done. Plan for lots of time as it will take
> several man-months.
>
> I guess another question is how do you know that an application of some
> name is the ‘real’ application? Key management is another problem.
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> I’ve got a customer looking for something similar. They want an
>> encryption type scheme where some applications trigger a decrypt (and
>> therefore a smaller size file), but other applications for instance
>> explorer just get the file encrypted. I can see similar problems here,
>> any comments or suggestions on this would be appreciated.
>>
>> This list will probably see a bunch of posts from me, I’ve done
>> filesystems and redirectors, but never a comercial filter. Definitely a
>> different world.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>>
>> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>>> Well, believe or not, a workaround is necessary. The good solution
>>> (b the means of FS design) is to get the real file size on query
>>> directory.
>>> But because third party data modification filters don’t have the confort
>>> of
>>> “encrypted” or “compressed” attribute (like NTFS has), the process of
>>> querying file state is much slower than testing a bit in the attributes
>>> entry.
>>>
>>> You certainly can imagine what will this process do with e.g. Explorer
>>> performance, if every query directory will be followed by file open
>>> and read a few bytes from it.
>>>
>>> So good compromise is necessary here.
>>>
>>> L.
>>>
>>>
>>
>>
>>
>
>
>

David_J_Craig · April 1, 2005, 1:11pm

You can authenticate the ‘real’ application by storing dates, sizes, &
hashes of them. High maintenance, but doable. I would suggest if you are
paranoid enough that you store MD5 & SHA-1 hashes as while both have
weaknesses, finding a way through both would be much harder.

The IRP_MJ_CREATE for files opened by applications will be at passive level,
so you could pass it off to a program. If the access is queried when the
user logs in, only the credentials needed for decryption/encryption will be
required and no user prompt. I like using smartcards. If the correct card
is not present, access is denied. You can then store the session key in the
file, encrypted by the smartcard’s public key. Use a good crypto package
and have it reviewed by them unless you are a cryptographer.

“Don Burn” wrote in message news:xxxxx@ntfsd…
> Yeah, I know about the “real” application problem and have educated the
> customer. They are trying to insist on a password prompt triggered by the
> create, I’ve suggested this is not viable approach.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “David J. Craig” wrote in message
> news:xxxxx@ntfsd…
>> There are two solutions to this problem. You can allow or prevent access
>> to the ‘file(s)’ in different modes - encrypted or plaintext - at the
>> same time. You can write it so that if an authorized program has the
>> file open in plaintext mode and an application attempts to open it in
>> encrypted mode that second application get a failure on create. The
>> converse will have to be true also. I would just fake a file not found
>> or access error to the second program. If this is not acceptable to your
>> client, then you will find that Windows does not support multiple caches,
>> so writing your own filesystem is required. You might be able to fake
>> being a filesystem while actually filtering other filesystems, but it
>> sure won’t be easy to keep the views straight. Memory mapped will be an
>> interesting challenge, but it can probably be done. Plan for lots of
>> time as it will take several man-months.
>>
>> I guess another question is how do you know that an application of some
>> name is the ‘real’ application? Key management is another problem.
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>> I’ve got a customer looking for something similar. They want an
>>> encryption type scheme where some applications trigger a decrypt (and
>>> therefore a smaller size file), but other applications for instance
>>> explorer just get the file encrypted. I can see similar problems here,
>>> any comments or suggestions on this would be appreciated.
>>>
>>> This list will probably see a bunch of posts from me, I’ve done
>>> filesystems and redirectors, but never a comercial filter. Definitely a
>>> different world.
>>>
>>>
>>> –
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> Remove StopSpam from the email to reply
>>>
>>>
>>>
>>>
>>> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>>>> Well, believe or not, a workaround is necessary. The good solution
>>>> (b the means of FS design) is to get the real file size on query
>>>> directory.
>>>> But because third party data modification filters don’t have the
>>>> confort of
>>>> “encrypted” or “compressed” attribute (like NTFS has), the process of
>>>> querying file state is much slower than testing a bit in the attributes
>>>> entry.
>>>>
>>>> You certainly can imagine what will this process do with e.g. Explorer
>>>> performance, if every query directory will be followed by file open
>>>> and read a few bytes from it.
>>>>
>>>> So good compromise is necessary here.
>>>>
>>>> L.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

OSR_Community_User · April 4, 2005, 1:27am

Tony, David, Don,

The approach we’ve used is that you present two different views - as if
they were two different files at least from the OS perspective. We make
this work by implementing as a layered file system, so we control the
caching of the clear data.

This is exactly the way how we’ve done it. But this is also
one of most problematic thing in filter world.

Could you tell me how you handle custom IOCTLs,
which receive a file handle in the data structure (e.g. defragmentation
API or offline folders ?)

I guess another question is how do you know that an application of some
name
is the ‘real’ application? Key management is another problem.

I think it is enough to test the application name in
the EPROCESS structure. I know that there is not enough
space for the possible long EXE name, but if you check
for the same name as in Task manager (which - i think -
also shows the name from the EPROCESS), it is sufficient
for distinguishing one app from another.

Yeah, I know about the “real” application problem and have educated the
customer. They are trying to insist on a password prompt triggered by the
create, I’ve suggested this is not viable approach.

It IS a viable approach. You only cannot require the encryption key
and password on EVERY create (because you would get crazy
then, there are tens of CREATEs during e.g. when MS Word
opens a document).

L.

OSR_Community_User · April 4, 2005, 2:28am

> I think it is enough to test the application name in

the EPROCESS structure. I know that there is not enough
space for the possible long EXE name, but if you check

IIRC this is name is a) ANSI single-byte b) 8.3

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · April 4, 2005, 2:51am

> I think it is enough to test the application name in

the EPROCESS structure. I know that there is not enough
space for the possible long EXE name, but if you check

The “ImageFileName” in the EPROCESS has 16 CHARs,
so you’re right. But I think testing this name
by this name is still better than version-dependent looking
for the FileObject in the EPROCESS.

I admit there might be two applications of the same name,
but in praxis, I think it is very unprobable.

Until Microsoft will not give us a mechanism to get the full image
file name of the process, we can’t do more.

L.

OSR_Community_User · April 4, 2005, 6:55am

Handles are always problematic - you have to find the corresponding file
object and map it to the correct internal state, unfortunately, and then
determine how to handle it based upon the provided information. That’s
going to depend upon the IOCTL and how you choose to implement it (first
implementation: just say no…)

Testing the name in EPROCESS is not sufficient. For example, there are
KNOWN hoax services called svchost.exe that ALREADY EXIST today,
precisely for the purpose of spoofing the OS. You need to know the path
to the binary as well as the name. Plus, spoofing such information is
not so hard because once I install your program I know the name of your
service. If I really want to compromise your driver, that’s where I’ll
be focusing my efforts (especially after I find the string embedded in
your driver). Someone trying to actively compromise a system with your
driver will insist on this…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

And now off to teach file systems this week in Boston…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Monday, April 04, 2005 1:23 AM
To: ntfsd redirect
Subject: Re: [ntfsd] because my encrypted filter,winzip can’t handle
.zip file

Tony, David, Don,

The approach we’ve used is that you present two different views - as
if
they were two different files at least from the OS perspective. We
make
this work by implementing as a layered file system, so we control the
caching of the clear data.

This is exactly the way how we’ve done it. But this is also
one of most problematic thing in filter world.

Could you tell me how you handle custom IOCTLs,
which receive a file handle in the data structure (e.g. defragmentation
API or offline folders ?)

I guess another question is how do you know that an application of
some
name
is the ‘real’ application? Key management is another problem.

I think it is enough to test the application name in
the EPROCESS structure. I know that there is not enough
space for the possible long EXE name, but if you check
for the same name as in Task manager (which - i think -
also shows the name from the EPROCESS), it is sufficient
for distinguishing one app from another.

Yeah, I know about the “real” application problem and have educated
the
customer. They are trying to insist on a password prompt triggered by
the
create, I’ve suggested this is not viable approach.

It IS a viable approach. You only cannot require the encryption key
and password on EVERY create (because you would get crazy
then, there are tens of CREATEs during e.g. when MS Word
opens a document).

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · April 4, 2005, 7:23am

> Handles are always problematic - you have to find the corresponding file

object and map it to the correct internal state, unfortunately

Hm, we are doing it the same way, obviosly there’s
no better way.

Testing the name in EPROCESS is not sufficient. For example, there are
KNOWN hoax services called svchost.exe that ALREADY EXIST today,
precisely for the purpose of spoofing the OS. You need to know the path

This is true. But the only alternative I know is
to get the file object from EPROCESS and query for the full path.
This is not impossible, but the position of the data member
in the EPROCESS varies between OS versions and you must
manually add a support for every new OS (not speaking
about possibility to change that structure between service
packs, which makes that task nearly impossible
from the point of view of the driver).

I’m afraid even if you use some user mode service
for getting the file name, you will only get the same information
like the short ANSI 8.3 file name.

L.