W32pServiceTable from windows 10 build 20292 64bit

 It seems that MS cut off whole apfnSimpleCall dispatching - no more functions

• NtUserCallHwndParamLock
• NtUserCallHwndParam
• NtUserCallHwndLockSafe
• NtUserCallHwndParamLockSafe
• NtUserCallHwndLock
• NtUserCallHwnd
• NtUserCallNoParam
• NtUserCallTwoParam
• NtUserCallOneParam
• NtUserCallHwndSafe
• NtUserCallHwndOpt

Instead all functions from apfnSimpleCall now exported and contained in W32pServiceTable. Like (just to name few):

• CreateMenu -> NtUserCreateMenu
• CreatePopupMenu -> NtUserCreatePopupMenu
• AllowForegroundActivation -> NtUserAllowForegroundActivation

etc etc

content of W32pServiceTable (W32pServiceLimit .eq. 0x5AA):

W32pServiceTable from windows 10 build 19577 64bit

W32pServiceLimit .eq. 0x5AD
Btw what does prefix NtModerncore mean?

Windows 10 1809 kernel sensors

After reading this article I was curious which info Mocrosoft gather in it`s telemetry. There is some theoretical possibility to ask Microsoft via MVI but link to "apply for membership" gives 404, lol. So as usually run IDA Pro and start with KeInsertQueueApc function

We can see that code checks EtwThreatIntProvRegHandle and somewhere inside function calls etw logger function EtwTiLogInsertQueueUserApc. So lets collect other etw loggers reffered to
EtwThreatIntProvRegHandle (and EtwSecurityMitigationsRegHandle too)

• EtwThreatIntProvRegHandle - called from KeInsertQueueApc and IopfCompleteRequest
• EtwTiLogSetContextThread - called from PspWow64SetContextThread & PspSetContextThreadInternal
• EtwTiLogAllocExecVm - called from MiAllocateVirtualMemory
• EtwTiLogProtectExecVm - called from NtProtectVirtualMemory
• EtwTiLogReadWriteVm - called from MiReadWriteVirtualMemory
• EtwTiLogDeviceObjectLoadUnload - called from IoDeleteDevice & IoCreateDevice
• EtwTiLogDriverObjectLoad - called from IopLoadDriver & IoCreateDriver
• EtwTiLogMapExecView - called from NtMapViewOfSection & MiMapViewOfSectionExCommon
• EtwTiLogSuspendResumeProcess - called from PsThawProcess, PsFreezeProcess, PsResumeProcess & PsSuspendProcess
• EtwTiLogSuspendResumeThread - called from PsSuspendThread & PsResumeThread

etw loggers reffered to EtwSecurityMitigationsRegHandle

• EtwpTimLogMitigationForProcess - called from MiAllowImageMap
• EtwTimLogProhibitDynamicCode - called from MiArbitraryCodeBlocked
• EtwTimLogProhibitWin32kSystemCalls - called from PsConvertToGuiThread
• EtwTimLogProhibitNonMicrosoftBinaries - called from MiValidateSectionSigningPolicy
• EtwTimLogProhibitChildProcessCreation - called from SeSubProcessToken
• EtwTimLogProhibitLowILImageMap - called from MiAllowImageMap

simple way to find PsKernelRangeList

It seems that since est. build 15025 to PsKernelRangeList was added absolute addresses of KUSER_SHARED_DATA.SystemCall and KUSER_SHARED_DATA.ProcessorFeatures
So now it can be trivially found with signature 0xFFFFF78000000308 (0xFFDF0308 for 32bit) in .data section
Lets see what is interesting in this list
Items in PsKernelRangeList can be described something like

struct protected_area
{
 PBYTE addr;
 PBYTE len;
};
Also it seems that new entries always adding in end of this list. On build 18312 this list contains

1. PspPicoProviderRoutines
2. 3 zero entry
3. MmUserProbeAddress (exported)
4. MmSystemRangeStart (exported)
5. MmHighestUserAddress (exported)
6. MmBadPointer (exported)
7. HvcallCodeVa
8. PsWin32NullCallBack
9. PspSystemMitigationOptions (size 0x10)
10. KdpBootedNodebug
11. KUSER_SHARED_DATA.SystemCall
12.  KUSER_SHARED_DATA.ProcessorFeatures
13. KiDynamicTraceEnabled
14. KiDynamicTraceCallouts (size 0x28 on 32bit, 0x50 on 64bit)

apisetschema.dll from windows 10 build 1774

new modules was added since 15025

• win-containers-cmclient
• win-core-backgroundtask
• win-core-com-private
• win-core-file-fromapp
• win-core-pcw
• win-core-state-helpers
• win-gaming-deviceinformation
• win-security-isolationapi
• win-security-isolationpolicy
• win-shcore-taskpool
• win-wsl-api
• win-appcompat-aeinv
• win-hostactivitymanager-hostidstore
• win-hyperv-hgs
• win-hyperv-hvemulation
• win-hyperv-hvplatform
• win-hyperv-compute
• win-networking-teredo
• win-rtcore-ntuser-controllernavigation
• win-security-authz-helper
• win-security-catalog-database
• ms-win-security-cfl
• win-security-ngc-local
• win-security-vaultcds
• win-session-candidateaccountmgr

W32pServiceTable from windows 10 build 16278

W32pServiceLimit .eq. 0x498

win32k calls filtering on w10

Lets see on some functions from W32pServiceTableFilter on w10 build 16215:
stub_UserSetSensorPresence:
  push    ebp
  mov     ebp, esp
  push    2 ; call index
  call    _IsWin32KSyscallFiltered@4    ; IsWin32KSyscallFiltered(x)
  test    al, al
  jz      short loc_1361D
  lea     ecx, aNtusersetsenso          ; "NtUserSetSensorPresence"
  mov     edx, 2
  call    @NtUserWin32kSysCallFilterStub@8 ; NtUserWin32kSysCallFilterStub(x,x)
  call    _PsIsWin32KFilterEnabled@0    ; PsIsWin32KFilterEnabled()
  test    al, al
  jz      short loc_1361D
  lea     edx, _W32pServiceTableFilter
  mov     ecx, cs:_W32pServiceLimitFilter
  mov     eax, 2 ; call index
  lea     edx, [edx+ecx*4]
  movsx   eax, byte ptr [eax+edx]
  or      eax, eax
  jle     short loc_13619
  mov     eax, 0C000001Ch ; STATUS_INVALID_SYSTEM_SERVICE
loc_13619:
  mov     esp, ebp
  pop     ebp
  retn
loc_1361D: ; call original function
  mov     esp, ebp
  pop     ebp
  jmp     _NtUserSetSensorPresence@4    ; NtUserSetSensorPresence(x)

In some case this stub just pass control to original function (NtUserSetSensorPresence in this case) if IsWin32KSyscallFiltered or PsIsWin32KFilterEnabled returned 0, returns STATUS_INVALID_SYSTEM_SERVICE or just do nothing. Last condition depends from byte stored with call index behind W32pServiceTableFilter, so we can write simple idc script to dump all functions which will return STATUS_INVALID_SYSTEM_SERVICE:
#include

static main(void)
{
  auto  cnt, addr, tab, ftab, i, fp, name;
  addr = LocByName("_W32pServiceLimitFilter");
  if ( addr == BADADDR )
  {
    Warn("Cannot find W32pServiceLimitFilter");
    return;
  }
  cnt = Dword(addr);
  tab = LocByName("_W32pServiceTableFilter");
  if ( tab == BADADDR )
  {
    Warn("Cannot find W32pServiceTableFilter");
    return;
  }
  ftab = cnt * 4 + tab;
  fp = fopen("wf32.dmp", "w");
  for ( i = 0; i < cnt; i++, tab = tab + 4, ftab = ftab + 1 )
  {
    if ( Byte(ftab) )
    {
      addr = Dword(tab);
      name = Name(addr);
      fprintf(fp, "[%d] \"%s\",\n", i, name);
    }
  }
  fclose(fp);
}

EPROCESS.MitigationFlags in w10 build 16215

Lets see EPROCESS.Flags3 in w10 build 16193:
unsigned long Flags3;
unsigned long Minimal:0:1;
unsigned long ReplacingPageRoot:1:1;
unsigned long DisableNonSystemFonts:2:1;
unsigned long AuditNonSystemFontLoading:3:1;
unsigned long Crashed:4:1;
unsigned long JobVadsAreTracked:5:1;
unsigned long VadTrackingDisabled:6:1;
unsigned long AuxiliaryProcess:7:1;
unsigned long SubsystemProcess:8:1;
unsigned long IndirectCpuSets:9:1;
unsigned long InPrivate:a:1;
unsigned long ProhibitRemoteImageMap:b:1;
unsigned long ProhibitLowILImageMap:c:1;
unsigned long SignatureMitigationOptIn:d:1;
unsigned long DisableDynamicCodeAllowOptOut:e:1;
unsigned long EnableFilteredWin32kAPIs:f:1;
unsigned long AuditFilteredWin32kAPIs:10:1;
unsigned long PreferSystem32Images:11:1;
unsigned long RelinquishedCommit:12:1;
unsigned long Reserved:13:1;
unsigned long HighGraphicsPriority:14:1;
unsigned long CommitFailLogged:15:1;
unsigned long ReserveFailLogged:16:1;
unsigned long DisableDynamicCodeAllowRemoteDowngrade:17:1;
unsigned long LoaderIntegrityContinuityEnabled:18:1;
unsigned long LoaderIntegrityContinuityAudit:19:1;
unsigned long ControlFlowGuardExportSuppressionEnabled:1a:1;
unsigned long FatalAccessTerminationRequested:1b:1;
unsigned long DisableSystemAllowedCpuSet:1c:1;
unsigned long ControlFlowGuardStrict:1d:1;

and compare it with EPROCESS.Flags3 in w10 build 16215:
unsigned long Flags3;
unsigned long Minimal:0:1;
unsigned long ReplacingPageRoot:1:1;
unsigned long Crashed:2:1;
unsigned long JobVadsAreTracked:3:1;
unsigned long VadTrackingDisabled:4:1;
unsigned long AuxiliaryProcess:5:1;
unsigned long SubsystemProcess:6:1;
unsigned long IndirectCpuSets:7:1;
unsigned long RelinquishedCommit:8:1;
unsigned long HighGraphicsPriority:9:1;
unsigned long CommitFailLogged:a:1;
unsigned long ReserveFailLogged:b:1;
unsigned long SystemProcess:c:1;

dramatic difference

how to find PspUniqueJobIdTable

In his cool presentation Alex Ionescu said:

PspUniqueJobIdTable - no way to open/enumerate

Sure there are always some ways. Lets see xrefs to PspUniqueJobIdTable:

• PspJobDelete
• NtCreateJobObject
• PspInitializeJobStructures

no exported functions in this list (well, NtCreateJobObject can be considered as such). Looks deep in PspJobDelete: 

loc_14001B6B4:                          ; CODE XREF: PspJobDelete+2A3
                                        ; PspJobDelete+17FEA8
  test    dword ptr [rbx+518h], 40000000h ; EJOB.JobFlags
  jnz     loc_14019B3AD

loc_14001B6C4:                          ; CODE XREF: PspJobDelete+17FEB6
  mov     rax, gs:188h
  dec     word ptr [rax+1E4h]
  mov     eax, [rbx+4C4h]               ; EJOB.JobId
  test    eax, eax
  jz      short loc_14001B701
  mov     rcx, cs:PspUniqueJobIdTable
  mov     edx, eax
  call    ExMapHandleToPointer

There is very long and noticeable signature for testing of EJOB.JobFlags with value 0x40000000: 18 05 00 00 00 00 00 40
If you searching it in .text section you get only 5-6 matches. Now question is how to get offset to EJOB.JobFlags. It can be done from exported function PsGetCurrentSilo:
PsGetCurrentSilo proc near
  mov     rax, gs:188h
  cmp     qword ptr [rax+7C8h], 0FFFFFFFFFFFFFFFDh
  jnz     short loc_1400B61BF
  mov     rax, [rax+220h]               ; KTHREAD.Process
  mov     rax, [rax+3B0h]               ; EPROCESS.Job
  test    rax, rax
  jz      short locret_1400B61BE

loc_1400B61A6:                          ; CODE XREF: PsGetCurrentSilo+3Cj
  test    dword ptr [rax+518h], 40000000h ; EJOB.JobFlags

And few words about enumerating - it`s just good old HANDLE_TABLE, so we can use ExEnumHandleTable and get all Jobs IDs

