Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
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
It checks the
Iopb->Parameters.AcquireForSectionSynchronization.PageProtection as a means to tell if they're DLLs and looks for:
PAGE_EXECUTE | PAGE_EXECUTE_READ | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY
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?
|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|
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...