--- 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;
                a 4-octet elapsed kernel CPU time followed by a 4-octet elapsed 
user CPU time;
                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

Reply via email to