Feature request: grep hex strings with -e

Markku Parviainen maketsi at gmail.com
Tue Oct 16 09:58:02 EDT 2012


Looking at the regexp comparison page in wikipedia, PCRE library seems
to be the most comprehensive for all purposes. A compile time option
would be one option, but would require more maintenance. That lib
could be the default too if the library existed in the system.
However, it should be very clear to an end-user which library was
selected, as multiple libraries will break the compatibility with
external scripts. Therefore you need to evaluate if the current
library is in anyway better than PCRE (for example), besides being on
(most?) systems already.

A simple alternative (or addition) to this particular case is to
provide binary string matching via new command line parameter (e.g. -E
"41beef" -> searches for string "A\xbe\xef"). That's easy to implement
as it's almost like a direct memcmp, without any regexp features. If
that -e regexp was better, this probably wouldn't be needed at all
though, except for convenience. Binary searches are basically used
when searching for known malware handshake patters, or when looking up
known image or compression formats in data flows. Encryptions and
snaplen used restrict the more advanced usage.

Extending and fixing the restrictions of the current -e parameter is
another thing completely, but might be desirable too on some cases.
Dave had many good points there. Alternative to some of those new
flags could be supporting the more typical regexp format of
[!]/regexp/modifiers, which supports inline negation and
case-insensitivity switches, along with other extended modifiers (such
as single/multi-line matching, affecting to behaviour of dot, \n, ^
and $).

One problem with current -e format is btw. that how do you search for
string "s:data" in both source and destination buffers, as currently
that would search for "data" in source buffer only? But I guess that's
quite an edge case, which is easily avoided.



More information about the argus mailing list