fltmgr.GLOBALS!PerfTraceRoutines

In windows 8 in fltmgr was introduced feature for filter operation Etw logging - structure WMI_FLTIO_NOTIFY_ROUTINES in GLOBALS:
 void  (TimeStampRoutine*)(struct _ETW_KERNEL_TRACE_TIMESTAMP*, unsigned long);
 void  (FailureNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short);
 void  (InitiationNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short);
 void  (CompletionNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short, struct _ETW_KERNEL_TRACE_TIMESTAMP*);

 void  (FastCompletionNotifyRoutine*)(void*, unsigned long, unsigned long, unsigned short, struct _ETW_KERNEL_TRACE_TIMESTAMP*);

in windows 10 new entry was added:
void  (IoRedirectionNotifyRoutine*)(struct _IRP*, struct _FILE_OBJECT*);

This structure initialized in DriverEntry - PerfTraceRoutines assigned address of GLOBALS.DummyPerfTraceRoutines and then called function WmiQueryTraceInformation with class FltIoNotifyRoutinesClass (where this structure filled with content of EtwpFltIoNotifyRoutines)
So patching this functions pointers you can have real-time info about operations in file filters (or perhaps disable Etw logging for them)

On freshly installed system only two pfns are initialized:

FilterConnectionPorts

Under windows 10 there are some very strange objects in root directory

They are created by Filter Manager (fltmgr.sys) and is used for communication between user-mode applications and filesystem minifilters. Lets see how we can enumerate and dump this

fltmgr diagnostic messages

from driver verifier.Content of FltvMessageTable (to enlarge collection):

w8 consumer preview FLTMGR structs

It seems that wincheck cannot dump fltmgr callback nodes on consumer preview version of windows 8

fltmgr callback nodes

microsoft все же никак не может удержаться от использования недокументированных вещей. Вот например в wdk в файле fltKernel.h объявлены всякие внутренние MJ_XXX до -6 и начиная с -13. Промежуток в -7..-12 не описан никак, в том числе и в ф-ции fltmgr!FltGetIrpName имена для них возвращаются как IRP_MJ_RESERVED-YY
И тем не менее:
  IRP_MJ_FAST_IO_CHECK_IF_POSSIBLE: FFFFFA800E0D4320
   PreOperation:            FFFFF880026D8414 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RESERVED-12: FFFFFA800E0D4350
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RESERVED-11: FFFFFA800E0D4380
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RESERVED-10: FFFFFA800E0D43B0
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RESERVED-9: FFFFFA800E0D43E0
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RESERVED-8: FFFFFA800E0D4410
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RESERVED-7: FFFFFA800E0D4440
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000
  IRP_MJ_RELEASE_FOR_CC_FLUSH: FFFFFA800E0D4470
   PreOperation:            FFFFF880026D82D8 \SystemRoot\system32\drivers\luafv.sys
   PostOperation:           0000000000000000

Как туда попали, чем питаются что делают - неизвестно (c)

w8 FltpFilterVerifierThunks

в дополнение к

FltpFilterVerifierThunks

а вот например я уже писал про всякие ф-ции, перехватываемые Driver Verifier
Внезапно оказалось что такие ф-ции могут перехватываться не только из ntoskrnl, но и из любых других драйверов, имеющих соотв-щую поддержку
Собс-но поддержка заключается в вызове недокументированной ф-ции MmAddVerifierThunks, которой на вход приезжают два параметра:

struct vrf_thunk
{
 PVOID original_function;
 PVOID patched_function;
};

NTKERNELAPI NTSTATUS MmAddVerifierThunks(struct vrf_thunk *tab, ULONG tabSizeInBytes);


Driver Verifier патчит IAT подопытного драйвера, заменяя original_function на patched_function, которая в свою очередь делает все необходимые проверки (например своих параметров или IRQL) и вызывает original_function (или DbgPrintEx если чо-нть нашлось).

Например fltmgr поддерживает driver verifier, регистрируя в DriverEntry табличку FltpFilterVerifierThunks. Интересно, что число поддерживаемых ф-ций отличается в разных версиях windows:

fltmgr.sys 64bit exports

Должен признаться что в предыдущем посте я несколько ошибся - у fltmgr.sys есть механизмы для enumeration (просто я их ни разу не использовал). Нужно смотреть правда насколько сложно их пропатчить/обмануть