Wireshark · Ethereal-users: Re: [Ethereal-users] simple frame data evaluation?

[Guy Harris <guy@xxxxxxxxxx>]

On Tue, May 06, 2003 at 06:59:21AM -0700, Jon Baer wrote:
> what is the display filter expression to test for a true statement no matter
> what protocol is present?  how to do a simply query on a frame's data?

	http://www.ethereal.com/ethereal.1.html

"A slice operator also exists. You can check the substring (byte-string)
of any protocol or field. For example, you can filter on the vendor
portion of an ethernet address (the first three bytes) like this:

    eth.src[0:3] == 00:00:83

If the length of your byte-slice is only one byte, then it is still
represented in hex, but without the preceding ``0x'':

    llc[3] == aa

You can use the slice operator on a protocol name, too. And remember,
the ``frame'' protocol encompasses the entire packet, allowing you to
look at the nth byte of a packet regardless of its frame type (Ethernet,
token-ring, etc.).

    token[0:5] ne 0.0.0.1.1
    ipx[0:2] == ff:ff
    llc[3:1] eq 0xaa

The following syntax governs slices:

        [i:j]   i = start_offset, j = length
        [i-j]   i = start_offet, j = end_offset, inclusive.
        [i]     i = start_offset, length = 1
        [:j]    start_offset = 0, length = j
        [i:]    start_offset = i, end_offset = end_of_field

Offsets and lengths can be negative, in which case they indicate the
offset from the end of the field. Here's how to check the last 4 bytes
of a frame:

    frame[-4:4] == 0.1.2.3

or

    frame[-4:] == 0.1.2.3

You can create complex concatenations of slices using the comma
operator:

        field[1,3-5,9:] == 01:03:04:05:09:0a:0b

"

> i just noticed what i wanted to do was in the wishlist but i think it's
> already present, # 34:
> 
> 34. Add a display filter "match string" operator, which is similar to the
> "==" operator, but operates only on strings and byte arrays, and matches if
> the string in question appears anywhere in the item being tested. This would
> allow users to search for packets that contain a string anywhere in the
> packet (frame[0:] =~ "hi, there"), and anywhere in or after any particular
> protocol's header. A regular-expression match might also be useful.
> 
> non existant @ the moment or am i missing something?

That feature does not exist in Ethereal; that's why it's in the wish
list and not the manual.  :-) (There are probably items in the wish list
that we did and forgot to remove from the wish list, but that's not one
of them.)

That feature is also not the same as the one described by the quoted
text from the manual page - the feature described by the quoted text
lets you query a frame's data, but only lets you query data at offsets
wired into the query expression; it doesn't let you check whether the
data in question exists in the frame at *any* offset.

> and wouldn't this
> kinda be like putting snort-like features directly into ethereal?

No.  In some sense, Ethereal, or, rather, Tethereal, already has
"snort-like features", as does tcpdump:

	http://www.snort.org/docs/writing_rules/chap1.html#tth_sEc1.2

"First, let's start with the basics. If you just want to print out the
TCP/IP packet headers to the screen (i.e. sniffer mode), try this: 

./snort -v"

and

	http://www.snort.org/docs/writing_rules/chap1.html#tth_sEc1.3

"OK, all of these commands are pretty cool, but if you want to record
the packets to the disk, you need to specify a logging directory and
Snort will automatically know to go into packet logger mode:

	...

If you're on a high speed network or you want to log the packets into a
more compact form for later analysis you should consider logging in
binary mode. Binary mode logs the packets in tcpdump format to a single
binary file in the
logging directory: 

./snort -l ./log -b"

The mode that Ethereal doesn't do is network intrusion detection mode,
because that involves Snort reporting various alerts if packets that
match certain rules are seen - Ethereal doesn't support that sort of
background mode (you could sort of bludgeon Tethereal into doing
something sort of like that, by running it with a read filter, but
filter expressions don't have messages assocatied with them, you'd just
get the matching packets printed out).

Furthermore, Snort can do more than just content matching - it can do
stuff such as IP address and TCP/UDP port matching, which is stuff
Ethereal can also do, so it's not as if adding, say, a Boyer-Moore
string matcher to Ethereal crosses some magic threshhold that makes it
do stuff that's Too Much Like Snort.