wiretap: add support for ETL traces (WAS 66fa3ee6455521f6b9f5c7251c0b5c3728953623)
authorAurelien Aptel <aaptel@suse.com>
Fri, 23 Aug 2019 14:36:18 +0000 (16:36 +0200)
committerStefan Metzmacher <metze@samba.org>
Thu, 25 Apr 2024 09:57:36 +0000 (11:57 +0200)
commit226656f40cbb772407fd6aab39f5c22e803fe1b2
tree2fb9abf77ce0fcdbce3be50208f0ee24d1dce536
parent2ab01ab01243f270f3632536ef8eb97f677afee4
wiretap: add support for ETL traces (WAS 66fa3ee6455521f6b9f5c7251c0b5c3728953623)

ETL files are Windows native traces. They can be generated using
netsh:

    netsh trace start tracefile=c:\mytrace.etl capture=yes
    netsh trace stop

They are quite versatile: they store all sorts of system
information (TCP/IP stack state, processes running, ...) and system
events (syscalls, kernel stacks, ...), including network
traffic. It's pretty much the equivalent of strace, ftrace, /proc/
and tcpdump all bundled into one file.

The API to consume and produce those events on a Window system is
called ETW and it uses a myriad of different structs, some
undocumented.

https://docs.microsoft.com/en-us/windows/win32/api/evntcons/

ETL files are made of those structs which are simply dumped from
memory. The file format remains undocumented but can be figured out
by looking at the API struct definitions, hexdumps and some guess
work. Microsoft also has its own tool to explore those traces
(MessageAnalyzer) which was very useful to double-check some of the
findings.

Each event producer is called a Provider and they all have a
GUID. It seems the Provider responsible for generating the network
traffic events is "Microsoft-Windows-NDIS-PacketCapture".

Here is a pseudo-grammar of an ETL file

ETL        := ETW_BUFFER+
ETW_BUFFER := WMI_BUFFER_HEADER EVENT+
EVENT      := SYSTEM_TRACE_HEADER TRACE_LOGFILE_HEADER
           |  PERFINFO_TRACE_HEADER
           |  EVENT_HEADER <-- packets are here
           |  EVENT_INSTANCE_HEADER
           |  (other ignored types)

NETMON files use EVENT_HEADER stuctures similar enough that we can
reuse its dissector. But the structure varies enough that we have
to introduce a new WTAP_ENCAP_ETL value.

This ETL reader reuses existing Wireshark support:
- the netmon dissector will dissect the EVENT_HEADER itself.
- the messageanalyzer dissector knows about the NDIS Provider and
  will handle the ETW NDIS sub-payload.

Sample capture:
https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=small-system-misc-ping.etl

Bug: 15104
Change-Id: I0092df8b40b6dfe04893a526c484b849a5153bef
epan/dissectors/packet-netmon.c
wiretap/CMakeLists.txt
wiretap/etl.c [new file with mode: 0644]
wiretap/etl.h [new file with mode: 0644]
wiretap/file_access.c
wiretap/wtap.h