wincheck rc8.60

download
mirror
Changelog:

• add some support of meltdown patched kernels. It seems that Microsoft backported from w10 InterruptObject to KPRCB on windows 8.1. so all offsets below this field were shifted downward and previous version of wincheck produced BSODs
• add dumping of SYSTEM_KERNEL_VA_SHADOW_INFORMATION
• add support of windows 10 build 17063
• add lots of new WNF IDs names from ADK version 10.1.16299

wincheck rc8.59

download
mirror
Changelog:

• add support of numerous versions of windows 10 insider preview - up to ~17025
• add -dsip option to dump SIPs from crypt32.dll
• add -dac & -dsac options to dump activation contexts and system activation contexts. based on this code from @deroko
• add dumping of rpcrt4 security providers
• add dumping of ETW private loggers (-wmi option)
• add lots of WNF IDs names
• add dumping of registered with winnsi!NsiRpcRegisterChangeNotification notifications

crypt32.dll SIPs

in cool paper "subverting windows trust" was described mechanism of subject interface package (SIP)
Lets see how we can extract and dump them
Unfortunately list of SIPs inside crypt32.dll don't have name in .pdb. One way is to find it with help of IDA Pro from function FindDll:

  push    [ebp+nSize]                   ; nSize
  push    ebx                           ; lpDst
  push    [ebp+lpSrc]                   ; lpSrc
  call    ds:__imp__ExpandEnvironmentStringsW@12
  test    eax, eax
  jz      short loc_5CF28F50
  push    offset dll_cs
  call    ds:__imp__EnterCriticalSection@4
  mov     edi, dll_list ; linked list of SIPs
  test    edi, edi
  jz      short loc_5CF28F89

next_item:
  push    0FFFFFFFFh                    ; cchCount2
  push    dword ptr [edi+8]             ; lpString2
  push    0FFFFFFFFh                    ; cchCount1
  push    ebx                           ; lpString1
  push    1                             ; dwCmpFlags
  push    409h                          ; Locale
  call    ds:__imp__CompareStringW@24
  dec     eax
  sub     eax, 1
  jz      short loc_5CF28F41
  mov     edi, [edi+4]
  test    edi, edi
  jnz     short next_item

this address (I named it dll_list) contains head of linked list to SIPs structures like this:
struct sip_item
{
  sip_item *next;
  PVOID unk4;        // ptr to crypto32_dll_list_item
  const char *fname; // actually ends to end of sip_item
  PVOID pfn; // if function was resolved, else NULL
};

struct crypto32_dll_list_item
{
  PVOID unk;
  crypto32_dll_list_item *next;
  const wchar_t *dll_name;
  HANDLE base; // if dll was loaded - load base else NULL
  DWORD unk10;
  DWORD unk14;
  sip_item *func_items_list;
  PVOID unk20;
  PVOID unk24;
  PVOID unk28;
};

rpcrt4 security providers

Count of loaded providers stored in rpcrt4!LoadedProviders and list in rpcrt4!ProviderList
Structure of each provider can be partially recovered from function FindSecurityPackage:
struct _rpc_loaded_provider
{
  DWORD unk1;
  PVOID unk2;
  PSecurityFunctionTable table; 
  PVOID unk3;
  PVOID unk4;
}; // size of struct 0x14 for x86 and 0x28 for x64


It's interesting that the function of InitSecurityFunctionTable patches the contents of SECURITY_FUNCTION_TABLE. Sample of output from w8.1:

how to find rpcrt4!GlobalRpcServer

I looked through sources of rpcview and found that they used some kind of brute-force in file RpcCore.c in function GetRpcServerAddressInProcess. It looks very strange and slow - they already has some code for pdb reading, so why not just ask address of ?GlobalRpcServer@@3PEAVRPC_SERVER@@EA ?

Anyway there is better way. Lets run my exref.pl in IDA Pro on rpcrt4.dll from windows 10 build 16278:
_I_RpcServerUseProtseq2W@20: 4EFACEB0 addr 4EFACEED
_RpcServerInqBindings@4: 4EFADA90 addr 4EFADAAC
_RpcServerRegisterIfEx@24: 4EFADCB0 addr 4EFADCCC
_RpcMgmtIsServerListening@4: 4EFAE470 addr 4EFAE48D
_RpcServerInterfaceGroupActivate@4: 4EFAE5B0 addr 4EFAE5C2
_RpcServerInterfaceGroupDeactivate@8: 4EFAE5E0 addr 4EFAE5F2
_I_RpcServerUseProtseqEp2W@24: 4EFB33E0 addr 4EFB33FF
_RpcServerUnregisterIf@12: 4EFB50B0 addr 4EFB50C5
_RpcServerRegisterIf3@32: 4EFB51F0 addr 4EFB5222
_RpcServerRegisterIf2@28: 4EFDFF40 addr 4EFDFF5C
_RpcServerInqBindingsEx@8: 4EFE0080 addr 4EFE0098
_RpcServerRegisterIf@12: 4EFE02E0 addr 4EFE02F5
_I_RpcServerRegisterForwardFunction@4: 4EFE03E0 addr 4EFE03F2
_RpcServerInterfaceGroupInqBindings@8: 4F0070D0 addr 4F0070E7
_RpcServerUseAllProtseqsEx@12: 4F007150 addr 4F00722C

wow, it seems that this will be easy
Lets look at exported function I_RpcServerRegisterForwardFunction:

W32pServiceTable from windows 10 build 16278

W32pServiceLimit .eq. 0x498

ETW private loggers

as you know ordinary etw loggers can be checked in compmgmt.msc\performance\data collector sets\event trace sessions
But private etw sessions cannot be showed in compmgmt.msc
Actually all private sessions stored in ntdll!EtwpLoggerArray. This array has size of 0x40 items (see allocation in function EtwpGetNextAvailableLoggerId) and looks like:

EtwpLoggerArray: 000000000524D380
00000000  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000010  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000020  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000030  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000040  80 6D 2B 05-01 00 00 00|01 00 00 00-00 00 00 00  Ђm+.............
00000050  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000060  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000070  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000080  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
00000090  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................
000000A0  01 00 00 00-00 00 00 00|01 00 00 00-00 00 00 00  ................