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


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:

Is there a way to block the load of .Net dlls via IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION?

BenStanifordBenStaniford Member Posts: 17

At present, a security tool I maintain can block the loading of DLLs into certain vulnerable processes by intercepting them being mapped into memory via a Pre callback on IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION.

It checks the Iopb->Parameters.AcquireForSectionSynchronization.PageProtection as a means to tell if they're DLLs and looks for:


Recently, we discovered that this method does not work for .NET DLLs since they're generally READ_ONLY data rather than executable pages. That's meant that we need a better way of identifying if the item being mapped into memory is actually a DLL.

The first approach we considered was simply looking at the file extension, but it seems as if that's prone to identification issues since you can call LoadLibrary() on more or less anything.

The second approach we tried works, and involves examining the PE header on the actual file being mapped by reading from the FILE_OBJECT. We're worried about the performance implications of this and I was wondering if there was a better approach or if it made more sense to switch our blocking to the Post IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION and examine the PE header in memory in the user process after the memory was mapped.

Is there a reason this would be a bad idea? I'm aware we'd need to wrap the examination of the user mode memory in structured exception handling and I'm assuming we can get to the correct memory location by looking at:


One of the things that worried me about doing this was that it looked as though I'd have to use the nt!_SEGMENT structure which looks to be undocumented and may change.

Is there a better approach we could use here? Or one that would allow us to safely examine the in-memory PE header from this filter callback?


  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,556
    edited March 10

    Can you capture a ProcMon trace or provide an easy way to reproduce what you're seeing? This is both for my own curiosity and so that I can try to give a complete answer...

    Few things:

    1. IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION is the notice that the section is being created so you're not guaranteed that it's actually mapped anywhere at that point. The notification of the mapping comes in via PsSetImageLoadNotifyRoutine, but that's informational only (i.e. you can't fail it)
    2. Digging into these structures is going to be a recipe for disaster...They're likely to change and there's a lot of locking involved in mucking with them.
    3. You can always create your own section with FltCreateSectionForDataScan and use that to get a mapping. I've never tried to call this in the PreAcquireForSectionSynchronization directly, but I've absolutely held up that operation while I mapped the file from another process (e.g. to generate file hashes and whatnot).


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online
Writing WDF Drivers 22 May 2023 Live, Online