Feature request: grep hex strings with -e

[Carter Bullard]

Hey Markku,
ra* clients use the available regular expression library, and should support hexadecimal codes for matching now.

We compile the regular expression, using the REG_EXTENDED and REG_NOSUB options, and if you also provide the -i option, we'll compile with the REG_ICASE option.  regexec() is then called with 0 as the flags.

So, there is nothing keeping ra* from doing hexidecimal code matching.  Because you have to use '\xNN' to specify the codes, when you provide it on the command line, you may need to escape the ' \ ' to get it past the shell.

Did you try:
   ra -e \\x01\\x02

to get the string through the shell into the compiler ?

Carter


On Oct 4, 2012, at 2:22 AM, Markku Parviainen <maketsi at gmail.com> wrote:

> Hi,
> 
> There's already '-e regex' option in argus, but it only accepts
> printable ascii strings. Could you extend it to parse quoted hex
> strings too so that we could use it to search for binary content? The
> recommended format would be \xNN for single chars, where NN is between
> 00..FF, representing one ascii character. That conforms to typical
> quoting used in perl and others. Perhaps there could be another option
> for binary strings too that would work directly without that \x
> quoting for courtesy (i.e. saying directly 0102 instead of \x01\x02),
> but both are not required, and the former (extended -e) is more
> recommended of the two.
> 
> I'm now searching for binary content by using external grep this way:
> $ ra -r file.ra -M printer=encode32 -s suser:n | fgrep 4142
> .. which works fine for packets where I know that the data (4142 =
> "AB") exists within 'n' first bytes.
> 
> It would be much simpler to just say:
> $ ra -r file.ra -e '\x41\x42'
> 
> That would work better for large packets and be easier to pipe forward.
> 
> I tried using external tools to add binary strings directly in -e, but
> it doesn't work in all cases as you might imagine as the shell
> intercepts some characters, and is therefore incredibly dangerous.
>