KernelMode.info

TLDR: Why can't I register a file system filter using a driverless driver?

I've been experimenting for a month with process and file hiding using kernel mode drivers on Windows 64. I started by enabling debugging, and disabling signed drivers checks and Patchguard. Then I created a basic driver based on samples of EasyHook framework. I could load the driver easily using the provided loader without any problem.
Next step was hooking. I could easily implement file hiding but some strange reason I couldn't hide processes. Later (with your help) I found that the trampoline jump of the inline hook generated by EasyHook was trashing the RAX register, so I just had to replace it with code that can preserve the RAX register and it started working again.
Next, I worked on loading the driver with driver signing enabled. After many trials and errors, I could load the driver using TDL by modifying the driver to make it "driverless" (I'm not sure that this is the right term).
I did that by replacing the IoCreateDevice function with IoCreateDriver, giving it as a parameter an initialization method that is used to call the IoCreateDevice method in addition to other driver initialization procedures.
That driver worked on the latest versions of Windows 7, 8.1 and with everything enabled EXCEPT Patchguard. After spending sometime looking for workarounds for Patchguard, I saw that more recent articles talk about implementing file and process hiding functionalities using file system filters and callback functions, and I saw many recommendations for not using inline patching for kernel functions.
So I brought up the Microsoft samples for file system filters, compiled and ran it and it worked without any problem.
The problem happened when I added the same filter creation and registration code code to my "driverless" driver: it would always crash the system with Access Violation error message.
So my question is: are there any special requirements for these file system drivers?
At the stage that I reached developing this driver, what is the best step to be taken? using SSDT hooks? Inline hooks? disabling Patchguard in memory? or disabling it using a patch to Windows? is using filters a feasible solution?

AFAIK when registering as a FS Minifilter, or when using ObRegisterCallbacks or PsSetCreateProcessNotifyRoutineEx, the kernel performs certain checks that I consider quite annoying. It checks (not sure in the Minifilter case) whether the registering driver is digitaly signed. If not, you get STATUS_ACCESS_DENIED error code. Because such a check might be quite complex, I expect that the system really uses the DRIVER_OBJECT structure you passed to the registration function (so it might be quite hard to successfully pass a fake DRIVER_OBJECT to it).

Try to reverse the registration function(s) and you will see.

Force windows into debug mode. No patchguard, you can use your multiple hacks.

Vrtule wrote:AFAIK when registering as a FS Minifilter, or when using ObRegisterCallbacks or PsSetCreateProcessNotifyRoutineEx, the kernel performs certain checks that I consider quite annoying. It checks (not sure in the Minifilter case) whether the registering driver is digitaly signed. If not, you get STATUS_ACCESS_DENIED error code. Because such a check might be quite complex, I expect that the system really uses the DRIVER_OBJECT structure you passed to the registration function (so it might be quite hard to successfully pass a fake DRIVER_OBJECT to it).

Try to reverse the registration function(s) and you will see.

looks like I'm hitting a dead end! coz my only other option was using PsSetCreateProcessNotifyRoutineEx to inject a usermode DLL inside every new process...

EP_X0FF wrote:Force windows into debug mode. No patchguard, you can use your multiple hacks.

Wouldn't I need to disable secureboot to do that? I'm looking for a completely automated solution, no matte how complicated it is, without any user intervention.
As far as I know, secureboot cannot be disabled programmatically, or is there a workaround for that?

fifo_thekid wrote:

EP_X0FF wrote:Force windows into debug mode. No patchguard, you can use your multiple hacks.

Wouldn't I need to disable secureboot to do that? I'm looking for a completely automated solution, no matte how complicated it is, without any user intervention.
As far as I know, secureboot cannot be disabled programmatically, or is there a workaround for that?

Yes you need to disable secure boot first. Automatically? Are you writting rootkit?

yes and yes

Mod:
http://www.kernelmode.info/forum/viewtopic.php?f=8&t=16

NO ILLEGAL CONTENT. This means: no posting warez, cracked software, or talking about how to write viruses and trojans. We do not create malware here.