WPP trace message capture

[udoe]

Hi,

I'm trying to create an application that captures events produced by WPP in a kernel-mode driver and I found krabsetw quite useful for this task. Basically creating and starting a session using krabs::user_trace works as expected.

The issue is that ut::forward_events() checks the record.EventHeader.ProviderId in each event and forwards it only if this field matches the provider GUID. I found that in WPP messages the EventHeader.ProviderId field is not set to the provider GUID. It is set to some local GUID generated by WPP instead. So WPP messages cannot pass the check in ut::forward_events().

The documentation states that the EVENT_HEADER_FLAG_TRACE_MESSAGE flag indicates a WPP message. So I fixed that by modifying the check as follows:

if (0 != (record.EventHeader.Flags & EVENT_HEADER_FLAG_TRACEMESSAGE) || record.EventHeader.ProviderId == provider.get().guid) { provider.get().on_event(record); }

It would be great if this check could be made configurable. Or could it be removed completely? Maybe there should be a separate trace type for WPP, e.g. krabs::wpp_trace.

Thanks Udo

[zacbrown]

Hi Udo,

I haven't personally used WPP with krabsetw so I'm not surprised there's a subtle issue there. We'd happily accept a patch for that if you wanted to create one.

thanks,

Zac

[pathtofile]

So FWIW I just tried to use the latest Krabs with the AMSI WPP trace in Matt Graeber's blog (https://posts.specterops.io/data-source-analysis-and-dynamic-windows-re-using-wpp-and-tracelogging-e465f8b653f7)

And it seemed to work ok? The event_names weren't parsed correctly, but I did recieve the events and could parse the data in them.

Tried some other WPP traces and the same thing - Event Names were wrong, but data still there

[swannman]

Thanks @pathtofile! We are discussing the fix on your PR #131.

[swannman]

Resolved by #131