File System Filter Using a Driverless Driver

Ask your beginner questions here.
Locked
fifo_thekid
Posts: 11
Joined: Mon Feb 29, 2016 4:09 am

File System Filter Using a Driverless Driver

Post by fifo_thekid » Fri Mar 18, 2016 5:53 am

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?

User avatar
Vrtule
Posts: 464
Joined: Sat Mar 13, 2010 9:14 pm
Location: Czech Republic
Contact:

Re: File System Filter Using a Driverless Driver

Post by Vrtule » Fri Mar 18, 2016 7:30 am

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.

User avatar
EP_X0FF
Global Moderator
Posts: 4882
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: File System Filter Using a Driverless Driver

Post by EP_X0FF » Fri Mar 18, 2016 7:37 am

Force windows into debug mode. No patchguard, you can use your multiple hacks.
Ring0 - the source of inspiration

fifo_thekid
Posts: 11
Joined: Mon Feb 29, 2016 4:09 am

Re: File System Filter Using a Driverless Driver

Post by fifo_thekid » Fri Mar 18, 2016 9:11 pm

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...

fifo_thekid
Posts: 11
Joined: Mon Feb 29, 2016 4:09 am

Re: File System Filter Using a Driverless Driver

Post by fifo_thekid » Fri Mar 18, 2016 9:13 pm

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?

User avatar
EP_X0FF
Global Moderator
Posts: 4882
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: File System Filter Using a Driverless Driver

Post by EP_X0FF » Sat Mar 19, 2016 3:40 am

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?
Ring0 - the source of inspiration

fifo_thekid
Posts: 11
Joined: Mon Feb 29, 2016 4:09 am

Re: File System Filter Using a Driverless Driver

Post by fifo_thekid » Sat Mar 19, 2016 7:58 pm

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.
Last edited by EP_X0FF on Mon Jun 27, 2016 6:28 am, edited 1 time in total.
Reason: See comment

Locked