--- Begin Message ---
On Jun 2, 2020, at 12:58 AM, Airbus CERT via tcpdump-workers
<tcpdump-workers@lists.tcpdump.org> wrote:
> The layout is
> https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-evntcons-event_header
So each packet's data starts with, in order:
a 2-octet event record size;
a 2-octet header type;
a 2-octet flag word;
a 2-octet indication of the format of the event data;
a 4-octet thread ID;
a 4-octet process ID;
an 8-octet time stamp;
a 16-octet UUID for the event provider;
a sequence of:
a 2-octet event identifier;
a 1-octet event version;
a 1-octet event channel;
a 1-octet event level;
a 1-octet event opcode;
a 2-octet task identifier;
an 8-octet keyword bitmask;
either:
a 4-octet elapsed kernel CPU time followed by a 4-octet elapsed
user CPU time;
or:
an 8-octet elapsed user-mode CPU time;
a 16-octet UUID for an activity.
What byte order are the numerical values in? Little-endian?
> following by one or more
> https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-evntcons-event_header_extended_data_item
> depending of the flag _EVENT_HEADER.Flags.
So that's one or more of, in order:
2 reserved octets;
a 2-octet extended data type value;
2 reserved octets;
a 2-octet extended data size value;
presumably immediately followed by the octets of the extended data.
What byte order are the numerical values in? Little-endian?
If the number of octets of extended data isn't a multiple of 8, is there any
padding after it?
And do the same rules used to generate those data layouts - and the same choice
of byte order - apply for the structures in the extended data?
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
