etw part 4½: MCGEN_TRACE_CONTEXT

let's continue to dissect ETW (parts 1,2, 3 & 4)

Now consider structures generated with mc.exe (Windows Message Compiler). It seems that this is very old technology - some .mc files in official Microsoft github repository have copyrights from 1992! Despite this they are still supported for example in MSBuild - see rule for MessageCompile

This generated with mc structure has name MCGEN_TRACE_CONTEXT and looks like:

typedef struct _MCGEN_TRACE_CONTEXT

{

    HANDLE                 RegistrationHandle;

    HANDLE                 Logger;

    ULONGLONG              MatchAnyKeyword;

    ULONGLONG              MatchAllKeyword;

    ULONG                  Flags;

    ULONG                  IsEnabled;

    UCHAR                  Level; 

    UCHAR                  Reserve;

    USHORT                 EnableBitsCount;

    PULONG                 EnableBitMask;

    const ULONGLONG*       EnableKeyWords;

    const UCHAR*           EnableLevel;

} MCGEN_TRACE_CONTEXT, *PMCGEN_TRACE_CONTEXT;

Looks very similar to _TlgProvider_t. Unfortunately they cannot be found with some simple signatures scan - you need to use some disasm magic. I wrote simple PoC to find them in arm64 windows kernel

Let`s see where you can encounter this ancient variant of ETW

Kernel

kernel contains following mc generated providers:

• MS_KernelCc_Provider_Context, GUID MS_KernelCc_Provider (A2D34BF1-70AB-5B21-C819-5A0DD42748FD)
• MS_StorageTiering_Provider_Context. GUID MS_StorageTiering_Provider (990C55FC-2662-47F6-B7D7-EB3C027CB13F)
• IoMgrProvider_Context, GUID IoMgrProvider (ABF1F586-2E50-4BA8-928D-49044E6F0DB7)
• MS_KernelPnP_Provider_Context, GUID MS_KernelPnP_Provider (9C205A39-1250-487D-ABD7-E831C6290539)

Field RegistrationHandle in kernel mode points to ETW_REG_ENTRY (same as RegHandle in _TlgProvider_t)

Drivers 

This is not comprehensive list - just some samples

• ndis.sys - NDIS_PROVIDER_ID_Context & SLEEPSTUDY_ETW_PROVIDER_Context
• tcpip.sys - EQOS_EVENT_PROVIDER_Context & MICROSOFT_TCPIP_PROVIDER_Context
• winnat.sys - MICROSOFT_WINNAT_ETW_PROVIDER_Context
• ntfs.sys - NtfsGeneralEventProvider_Context

Lets see how they looks for example for tcpip.sys:

MCGEN_TRACE_CONTEXTs for tcpip.sys:

 [0] EQOS_EVENT_PROVIDER_Context at FFFFF80144CFC100

 RegistrationHandle: FFFF940A69586E90

  GuidEntry: FFFF940A690CF520

 Logger: 0000000000000000

 Flags: 0

 IsEnabled: 1

 Level: 255

 EnableBitsCount: 4

 [1] MICROSOFT_TCPIP_PROVIDER_Context at FFFFF80144CFA6D0

 RegistrationHandle: FFFF940A69586710

  GuidEntry: FFFF940A690CC7A0

 Logger: 0000000000000000

 Flags: 0

 IsEnabled: 1

 Level: 255

 EnableBitsCount: 7A

Usermode .dlls

Just like in _TlgProvider_t field RegistrationHandle is not real HANDLE but some structure with address to ETW_REGISTRATION_ENTRY. Again this is not comprehensive list - just some samples:

• dnsrslvr.dll - MS_VPN_PLGN_PLATFORM_Operational_Context
• rpcrt4.dll - RpcEtwGuid_Context & RpcLegacyEvents_Context
• ole32.dll/combase.dll - COM_PERFORMANCE_PROVIDER_Context, ASYNCHRONOUS_CAUSALITY_PROVIDER_Context, WINRT_ERROR_PROVIDER_Context, RUNDOWN_INSTRUMENTATION_PROVIDER_Context

So as you can see these structures are ubiquitous and need to be checked against ETW attacks