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.har...@gmail.com> 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+unsubscr...@googlegroups.com.
> 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.
