There is no down selection going on that I am aware of, but my experience in this part of the code is almost nonexistent. My understanding is that all strings across all rules are searched for all at once. You and I are using a single rule example, where doing this kind of thing certainly makes sense, but when you are considering the case of more than one rule it becomes difficult to reason about what to do down selection on because each string can be treated, logically speaking, differently in the condition of different rules.
Another thing to consider is that recent versions of YARA have implemented short-circuit logic for logical conditionals. For example, consider this: uint32(1000) == 0xdeadbeef and for any i in (0..pe.number_of_resources): (hash.sha256(pe.resources[i].offset, pe.resources[i].length) == "FOO") While this isn't down selection it is something to keep in mind if you want to squeeze performance out of your rules. -- WXS In this case the for loop would be skipped if the uint16() condition evaluates to false. > On Jan 5, 2016, at 3:11 PM, Harley H <[email protected]> wrote: > > 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 <[email protected]> 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 [email protected]. > > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