wnf kernelmode callbacks

I already described how to enum usermode wnf callbacks
Now it`s time to enum WNF callbacks in kernel
It is not surprising that they stored in EPROCESS.WnfContext, this struct is undocumented but can be partially recovered from function ExpWnfCreateProcessContext:
offset 0 - WORD signature 0x906
offset 4 - WORD - size 0x88 (0x44 for x86)
offset 8 - eprocess
offset 0x10 - linked list for WNF contexts
offset 0x28 - push lock
offset 0x40 - linked list
offset 0x58 - linked list
offset 0x70 - linked list

Lets see at this struct in windbg

kernel etw traces in windows 10

In windows 10 there is no good old EtwpGuidHashTable and all registered Etw stored in SILO. Let`s see how we can extract them

Check first function exported function EtwRegister:
  call    _PsGetCurrentServerSiloGlobals@0 ; PsGetCurrentServerSiloGlobals()
  push    [ebp+arg_C]
  mov     edx, [ebp+arg_0]
  push    dword ptr [ebp+4]
  mov     ecx, [eax+1F0h]               ; ESERVERSILO_GLOBALS.EtwSiloState
  push    [ebp+arg_8]
  push    [ebp+arg_4]
  push    3
  call    _EtwpRegisterProvider@28      ; EtwpRegisterProvider(x,x,x,x,x,x,x)

