Ethereal-users: Re: [Ethereal-users] Need Help With Capture Filter

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Al Stu" <AHStubbl@xxxxxxxxxxx>
Date: Sun, 24 Apr 2005 22:47:01 -0700
Thanks Guy, Think I'm starting to get it!!!

The UUID looks to be 16 bytes, but the size specified can only be 1, 2, or 4. So it would seem I'd have to use 4 expression tests. Is this correct or am I missing something?

Currently capturing based on DCE RPC Version (0x2A:1) and Interface Hint + Activity Hint (0x70:4).
(ether[0x2A:1] = 0x04) and (ether[0x70:4] = 0xFFFFFFFF)

But would like to use Object UUID (0x32:16) instead of the Interface and Activity Hints (chose those because they are convenient 4 sequential bytes).

Again thanks, for your help.

----- Original Message ----- From: "Guy Harris" <gharris@xxxxxxxxx>
To: "Ethereal user support" <ethereal-users@xxxxxxxxxxxx>
Sent: Sunday, April 24, 2005 1:12 AM
Subject: Re: [Ethereal-users] Need Help With Capture Filter


Al Stu wrote:
Need to create a capture filter for Microsoft Messenger Service, NetrSendMessage packets (see attached capture file).

The capture filter can not be based on IP source address or UDP destination port, as these vary.

If those packets have a pattern that appears in all packets at a fixed offset, you could try using the comparison feature in libpcap capture filters; to quote the tcpdump man page:

      expr relop expr
             True  if  the relation holds, where relop is one of >, <,
             >=, <=, =, !=, and expr is an arithmetic expression  com-
             posed  of integer constants (expressed in standard C syn-
             tax), the normal binary operators [+, -, *, /, &, |,  <<,
             >>],  a  length  operator, and special packet data acces-
             sors.  To access data inside the packet, use the  follow
             ing syntax:
                  proto [ expr : size ]
             Proto  is  one of ether, fddi, tr, wlan, ppp, slip, link,
             ip, arp, rarp, tcp, udp, icmp or ip6, and  indicates  the
             protocol  layer  for  the index operation.  (ether, fddi,
             wlan, tr, ppp, slip  and  link  all  refer  to  the  link
             layer.)   Note that tcp, udp and other upper-layer proto-
             col types only apply to IPv4,  not  IPv6  (this  will  be
             fixed  in  the future).  The byte offset, relative to the
             indicated protocol layer, is  given  by  expr.   Size  is
             optional  and  indicates the number of bytes in the field
             of interest; it can be either  one,  two,  or  four,  and
             defaults  to  one.  The length operator, indicated by the
             keyword len, gives the length of the packet.

             For example, `ether[0] & 1 != 0'  catches  all  multicast
             traffic.   The  expression `ip[0] & 0xf != 5' catches all
             IP packets  with  options.   The  expression  `ip[6:2]  &
             0x1fff  = 0' catches only unfragmented datagrams and frag
             zero of fragmented datagrams.  This check  is  implicitly
             applied  to  the  tcp  and  udp  index  operations.   For
             instance, tcp[0] always means the first byte of  the  TCP
             header,  and never means the first byte of an intervening
             fragment.

From your reference to "NetrSendMessage" I assume this is the DCE RPC-based service, but that it's not running over SMB (in which case it'd be TCP traffic on port 139 or 445). If it's *not* running over SMB, there might be some pattern you could construct; you'd have to look at fields such as the DCE RPC version number field (the major version should be 4), as well as at the UUID (you'd want the UUID for Microsoft Messenger).

Constructing a capture filter to match those packets is left as an exercise for the reader.

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users