Feature request: grep hex strings with -e

[Carter Bullard]

Hey Markku,
OK, try this patch on your clients code, to see if it works.  Not sure what version
you're running, so I'm going to assume its argus-clients-3.0.7.1.  The patch's
exact line numbers may not be exact, so change the lines that look similar to
the new line, and all should be fine.

thoth:common carter$ p4 diff ...
==== //depot/argus/clients/common/argus_grep.c#11 - /Volumes/Users/carter/argus/clients/common/argus_grep.c ====
57c57
<          int options = REG_EXTENDED | REG_NOSUB;;
---
>          int options = REG_EXTENDED | REG_ENHANCED | REG_NOSUB;


On my Mac OS X, I needed to add this option to the regular expression compile
code to get this to work as you suggested.  Not sure if that is a Mac thing or not.
Here is what I get now:

thoth:common carter$ ../bin/ra -r /tmp/*09.35* -e s:\\x41\\x70 -s +suser:32
                 StartTime        Dur      Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  SrcPkts  DstPkts     SrcBytes     DstBytes State                 srcUdata                  
2012/10/05.09:36:11.842712   0.099477  e           udp       192.168.0.33.mdns      ->        224.0.0.251.mdns          2        0          357            0   INT s[32]=.............Apt._tivo-videostre
2012/10/05.09:37:50.429561   0.095191  e           udp       192.168.0.33.mdns      ->        224.0.0.251.mdns          2        0          357            0   INT s[32]=.............Apt._tivo-videostre
2012/10/05.09:39:29.012663   0.101437  e           udp       192.168.0.33.mdns      ->        224.0.0.251.mdns          2        0          357            0   INT s[32]=.............Apt._tivo-videostre

Holler if that does it for you.

Carter


On Oct 5, 2012, at 8:55 AM, Carter Bullard <carter at qosient.com> wrote:

> Hey Markku,
> I'll look into it today.  Need to run under gdb() to see what actually makes it to recomp().  It maybe as dumb as double quotes vs single quotes, but I'll check it out before lunch.
> 
> Carter
> 
> On Oct 5, 2012, at 2:04 AM, Markku Parviainen <maketsi at gmail.com> wrote:
> 
>> 2012/10/4 Carter Bullard <carter at qosient.com>:
>>> ra* clients use the available regular expression library, and should support hexadecimal codes for matching now.
>>> 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.
>> 
>> The param was already quoted so that the shell (bash) would not interfere.
>> Anyway, for some reason it just doesn't work. I attached a sample (240
>> bytes) for your analysis.
>> 
>> # ra -r regex-anon.ra -M printer=encode32 -s suser:32
>>                               srcUdata
>> s[32]=333712F228948DABC9C0D199D1C3B00F
>> 
>> # ra -r regex-anon.ra -e '\x33'
>> # ra -r regex-anon.ra -e '\\x33'
>> # ra -r regex-anon.ra -e '33'
>> 
>> None of them produce anything (whereas only the first one should). Ideas?
>> 
>> I tried enabling debug output, but even -D10 does not produce any
>> lines about regex behaviour.
>> The system is CentOS 5.7 64bit, gcc v4.1.2, ra v3.0.7.1.
>> 
>> 
>> Btw. To confirm what the shell is delivering to the prog when \x is
>> single quoted:
>> 
>> # echo '\x33'
>> \x33
>> # echo \x33
>> x33
>> # perl -e 'print join(", ", @ARGV) ."\n"' -- -e '\x33'
>> -e, \x33
>> # echo '\\x33'
>> \\x33
>> <regex-anon.ra>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121005/77d566df/attachment.bin>