Function PsGetCurrentServerSiloGlobals returns processes SILO or default SILO PspHostSiloGlobals stored in kernel which has type ESERVERSILO_GLOBALS. Field EtwSiloState has type ETW_SILODRIVERSTATE:
struct _ETW_SILODRIVERSTATE {
  /*   0x0 */ /*|0x4|*/ struct _ESERVERSILO_GLOBALS* SiloGlobals;
  /*   0x8 */ /*|0x168|*/ struct _ETW_GUID_ENTRY EtwpSecurityProviderGuidEntry;
  /* 0x170 */ /*|0x100|*/ struct _EX_RUNDOWN_REF_CACHE_AWARE* EtwpLoggerRundown[64];
  /* 0x270 */ /*|0x100|*/ struct _WMI_LOGGER_CONTEXT* WmipLoggerContext[64];
  /* 0x370 */ /*|0x700|*/ struct _ETW_HASH_BUCKET EtwpGuidHashTable[64];
  /* 0xa70 */ /*|0x10|*/ unsigned short EtwpSecurityLoggers[8];
  /* 0xa80 */ /*|0x1|*/ unsigned char EtwpSecurityProviderEnableMask;
  /* 0xa84 */ /*|0x4|*/ long EtwpShutdownInProgress;
  /* 0xa88 */ /*|0x4|*/ unsigned long EtwpSecurityProviderPID;
  /* 0xa8c */ /*|0x10|*/ struct _ETW_PRIV_HANDLE_DEMUX_TABLE PrivHandleDemuxTable;
  /* 0xa9c */ /*|0x10|*/ struct _ETW_COUNTERS EtwpCounters;
  /* 0xab0 */ /*|0x8|*/ union _LARGE_INTEGER LogfileBytesWritten;
  /* 0xab8 */ /*|0x4|*/ struct _ETW_SILO_TRACING_BLOCK* ProcessorBlocks;
};

