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
