I’m trying to intercept calls to FindFirstFile/ZwQueryDirectoryFile from a specific application from Minifilter. The goal is for the application to see a folder that doesn’t exist. So if the app enumerates files and folders from an empty folder C:\Temp, that application shouldn’t see that the folder is empty, instead it should see a folder in that directory (that I will provide in output result).
Now I understand that I need to modify DirectoryBuffer or Mdl buffer pointed by MdlAddress. Basically I need to return one more **FILE_BOTH_DIR_INFORMATION ** structure instance to the caller. Problem is that those buffers comes with fixed size, so I can not add anything in them.
So my question is:
-
What options do I have. Should I allocate a larger memory from non-paged pool and replace the DirectoryBuffer pointer in post operation (same with Mdl)? Will the caller be able to access that memory?
-
If so, what should I do with original buffer, should I free it?
-
If not how can I return a larger buffer to the caller in user mode?
I’m lost, any help would be greatly appreciated.
Thanks
Uuh, there is a lot of basic misconception about memory managenent here.
If this is for fun, sure. But otherwise you will cause a lot of BSODs.
Anyway, the simplest way is to wait for STATUS_NO_MORE_FILES or
STATUS_NO_SUCH_FILE return from the file system, placing your foldername in
the user’s buffer, and returning STATUS_SUCCESS.
If the user’s buffer is not large enough, return STATUS_BUFFER_OVERFLOW.
Thanks Dejan. Yes I had lots of misconception. I assumed a single post op callback of IRP_MJ_DIRECTORY_CONTROL contained all the files and folders in DirectoryBuffer because of _FILE_BOTH_DIR_INFORMATION::NextEntryOffset. Only after stumbling across ZwQueryDirectoryFile documentation page I understood how it worked. Anyway, thanks for the help
A top tip is that although there is no guarantee that directory results are ordered a great deal of badly coded applications assume an order. They are usually old enough to have been written for FAT. So if things appear to start going wrong that it a first port of call, but you really do not want to deal with that unless you absolutely have to.
@rod_widdowson said:
A top tip is that although there is no guarantee that directory results are ordered a great deal of badly coded applications assume an order. They are usually old enough to have been written for FAT. So if things appear to start going wrong that it a first port of call, but you really do not want to deal with that unless you absolutely have to.
Hey @rod_widdowson. Thanks for the help, I’m not really sure I understand what you mean. Actually I want my directory to be the first one, so I kind of assume an order. Kind of because I’m planning to return my directory on the first call of ZwQueryDirectoryFile and remaining calls will return “real” data. You mean I do not want to deal with this approach for some reason? Thanks again