__security_init_cookie in the Windows driver causes a bugcheck error KERNEL_SECURITY_CHECK_FAILURE

Something very strange happens when I target Windows 8.1 when compiling my driver.

Once it loads, it is reset using the bugcheck KERNEL_SECURITY_CHECK_FAILURE , the first parameter of 6, which means " The stack cookie security cookie was not properly initialized by the loader ".

This may be caused by creating a driver to run only on Windows 8 and trying to load the driver image onto an earlier version of Windows. To avoid this problem, you must create a driver to run on an earlier version of Windows. " This error does not occur if I am targeting Windows 7.

I was able to pinpoint where this error is. This happens in the __security_init_cookie function, which is called by GsDriverEntry .

 INIT:000000014000C1B4 __security_init_cookie proc near ; CODE XREF: GsDriverEntry+10p INIT:000000014000C1B4 mov rax, cs:__security_cookie INIT:000000014000C1BB test rax, rax INIT:000000014000C1BE jz short loc_14000C1DA INIT:000000014000C1C0 mov rcx, 2B992DDFA232h INIT:000000014000C1CA cmp rax, rcx INIT:000000014000C1CD jz short loc_14000C1DA INIT:000000014000C1CF not rax INIT:000000014000C1D2 mov cs:__security_cookie_complement, rax INIT:000000014000C1D9 retn INIT:000000014000C1DA ; --------------------------------------------------------------------------- INIT:000000014000C1DA INIT:000000014000C1DA loc_14000C1DA: ; CODE XREF: __security_init_cookie+Aj INIT:000000014000C1DA ; __security_init_cookie+19j INIT:000000014000C1DA mov ecx, 6 INIT:000000014000C1DF int 29h ; Win8: RtlFailFast(ecx) 

It can be seen from this showdown that it performs 2 checks.

 The first check checks if rax (__security_cookie) is zero and the second check compares it to 2B992DDFA232h. 

However, __security_cookie declared in my binary format as 2B992DDFA232h , and therefore the interrupt should never be called, but somehow it is.

+7
windows driver wdk
source share
2 answers

Windows 8+ can generate a cookie for the downloaded executable image. The location of the cookie is stored in the Data LoadConfig directory in the PE header so that the Windows loader can easily replace it.
The reason is that the OS must be able to generate cookies in a safe way (for example, using the RDRAND instruction, if available, and / or other sources of random entropy). There is also no need to copy the cookie initialization code for each driver.

If your driver targets Windows 8 (or later), it expects the OS to initialize the cookie. Therefore, it raises the BSOD if the cookie has not been changed.
On the other hand, if your driver targets an older OS (Windows 7), the compiler must generate code that initializes the cookie if it has not yet been initialized by the OS. Thus, the driver is compatible with all versions of Windows.

I did not find an official description of this feature in Windows 8, but here is an article that describes it:
Windows8 Reversal: Interesting Kernel Security Features

When the kernel driver is loaded, Windows 8 calls MiProcessLoadConfigForDriver to generate a security cookie, finds the old security cookie in PE, and replaces it.

New Windows8 kernel drivers will check, replaced.

+3
source share

For those who create drivers in Visual studio 2015. If you need a driver for compatibility with Windows 7.

  • You need the Windows 10 sdk and the corresponding WDK (the changes must match).
  • In your driver project, use the target platform Target Target Version version 10.xxx and the default platform toolkit, that is, WindowsKernelModeDriver10. Do not change anything here. And do not touch the definition of _WIN32_WINNT.
  • The platform is listed in the "Driver Settings" - "General" section. There you indicate the target OS version - Windows 7, Target Platform - Desktop. AND ONLY THIS IS ONE. If you specify Windows 8 or Windows 8.1, the security cookie verification code will still fail.

The ps driver will still be compatible with windows 10, 8.1 and 8.

+2
source share

All Articles