What's done in a minifilter GsDriverEntry routine?

fafalone

I noticed that's where the entry point actually is. For KMDF drivers, it's clear what happens there, if unfortunately too poorly documented to understand much beyond a surface level. For minifilters, all the fltmgr.sys APIs show up in the IAT as direct imports and I don't see any imports not accounted for by user code that might be communicating with kernel components. Is there anything essential being done there? What happens if you set DriverEntry as the entry point?

Peter_Viscarola_(OSR)

Is there anything essential being done there

Yes.

What happens if you set DriverEntry as the entry point?

Things don't work properly.

I mean... disassemble and walk into the code if you need more than that, right?

fafalone

Well I have very, very little knowledge of assembly. I did dump the disassembly and it sure looks like it's not doing anything besides a buffer-overrun protection related __security_init_cookie routine. Can you share your expertise as to why this assessment is incorrect, and why, assuming I could do without buffer overrun protection (old-style WDM drivers obviously run without it), it would not work to skip it, or possibly call it myself?

GsDriverEntry:
  00000001400060A0: 48 89 5C 24 08     mov         qword ptr [rsp+8],rbx
  00000001400060A5: 57                 push        rdi
  00000001400060A6: 48 83 EC 20        sub         rsp,20h
  00000001400060AA: 48 8B DA           mov         rbx,rdx
  00000001400060AD: 48 8B F9           mov         rdi,rcx
  00000001400060B0: E8 17 00 00 00     call        __security_init_cookie
  00000001400060B5: 48 8B D3           mov         rdx,rbx
  00000001400060B8: 48 8B CF           mov         rcx,rdi
  00000001400060BB: E8 40 FF FF FF     call        DriverEntry
  00000001400060C0: 48 8B 5C 24 30     mov         rbx,qword ptr [rsp+30h]
  00000001400060C5: 48 83 C4 20        add         rsp,20h
  00000001400060C9: 5F                 pop         rdi
  00000001400060CA: C3                 ret
  00000001400060CB: CC                 int         3
__security_init_cookie:
  00000001400060CC: 48 8B 05 2D CF FF  mov         rax,qword ptr [__security_cookie]
                    FF
  00000001400060D3: 48 85 C0           test        rax,rax
  00000001400060D6: 74 1B              je          00000001400060F3
  00000001400060D8: 48 B9 32 A2 DF 2D  mov         rcx,2B992DDFA232h
                    99 2B 00 00
  00000001400060E2: 48 3B C1           cmp         rax,rcx
  00000001400060E5: 74 0C              je          00000001400060F3
  00000001400060E7: 48 F7 D0           not         rax
  00000001400060EA: 48 89 05 17 CF FF  mov         qword ptr [__security_cookie_complement],rax
                    FF
  00000001400060F1: C3                 ret
  00000001400060F2: CC                 int         3
  00000001400060F3: B9 06 00 00 00     mov         ecx,6
  00000001400060F8: CD 29              int         29h
  00000001400060FA: CC CC

Does the filter manager enforce the presence of this protection somehow?

Peter_Viscarola_(OSR)

it sure looks like it's not doing anything besides a buffer-overrun protection related __security_init_cookie routine

Your analysis is correct.

it would not work to skip it, or possibly call it myself

Why on EARTH would you want to do that?