ntdll ProtectedPolicies

It seems that since windows 10 ntdll has security feature called "ProtectedPolicies" - you can query it with RtlQueryProtectedPolicy function. Prototype of this function is:
NTAPI NTSTATUS RtlQueryProtectedPolicy(GUID *, PDWORD out_flag);

Lets see how it works:
loc_6A277EFB:   ; CODE XREF: RtlQueryProtectedPolicy(x,x)+12 j
  push    edi
  mov     edi, offset _RtlpProtectedPoliciesSRWLock
  push    edi
  call    _RtlAcquireSRWLockShared@4    ; RtlAcquireSRWLockShared(x)
  push    offset _RtlpSearchProtectedPolicyEntry ; PtFuncCompare
  push    14h                           ; SizeOfElements
  push    ds:_RtlpProtectedPoliciesActiveCount ; NumOfElements
  push    ds:_RtlpProtectedPolicies     ; Base
  push    [ebp+Key]                     ; Key
  call    _bsearch

That policies stored in array RtlpProtectedPolicies, count located in RtlpProtectedPoliciesActiveCount and size of each policy is 0x14 bytes (0x18 under x64), so each policy looks like struct:
struct protected_policy
{
  IID guid;
  DWORD flag;
};

Lets see from where RtlQueryProtectedPolicy called

