Geoff Chappell, Software Analyst
An array of KSE_HOOK_COLLECTION structures provides the second level in the description of a driver shim. The top level of the description is a KSE_SHIM structure.
Microsoft’s name for this structure is known from symbol files for a driver (NDIS.SYS) that registers a shim and uses C++ for instantiating its KSE_HOOK_COLLECTION array as statically allocated data: the C++ decoration names the type. Microsoft’s names and types are not known for members, there being no type information in the symbol file.
The KSE_HOOK_COLLECTION is 0x0C and 0x18 bytes in 32-bit and 64-bit Windows 10, respectively.
|Offset (x86)||Offset (x64)||Size||Description|
|0x00||0x00||dword||type of collection:
0 to hook imports from kernel;
1 to hook imports from HAL;
2 to hook imports from named module;
3 to hook I/O requests and other driver functions;
4 for last collection in array
|0x04||0x08||pointer||for type 2 only: address of name of importing module, as null-terminated Unicode string|
|0x08||0x10||pointer||address of KSE_HOOK array|
For the last collection in the array, i.e., for type 4, all other members are ignored.
Each collection that has any other valid type must have a KSE_HOOK array. If instead the pointer is NULL, the shim that contains this collection cannot be registered.
Who’s to know how, but for the first two years of this page’s life, I had this name transcribed incorrectly as KSE_COLLECTION. That I looked again is only because Alex Ionescu’s Abusing the Kernel Shim Engine, apparently from a conference in June 2016 but available in this easily readable form only since March 2017, gave a different name but no indication of where he had got it from.