NtCreateSection and IRP_MJ_CREATE

NTFSD
1

I am rewriting a legacy device driver that used the “hooked syscall” method to redirect the NtCreateFile, NtOpenFile, NtCreateSection and NtOpenSection syscalls. This method won’t work with the 64-bit OSs due to the MS kernel patch. The legacy filter looked for specific file names and when found, redirected them to its own internal files to be opened instead.

I am planning on using the minifilter approach, based on the Microsoft supplied simrep minifilter sample. I know I can intercept the IRP_MJ_CREATE Irp to redirect the NtCreateFile and NtOpenFile calls, but I am concerned about the Section calls. I am not sure if the section calls come through IRP_MJ_CREATE with different flags or not at all, and I can find no specific references in MSDN. I saw some reference on this forum that they do not go through IRP_MJ_CREATE. Since the previous developer told me that often the calls come through as Section calls, I know I have to handle this case.

Can you tell me if there is a way to intercept the NtSectionCreate/Open calls and also verify that my decision to use the minifilter simrep sample is the right way to go?

Thanks!

2

NtCreateSection operates on a file handle and not a file name. What was your NtCreateSection hook really doing?

  • S

-----Original Message-----
From: xxxxx@grammatech.com
Sent: Friday, March 13, 2009 09:21
To: Windows File Systems Devs Interest List
Subject: [ntfsd] NtCreateSection and IRP_MJ_CREATE

I am rewriting a legacy device driver that used the “hooked syscall” method to redirect the NtCreateFile, NtOpenFile, NtCreateSection and NtOpenSection syscalls. This method won’t work with the 64-bit OSs due to the MS kernel patch. The legacy filter looked for specific file names and when found, redirected them to its own internal files to be opened instead.

I am planning on using the minifilter approach, based on the Microsoft supplied simrep minifilter sample. I know I can intercept the IRP_MJ_CREATE Irp to redirect the NtCreateFile and NtOpenFile calls, but I am concerned about the Section calls. I am not sure if the section calls come through IRP_MJ_CREATE with different flags or not at all, and I can find no specific references in MSDN. I saw some reference on this forum that they do not go through IRP_MJ_CREATE. Since the previous developer told me that often the calls come through as Section calls, I know I have to handle this case.

Can you tell me if there is a way to intercept the NtSectionCreate/Open calls and also verify that my decision to use the minifilter simrep sample is the right way to go?

Thanks!

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Apparently it is expected that the incoming ObjectAttributes->ObjectName for either NtCreateFile or NtCreateSection contains the file name.

The hooked functions are really pretty simple. The hooked function would first call the “real” NtCreateSection. If it succeeded, it would compare the ObjectAttributes->ObjectName to known strings for files we want to redirect. If it matched, it would close the previously returned handle and call the NtCreateSection again with a new file name set into the ObjectAttributes->ObjectName. If it didn’t match, it just leaves the handle open and returns success.

The only special handling I see in the code for the Section case is this block (called after the initial NtCreateSection) which avoids redirection:

if( SectionDesiredAccess &
( SECTION_MAP_WRITE |
SECTION_EXTEND_SIZE ) )
return STATUS_SUCCESS;

Thanks!

4

It’s good that you’re trying to move away from that model, as it’s an enormous mine field of time of check/time of use security issues.

That being said, the object name passed to NtCreateSection is, as the public documentation implies, the name of the section object itself, and not a file name. The two are completely unrelated. For example, if you create a named file mapping object with CreateFileMapping, that would end up being the name of the underlying section object.

If you are really operating on the object name of the *section*, then it sounds to me like the code you’ve got there with your hook never worked to do anything useful anyway.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@grammatech.com
Sent: Friday, March 13, 2009 11:13 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] NtCreateSection and IRP_MJ_CREATE

Apparently it is expected that the incoming ObjectAttributes->ObjectName for either NtCreateFile or NtCreateSection contains the file name.

The hooked functions are really pretty simple. The hooked function would first call the “real” NtCreateSection. If it succeeded, it would compare the ObjectAttributes->ObjectName to known strings for files we want to redirect. If it matched, it would close the previously returned handle and call the NtCreateSection again with a new file name set into the ObjectAttributes->ObjectName. If it didn’t match, it just leaves the handle open and returns success.

The only special handling I see in the code for the Section case is this block (called after the initial NtCreateSection) which avoids redirection:

if( SectionDesiredAccess &
( SECTION_MAP_WRITE |
SECTION_EXTEND_SIZE ) )
return STATUS_SUCCESS;

Thanks!

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Interesting. I did notice in the code for the NtCreateSection hooker that the ObjectAttributes was never swapped (as it was in the other 3 cases - NtCreateFile, NtOpenFile, and NtOpenSection). I am guessing this was a cut/paste error, but since it is in production code, it would seem that either:

  1. that function was never called;
  2. the “if ( SectionDesiredAccess)” condition listed in my previous post was always true; or,
  3. there is a serious but previously undiscovered bug in the code.

The previous developer still seems to believe that the Section entries are sometimes called. Once I get my minifilter up and running, if it is missing this functionality, I will ask some more questions.

But in the meantime, I really appreciate your quick responses!! It’s nice to know there’s help out there when working on something like this!