[Brock]

@EP_X0FF

[1] I've compiled a quick PoC using a small c-written driver, it simply supports a standard DriverEntry and DriverUnload routines and prints debug messages proving it bypassed DrvMon and was loaded successfully even with DrvMon's "deny drivers loading" checked. The messages can be seen with tools such as DbgView or you can just check any tool that lists currently loaded drivers, it will be present ;) I used Four-F's KMD Manager to dynamically load/unload the driver in a quick test I ran. Enjoy!

Download link http://www.mediafire.com/?bbztfzbpt64k4b0

To my knowledge no samples I have collected zeroes out the entry point so I don't have any "studio" malware samples if this is what you meant.

[2] Yes, whitelisting methods would work maybe in conjunction with some method such as calling sfc.dll!SfcIsFileProtected() on the target driver filename. If it is protected you could allow the driver attempting to load to do so, of course some additional security checks wouldn't hurt too just in case sfc.dll is compromised on disk or in memory or other such perversions. I think you get my point, regardless denying OS dependencies (system drivers) will lead to a frozen OS environment or a BSOD

[3] I'm running Windows XP x86 with SP3 on this machine. When I terminate DrvMon (with TaskMan) and attempt to rerun it after termination I get a BSOD. I will try to reproduce this later today and potentially send you a crash dump

[EP_X0FF]

@EP_X0FF

[1] I've compiled a quick PoC using a small c-written driver, it simply supports a standard DriverEntry and DriverUnload routines and prints debug messages proving it bypassed DrvMon and was loaded successfully even with DrvMon's "deny drivers loading" checked. The messages can be seen with tools such as DbgView or you can just check any tool that lists currently loaded drivers, it will be present ;) I used Four-F's KMD Manager to dynamically load/unload the driver in a quick test I ran. Enjoy!

Download link http://www.mediafire.com/?bbztfzbpt64k4b0

Yes thats nice trick. However it's bypassing also very easy and this will be implemented in next version. Thanks for info.

[2] Yes, whitelisting methods would work maybe in conjunction with some method such as calling sfc.dll!SfcIsFileProtected() on the target driver filename. If it is protected you could allow the driver attempting to load to do so, of course some additional security checks wouldn't hurt too just in case sfc.dll is compromised on disk or in memory or other such perversions. I think you get my point, regardless denying OS dependencies (system drivers) will lead to a frozen OS environment or a BSOD

Likely in future user defined white list (with some predefines) can be implemented. Currently we didn't faced any problems with Windows components while working with DrvMon.

[Brock]

@EP_X0FF:

To reproduce the Windows component blocking issue a simple test such as this works.

Try this under Windows XP x86. Open DrvMon and deny all driver loading, then right click the desktop choosing "properties" and then the "settings" tab which will show your display settings. Hopefully, vga.dll should attempt to load and since DrvMon denies this it will lock up or BSOD the system.

Looking forward to seeing a DrvMon v3. Best of luck

[r2nwcnydc]

[2] "Monitor->Deny drivers loading" is very unstable by design since you're denying all drivers from loading and in essence important OS drivers such as vga.dll (in XP) for example cannot load resulting in a one way ticket to a frozen OS environment if you're lucky, otherwise it's an instant BSOD! Perhaps you should allow "sfc protected" system files or something like this to automatically be permitted to load, this is basically what I did to solve the problem in my tools

In my experience blocking vga.dll from loading does not result in a BSOD or a frozen machine. The only time I've seen an issue with blocking those types of drivers, is when you return success even though you blocked the driver from loading. This blue screen happens because vga.dll is loaded using NtSetSystemInformation with SystemLoadGdiDriverInformation, which takes a SYSTEM_GDI_DRIVER_INFORMATION structure. Inside of this structure is a pointer to the entry point of the loaded image. The Windows function that calls NtSetSystemInformation to load vga.dll, does not check to ensure the entry point is valid, instead it checks the return code of the call and if it's >=0 it calls the entry point. So if you do not set the entry point to a valid location, Windows calls an invalid address from the kernel, which blue screens the machine.

I don't know if that is what EP_X0FF is doing in DrvMon, but this is what I've noticed over the years. If you have a driver blocking app that you wrote and you can reproduce this crash (and are willing to share the source or at least that bit of the source) without faking success from NtSetSystemInformation, please let me know. I'd be interested to see if I have been handling this issue properly in my programs.

[EP_X0FF]

DrvMon blocks drivers loading by patching their DriverEntry to return STATUS_UNSUCCESSFUL (for cleanup reasons). This is performed inside LoadImage notify callback.
This type of callbacks always called inside MmLoadSystemImage, which is directly called by NtSetSystemInformation.
Actually DrvMon don't care how drivers are being loaded - it works with their kernel code before it gained any execution control.

The vga.dll blocking in that way results in system freeze. However since this tool is not supposed to be running 24/7/365 and has a very specific purpose - this is not a critical issue or major flaw and casted as compatibility bug in todo list.

AFAIR described NtSetSystemInformation behavior is only valid for NT < 5.2 SP1.

[Brock]

I achieve the same thing with a load image callback / notify routine and inside the callback after calculating OEP I deny drivers with a STATUS_UNSUCCESSFUL return as well. This is the most practical and logical thing to do in my honest opinion. Faking STATUS_SUCCESS could potentially be a bad thing ;)

BYTE lpCode[8] = {0xB8, 0x01, 0x00, 0x00, 0xC0, 0xC2, 0x08, 0x00};
// MOV EAX, STATUS_UNSUCCESSFUL (0xC0000001)
// RETN 0x0008

[r2nwcnydc]

Just out of curiosity, why are you blocking drivers in this manner?

Also, I don't believe this method would block kernel mode "DLLs," as the DriverEntry routine is not called for these types of drivers. By kernel mode "DLL" I don't mean vga.dll (and similar drivers), I'm refering to drivers that only export functions for use by other drivers. It's probably not a method used right now, nor would not be trivial to implement. So you probably don't care about it right now, but I thought I would just throw it out there.

[EP_X0FF]

Because this allows Windows to automatically unload already mapped by MmLoadSystemImage drivers. And this not rely on any SSDT hooking/splicing etc.

export functions for use by other drivers

Before loading/using these functions exported by kernel mode library it's obviously needs to be loaded somehow by someone other.
Or you talking about something else?

[Brock]

I think r2nwcnydc is talking about TARGETTYPE=EXPORT_DRIVER which is a kernel mode DLL. It's like any other module loaded in kernel mode in respect to the fact that if it doesn't return STATUS_SUCCESS in its main routine it's immediately unmapped from memory, same rule applies to DriverEntry in standard/regular drivers obviously. Since we are both returning STATUS_UNSUCCESSFUL it should never be allowed to execute anything.

You can download an example here with a sample driver.

http://www.wd-3.com/downloads/kdll.zip

Load sample.sys after disallowing loaded drivers... It's successfully denied loading without a hitch so there is nothing to worry about, no bypass there.

[EP_X0FF]

@Brock

have you found any other system modules for whitelist except vga.dll?