IMAGE_DYNAMIC_RELOCATION_TABLE.Version 2

it seems that around since w10 build 15007 format of rfg relocs was changed and field IMAGE_DYNAMIC_RELOCATION_TABLE.Version now has value 2. So lets install platform SDK for 15003 and see what was changed

First remarkable thing is that IMAGE_LOAD_CONFIG_DIRECTORY now has two additional fields:
    WORD       DynamicValueRelocTableSection;
    WORD       Reserved2;
    // since w10 build 15003 ?
    ULONGLONG  GuardRFVerifyStackPointerFunctionPointer; // VA
    DWORD      HotPatchTableOffset;
} IMAGE_LOAD_CONFIG_DIRECTORY64, *PIMAGE_LOAD_CONFIG_DIRECTORY64;

so sizeof(IMAGE_LOAD_CONFIG_DIRECTORY64) is now 0xf4

KiServiceTable from windows 10 build 15007 x64

KiServiceLimit .eq. 0x1c8

KiServiceTable from windows 10 build 15007

KiServiceLimit .eq. 0x1c8

KiServiceTable from windows 10 build 14986

KiServiceLimit .eq. 0x1c5

W32pServiceTableFilter from windows 10 build 14951 x64

kd> ? nt!KeServiceDescriptorTableFilter
Evaluate expression: -8795428636992 = fffff800`2799b6c0

kd> dps fffff800`2799b6c0
fffff800`2799b6c0  fffff800`278f4450 nt!KiServiceTable
fffff800`2799b6c8  00000000`00000000
fffff800`2799b6d0  00000000`000001c4
fffff800`2799b6d8  fffff800`278f4b64 nt!KiArgumentTable
fffff800`2799b6e0  ffffa344`ba544bc0 win32k!W32pServiceTableFilter
fffff800`2799b6e8  00000000`00000000
fffff800`2799b6f0  00000000`0000049c
fffff800`2799b6f8  ffffa344`ba5462d4 win32k!W32pArgumentTableFilter

rfg longjumps

In IMAGE_LOAD_CONFIG_DIRECTORY64 there are two fields for setjmp/longjmp support - GuardLongJumpTargetTable & GuardLongJumpTargetCount. Lets see some module where this fields are not zero - for example hal.dll

ntstatus.idc for WDK 10.0.14931.0

added 95 new NTSTATUS values

IMAGE_LOAD_CONFIG_DIRECTORY from sdk 14951

typedef struct _IMAGE_LOAD_CONFIG_CODE_INTEGRITY {
    WORD    Flags;          // Flags to indicate if CI information is available, etc.
    WORD    Catalog;        // 0xFFFF means not available
    DWORD   CatalogOffset;
    DWORD   Reserved;       // Additional bitmask to be defined later
} IMAGE_LOAD_CONFIG_CODE_INTEGRITY, *PIMAGE_LOAD_CONFIG_CODE_INTEGRITY;