[tcpdump-workers] Reading capture files with an unknown link-layer header type

[Guy Harris via tcpdump-workers]

--- Begin Message ---
François checked in a change to tcpdump so that, if it's handed a capture file 
with a link-layer header type for which it has no dissector, it just dumps the 
packet data in hex, rather than failing with an indication that the header type 
isn't supported.

However, pcap_compile(), in *libpcap*, will fail with an unknown header type - 
and tcpdump always hands a filter to pcap_compile(), even if it's a null string 
(which means "accept every packet").

It doesn't fail with *known* filter types for which most filters are 
unsupported, it just rejects most of them (other than "link[M:N]").

Is there any reason *not* handle link-layer types unknown to libpcap in 
pcap_compile()?--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [AiG-CERT #104737] DLT value

[Guy Harris via tcpdump-workers]

--- Begin Message ---
On Jun 2, 2020, at 12:58 AM, Airbus CERT via tcpdump-workers 
 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

Re: [tcpdump-workers] [AiG-CERT #104737] DLT value

[Airbus CERT via tcpdump-workers]

--- Begin Message ---
Hi libpcap team,

Have you advanced on the subject? The project is published on the Airbus CERT 
github if you want to take a look : https://github.com/airbus-cert/Winshark

Have a nice day,

Sylvain

-- 
-- 
Don't hesitate to contact us if you have questions or need assistance.

Best regards,

Airbus CERT (AiG CERT)

Airbus CERT
PGP KeyId: 527B1472
PGP Fingerprint: 8001 FDE8 84DA 90FD 6D5F D011 6B83 10FF 527B 1472

On Tue Jun 02 09:58:02 2020, speyrefitte wrote:
> Hello,
> 
> The layout is https://docs.microsoft.com/en-
> us/windows/win32/api/evntcons/ns-evntcons-event_header 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. I strictly follow the two upper links.
> 
> Another good point for including ETW capability is a new way for
> network capture https://docs.microsoft.com/en-us/message-
> analyzer/microsoft-windows-ndis-packetcapture-provider without
> requiring to an NDIS driver.
> 
> Thanks for all your works on my PR,
> 
> Have a nice day,
> 
> Sylvain
> 
> --
> --
> Don't hesitate to contact us if you have questions or need assistance.
> 
> Best regards,
> 
> Airbus CERT (AiG CERT)
> 
> Airbus CERT
> PGP KeyId: 527B1472
> PGP Fingerprint: 8001 FDE8 84DA 90FD 6D5F D011 6B83 10FF 527B 1472
> 
> On Tue Jun 02 09:44:07 2020, ghar...@sonic.net wrote:
> > On Jun 2, 2020, at 12:22 AM, Airbus CERT via tcpdump-workers
> >  > work...@lists.tcpdump.org> wrote:
> > > Yes exactly each packet is an event. The layout of the event is
> > > https://docs.microsoft.com/en-us/windows/win32/api/evntcons/ns-
> > > evntcons-event_header and https://docs.microsoft.com/en-
> > > us/windows/win32/api/evntcons/ns-evntcons-
> > > event_header_extended_data_item. But we aligned this format with
> > > the
> > > ETL (serialization use by microsoft) which is not well documented.
> > Is it documented at all?
> > The description of a given LINKTYPE_/DLT_ value on
> > https://www.tcpdump.org/linktypes.html
> > and the pages linked to by that description must be sufficient to
> > allow somebody to write code to, at minimum, parse the link-layer
> > headers, without ever looking at Wireshark or tcpdump code.

The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers