I'm curious about this __security_cookie that I keep seeing all over the msvcp140.dll from my Windows 10 x64 (insider build.)

Here's an example:

enter image description here

Note that the address for indirect function call (or qword_18009FBD0) is taken somewhere from the .data section:

enter image description here

Then it is XOR'ed with the __security_cookie:

enter image description here

I thought that __security_cookie is something that is used on the stack to guard against buffer-overflows. So they must be using some new security technique. Any idea what that is?

And a follow up question. I'm trying to statically analyze this binary code with IDA and this __security_cookie makes it very difficult to see what function is actually being called. For instance, here's how qword_18009FBD0 looks like:

enter image description here

Any idea how to make those function addresses more legible?

  • Probably similar with this.
    – Biswapriyo
    Commented Sep 24, 2019 at 17:02
  • @Biswapriyo no, it's not the "GS cookie", even though it uses the same global variable name. Look at it, it has nothing to do with stack canaries, or "buffer overflows".
    – c00000fd
    Commented Sep 24, 2019 at 19:41
  • a much easier approach: use visual studio cl.exe to compile a random c source, generating assembly listing with /Fa /FAs
    – Limina102
    Commented Jun 5 at 14:22

1 Answer 1


Look for the writes to the qword_18009FBD0 to see where it's initialized.

Apparently it's a part of an array called __encodedKERNEL32Functions where various pointers to kernel32 functions are stored after being XORed with __security_cookie. You can rename the pointer to the kernel32 function's name to better see what is happening:

  ;(from initialize_pointers)
  lea     rdx, aClosethreadpoo ; "CloseThreadpoolTimer"
  mov     rcx, rbx        ; hModule
  mov     cs:qword_180092498, rax
  call    cs:__imp_GetProcAddress
  xor     rax, cs:__security_cookie
  lea     rdx, aCreatethreadpo_0 ; "CreateThreadpoolWait"
  mov     rcx, rbx        ; hModule
  mov     cs:pCloseThreadpoolTimer_xored, rax ;<- variable renamed

__crtCloseThreadpoolTimer proc near 
                sub     rsp, 28h
                mov     rax, cs:pCloseThreadpoolTimer_xored
                xor     rax, cs:__security_cookie
                jz      short loc_180036A8A
                call    cs:__guard_dispatch_icall_fptr ; calls CloseThreadpoolTimer()
                add     rsp, 28h
__crtCloseThreadpoolTimer endp

This mitigation is not actually new and was already used in VS2013 CRT although in a slightly different form. It is probably aimed at reducing the number of available API pointers in standard CRT DLLs to make exploitation harder.

Although __security_cookie is most commonly used for protecting data on the stack (GS and EH cookies), nothing prevents programmers from using it for other purposes as a simple source of entropy.

  • Yeah, I saw that too. There's a large function that repeatedly calls GetProcAddress on various system functions and populates that array. Unfortunately I can't load symbols to see its name. By the way, do you know the name of this security mitigation that they are using there? I haven't seen this before, although it uses the name of the stack canary cookie.
    – c00000fd
    Commented Sep 24, 2019 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.