Hello,
Is there any way a process could enumerate the contents of a folder without an IRP_MN_QUERY_DIRECTORY or IRP_MN_NOTIFY_CHANGE_DIRECTORY being issued on NTFS?
I am asking b/c I am filtering out a bunch of files so that a specific process will not know they exist. However, after I filter out the files, the process follows up with a series of IRP_MJ_QUERY_INFORMATION requests for each of the files. So, somehow it still knows about them.
I don’t think I am ignoring any irps I need to see. I also checked to see if it monitors the files via IRP_MN_NOTIFY_CHANGE_DIRECTORY, but I never get a IRP_MN_NOTIFY_CHANGE_DIRECTORY from this process and confirmed with FileMon.
This is a third-party process, so it can’t have anything hardcoded for random files I create.
The ultimate goal here is to prevent the process from sending the IRP_MJ_QUERY_INFORMATION requests. If it doesn’t know about the files, it shouldn’t send them.
Any ideas?
> Is there any way a process could enumerate the contents of a folder without an IRP_MN_QUERY_DIRECTORY or IRP_MN_NOTIFY_CHANGE_DIRECTORY being issued on NTFS?
Only by bypassing NTFS and going straight to disk structure.
Any ideas?
Are you handling ALL 6 File Information classes?
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
> Are you handling ALL 6 File Information classes?
No, but I do check for them and I have never received any requests for anything other than FileBothDirInformation from this process. For development purposes I haven’t coded that yet, but I will for the final product.
the only tip that I can give you is look more carefully with filemon, and also get process explorer and find any process strings (the process might try to open files that he “thinks” might be in that directory).
The best idea that you could implement is restrict access to that certain directory, for the process, not by filtering IRP_MJ_DIRECTORY_CONTROL but by restricting IRP_MJ_CREATE’s with the \Device\HardDiskVolumeXXX\FolderPath path. Deny this irp and for the process, and it won’t even call IRP_MJ_DIRECTORY_CONTROL for sure.
Good luck.
What OS?
wrote in message news:xxxxx@ntfsd…
>> Are you handling ALL 6 File Information classes?
>
> No, but I do check for them and I have never received any requests for
> anything other than FileBothDirInformation from this process. For
> development purposes I haven’t coded that yet, but I will for the final
> product.
>
> What OS?
Currently testing on XP SP2, but I suspect the same behavior would happen on W2K3 as well.
I’ll bet you are not actually handling all the info classes. There’s no other way to
enumerate a directory. (unless the app has a driver to do it, but that would be… plain
stupid)
xxxxx@charter.net wrote:
> What OS?
Currently testing on XP SP2, but I suspect the same behavior would happen on W2K3 as well.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
I have an if statement testing for cases where the info class is not FileBothDirectoryInformation and a DbgPrint statement to alert me. The DbgPrint statement never executes. I wish it were that simple.
Well, what does FileMon/FileSpy output say?
xxxxx@charter.net wrote:
I have an if statement testing for cases where the info class is not FileBothDirectoryInformation and a DbgPrint statement to alert me. The DbgPrint statement never executes. I wish it were that simple.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Just an info. I can confirm that other information classes are heavily used on vista platform.
I am using Process Monitor, but it shows the process doing the directory control to enum the files, it then closes the folder and opens it again, and then begins a series of IRP_MJ_QUERY_INFORMATION requests via both fastio and non-fastio. All of these operations are successful, except for a few of the fast io ops that indicate fast io is not allowed.
Basically the output looks exactly like I am not filtering anything at all. I know this isn’t the case, b/c if I were not filtering, the process would copy some files that I filter out.
Thanks Bronislav. I will keep that in mind.
If I were you I would write UM test application to verify your filtering works fine. Do you only change next entry offset or are you also shrinking buffer? Aren’t filenames somehow hardcoded in the application? Try also filespy monitor(www.zezula.net). It shows you in tooltip the list of returned files.
> write UM test application to verify your filtering works
I think I will give this a try. Might make it easier to troubleshoot as well.
Do you only change next entry offset or are you also shrinking buffer?
I use the buffer swapping technique from the swapbuffer sample to create a new buffer. I then decide if I want the process to know about the files. If I want the process to know about the file or folder, I add it to the new buffer. If not I don’t. When the DC is complete, I copy the new buffer back into the old buffer.
Aren’t filenames somehow hardcoded in the application?
How could the file names be hardcoded in the application if they didn’t exist when the app was written?
There is one more source of information about new file creation - USN
journal. You may check if it is enabled on the volume.
Alexei.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@charter.net
Sent: Friday, October 12, 2007 9:13 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] IRP_MJ_DIRECTORY_CONTROL
write UM test application to verify your filtering works
I think I will give this a try. Might make it easier to troubleshoot as
well.
Do you only change next entry offset or are you also shrinking buffer?
I use the buffer swapping technique from the swapbuffer sample to create a
new buffer. I then decide if I want the process to know about the files. If
I want the process to know about the file or folder, I add it to the new
buffer. If not I don’t. When the DC is complete, I copy the new buffer back
into the old buffer.
Aren’t filenames somehow hardcoded in the application?
How could the file names be hardcoded in the application if they didn’t exist
when the app was written?
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> write UM test application to verify your filtering works
>I think I will give this a try. Might make it easier to troubleshoot as well.
Filter works fine. FindFirstFile and FindNextFile are not able to see the files when I filter them out.
The files that I am filtering out have the offline bit set. I use the offline files as placeholders only and I have not enabled any OS offline file handling as far as I know. Does that offer any clues?
>There is one more source of information about new file creation - USN
Journal. You may check if it is enabled on the volume.
It’s not enabled.
I think I found the problem and it had nothing to do with any stealthy activity by the process. I had a very hard to find bug in my code that prevented me from removing the filtered files from the buffer if all of the files found should be removed.
Thank you all for your help. Sorry it wasn’t something more interesting.