I’m having a problem with my file system filter driver (decrypt on
read, encrypt on write).
It is decrypting files on paged i/o reads.
The OS is Windows XP SP2.
The problem is that I have 1 file
(c:\temp\THIS_DIRECTORY_IS_ENCRYPTED.TXT 52 bytes) that is not
decrypted after I open it with notepad after reboot. If I wait about 1
minute after reboot, everything is working as expected.
The interesting part is that it is only this file. I have no problems
with other files.
I know the filter is started because it can decrypt other files just
after reboot without any issues.
How can this be happening?
What would you advise to track the cause of this?
I cannot tell you where the problem is (from your description),
but it seems that you have a bug in implementation of
IRP_MJ_READ. Maybe your filter does not start
soon enough ?
L.
Here’s the code:
USHORT EncDirectory[6] = {‘\’, ‘t’, ‘e’, ‘m’, ‘p’, ‘\’};
NTSTATUS
SfRead (
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp);
if (irpSp->FileObject == NULL)
goto exit_pass;
if (irpSp->FileObject->FileName.Length < 7 * 2)
goto exit_pass;
if (memcmp(EncDirectory,
(PUSHORT)irpSp->FileObject->FileName.Buffer, 6 * 2) != 0)
goto exit_pass;
_asm int 3;
…
I modified it to check for file name in the begginning if dispatch routine.
So as soon as windows boots I go to start->run and enter the file name
I’m having problems with. And nothing. The notepad opens the file but
the breakpoint is not called.
Open another file in c:\temp directory and everything is OK.
Reboot the windows, wait 1 minute, and then open the file I’m having
problems with - again no problems - the breakpoint is called.
On Thu, 3 Mar 2005 07:39:01 +0100, Ladislav Zezula wrote:
> I cannot tell you where the problem is (from your description),
> but it seems that you have a bug in implementation of
> IRP_MJ_READ. Maybe your filter does not start
> soon enough ?
>
> L.
Well, there are some bad things I see
-
You are checking the file name in read handler.
The file name is valid in create handler only.
-
Don’t test the file name using memcmp.
memcmp is case sensitive, is will consider “FILE.TXT”
and “file.txt” to be different. Applications normally don’t
care about case sensitiveness and often send requests
with uppersase and lowercase together.
-
You are ignoring relative opens. The "\temp"
folder might not be pasrt of the file name,
it may be in FileObject->RelatedFileObject->FileName.
And again, RelatedFileObject is valid only in create.
-
You have probably used SFilter for creating an encryption driver.
I think it is not possible to write a data modification filter using the
“I-take-an-example-and-add-some-few-lines-of-code”
method. Expect much problems with this approach, the
problems that you currently have are only the beginning.
L.
On Thu, 3 Mar 2005 09:28:44 +0100, Ladislav Zezula wrote:
> Well, there are some bad things I see
>
> 1) You are checking the file name in read handler.
> The file name is valid in create handler only.
Thanks. This must be it but I’m still not getting anything.
I verified that file indeed is opened (IRP_MJ_CREATE) and saved the
FileObject pointer in create dispatch.
Still the IRP_MJ_READ dispatch with FileObject equaling to saved
pointer is not called for this particular file.
Again everything works just fine for other files or this file after
1min wait after reboot.
I suppose the FileObject should be the same in paging
IRP_MJ_READ/WRITE, shouldn’t it? If not what is the best approach to
id the file in read/write dispatch?
> 2) Don’t test the file name using memcmp.
> memcmp is case sensitive, is will consider “FILE.TXT”
> and “file.txt” to be different. Applications normally don’t
> care about case sensitiveness and often send requests
> with uppersase and lowercase together.
>
> 3) You are ignoring relative opens. The "\temp"
> folder might not be pasrt of the file name,
> it may be in FileObject->RelatedFileObject->FileName.
> And again, RelatedFileObject is valid only in create.
Yes, I know that, but this code was just for a quick and dirty test.
I’m sure that it’s using full path and lowercase for this particular
test.
> 4) You have probably used SFilter for creating an encryption driver.
> I think it is not possible to write a data modification filter using the
> “I-take-an-example-and-add-some-few-lines-of-code”
> method. Expect much problems with this approach, the
> problems that you currently have are only the beginning.
The encryption/decryption is working fine, I’m just having problems
identifying which files I need to encrypt/decrypt.
> I suppose the FileObject should be the same in paging
IRP_MJ_READ/WRITE, shouldn’t it? If not what is the best approach to
id the file in read/write dispatch?
Maybe, but maybe not. What you should save
is not the file object but the FCB (FileObject->FsContext).
FCB is guaranteed to be the same for multiple instances
of one open file (i.e. for multiple file objects)
Yes, I know that, but this code was just for a quick and dirty test.
I’m sure that it’s using full path and lowercase for this particular
test.
If you say so … 
The encryption/decryption is working fine, I’m just having problems
identifying which files I need to encrypt/decrypt.
Yes, to identifying the file is one of the more difficult tasks.
Remember that the file name can come as the short name
(c:\temp\THIS_D~1.TXT).
L.
On Thu, 3 Mar 2005 12:26:35 +0100, Ladislav Zezula wrote:
> > I suppose the FileObject should be the same in paging
> > IRP_MJ_READ/WRITE, shouldn’t it? If not what is the best approach to
> > id the file in read/write dispatch?
>
> Maybe, but maybe not. What you should save
> is not the file object but the FCB (FileObject->FsContext).
> FCB is guaranteed to be the same for multiple instances
> of one open file (i.e. for multiple file objects)
No luck with that either.
Tried even setting Fcb->Reserved to mark file.
I see the IRP_MJ_CREATE (so no problem identifying the file), but
can’t see IRP_MJ_READ with the same FileObject->FsContext or
FsContext->Reserved marked.
Is there any other way for windows to read the file? Why would it work
after 1 minute after reboot?
Could it be that the file is incorrectly stored on file system or smth
like that?
> > Yes, I know that, but this code was just for a quick and dirty test.
> > I’m sure that it’s using full path and lowercase for this particular
> > test.
>
> If you say so …
FWIW I get the IRP_MJ_CREATE for this file.
> > The encryption/decryption is working fine, I’m just having problems
> > identifying which files I need to encrypt/decrypt.
>
> Yes, to identifying the file is one of the more difficult tasks.
> Remember that the file name can come as the short name
> (c:\temp\THIS_D~1.TXT).
There is no other read path; there are no “secret handshakes” or
clandestine mechanisms for reading data. If you aren’t seeing the read,
it is because you are missing it - either it happens before you are
looking or it happens through an operation you are ignoring because the
logic in your driver is faulty.
The fact that you see an IRP_MJ_CREATE but no read, but then after a
period of time it works again suggests to me that you are missing an
earlier read - that the data is loaded into VM. Given sufficient time,
the memory is recycled so the next time you access the file it must be
re-read into memory.
Here’s one way to check if this is the case: in IRP_MJ_CREATE
post-processing, check to see if
FileObject->SectionObjectPointers->DataSectionObject is non-zero. If it
is, the data is already in memory.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kriloff
Sent: Thursday, March 03, 2005 7:02 AM
To: ntfsd redirect
Subject: Re: [ntfsd] IRP_MJ_READ not called
On Thu, 3 Mar 2005 12:26:35 +0100, Ladislav Zezula
wrote:
> > I suppose the FileObject should be the same in paging
> > IRP_MJ_READ/WRITE, shouldn’t it? If not what is the best approach to
> > id the file in read/write dispatch?
>
> Maybe, but maybe not. What you should save
> is not the file object but the FCB (FileObject->FsContext).
> FCB is guaranteed to be the same for multiple instances
> of one open file (i.e. for multiple file objects)
No luck with that either.
Tried even setting Fcb->Reserved to mark file.
I see the IRP_MJ_CREATE (so no problem identifying the file), but
can’t see IRP_MJ_READ with the same FileObject->FsContext or
FsContext->Reserved marked.
Is there any other way for windows to read the file? Why would it work
after 1 minute after reboot?
Could it be that the file is incorrectly stored on file system or smth
like that?
> > Yes, I know that, but this code was just for a quick and dirty test.
> > I’m sure that it’s using full path and lowercase for this particular
> > test.
>
> If you say so …
FWIW I get the IRP_MJ_CREATE for this file.
> > The encryption/decryption is working fine, I’m just having problems
> > identifying which files I need to encrypt/decrypt.
>
> Yes, to identifying the file is one of the more difficult tasks.
> Remember that the file name can come as the short name
> (c:\temp\THIS_D~1.TXT).
—
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
On Thu, 3 Mar 2005 07:31:11 -0500, Tony Mason wrote:
> The fact that you see an IRP_MJ_CREATE but no read, but then after a
> period of time it works again suggests to me that you are missing an
> earlier read - that the data is loaded into VM. Given sufficient time,
> the memory is recycled so the next time you access the file it must be
> re-read into memory.
>
> Here’s one way to check if this is the case: in IRP_MJ_CREATE
> post-processing, check to see if
> FileObject->SectionObjectPointers->DataSectionObject is non-zero. If it
> is, the data is already in memory.
Thank you. Indeed it was.
Problem solved.
StartType was “System” for my driver, changing to “Boot” fixed the problem.
Btw, why would windows cache this file
(c:\temp\THIS_DIRECTORY_IS_ENCRYPTED.TXT)?
> Btw, why would windows cache this file
(c:\temp\THIS_DIRECTORY_IS_ENCRYPTED.TXT)?
Don’t try to find why :-)) According to some my observations,
some files (e.g. Desktop.ini) are open event before
the Windows video mode is started :-)).
L.
Found out why.
c:\windows\prefetch
On Thu, 3 Mar 2005 14:49:12 +0100, Ladislav Zezula wrote:
> > Btw, why would windows cache this file
> > (c:\temp\THIS_DIRECTORY_IS_ENCRYPTED.TXT)?
>
> Don’t try to find why :-)) According to some my observations,
> some files (e.g. Desktop.ini) are open event before
> the Windows video mode is started :-)).