Minifilter and IRP_MJ_DIRECTORY_CONTROL post op

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:

  1. 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?

  2. If so, what should I do with original buffer, should I free it?

  3. 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 :slight_smile:

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 :slight_smile: