Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Minifilter and IRP_MJ_DIRECTORY_CONTROL post op

dato0011dato0011 Member Posts: 11

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

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 303
    via Email
    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.
  • dato0011dato0011 Member Posts: 11

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

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,121

    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.

  • dato0011dato0011 Member Posts: 11

    @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 :-)

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA