Wes,
Thanks for the info. Is there any down selecting going on? To illustrate
what I mean, I'll use snort as an example. When snort is selecting content
for matching it first checks to the rule and selects a string it thinks is
the best match to send to the fast pattern matcher. By default this is the
longest string but this behavior can be overridden by the rule writer. The
idea being that only packets matching the longest and/or most unique string
get sent through the main detection engine where more expensive logic is
performed.
So, let's say I had a Yara rule like this:
rule Testing {
strings:
$moreuniquebadstuff = { aa bb cc dd ee ff 00 11 22 }
$badstuff = { 00 00 00 00 aa bb cc dd }
condition:
$badstuff at 0x8000 and $moreuniquebadstuff
}
Would it make sense to for there to be something similar to snort's fast
pattern matcher in yara where file content is first checked against the
more unique string $morebadstuff then all subsequent logic is performed?
On Wednesday, December 30, 2015 at 4:07:43 PM UTC-5, Wesley Shields wrote:
>
> Condition statements are executed after the string scanning is done.
> Usually many rules are compiled and the strings are searched for all at
> once, so it's actually faster to ignore positions and just do the logic
> after the fact.
>
> If you only care that a set of bytes is at a specific offset you could do
> this:
>
> rule Testing {
> condition:
> uint32(0x8000) == 0x00000000 and
> uint32(0x8004) == 0xaabbccdd
> }
>
> You may have to use uint32be() instead, I don't recall exactly.
>
> -- WXS
>
> > On Dec 30, 2015, at 1:10 PM, Harley H <bobb....@gmail.com <javascript:>>
> wrote:
> >
> > Hello,
> > I'm receiving a warning message like this: "warning: $badstuff is
> slowing down scanning". The rule is similar to:
> >
> > rule Testing {
> > strings:
> > $badstuff = { 00 00 00 00 aa bb cc dd }
> >
> > condition:
> > $badstuff at 0x8000
> > }
> >
> > I do not think this would be a performance hit due to the positional
> limitation. I see in atoms.c the positional modifiers are not accounted for
> when considering the quality of an atom. But, does the detection engine
> consider the at offset prior to scanning the whole file for $badstuff?
> >
> > Thanks,
> > Harley
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "YARA" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to yara-project...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to yara-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
