Is there a limitation on the complexity of the conditions for Yara rules?
I've got a situation where any given string correctly matches where it's
supposed to, and for three subgroups of strings, any two groups will
correctly match, but if I try to add all three subgroup conditions, it
fails.
To lay it out in Yara syntax:
rule badstuff {
strings:
$a1 = ...
$a2 = ...
$b1 = ...
$b2 = ...
$b3 = ...
$b4 = ...
$c1 = ...
$c2 = ...
condition:
[here's where the trouble starts]
Works:
($a1 at 0 or $a2 at 0) and 3 of ($b*)
OR
($a1 at 0 or $a2 at 0) and ($c1 or $c2)
OR
($c1 or $c2) and 3 of ($b*)
Ordering of the groups of conditions does not appear to matter.
Does NOT work:
($a1 at 0 or $a2 at 0) and 3 of ($b*) and ($c1 or $c2)
???
I also tried
($a1 at 0 or $a2 at 0) and ($b1 or $b2 or $b3 or $b4) and ($c1 or $c2)
which isn't quite the same meaning, but should eliminate any weird edge
cases around the "n of [string list]" operator.
An earlier variation of this rule used:
($a1 at 0 or $a2 at 0) and $b1 and $c1
which worked fine, except it didn't match the new variation sample files
that showed up today.
I've just about resolved to drop $c1 and $c2 for the particular samples
at hand as they're possibly a little *too* specific to catch future
variations, but I could easily see really wanting to use conditions like
this.
(As a side question, is there a setting I can use somewhere to make
unused strings a warning rather than a hard error? It's a real pain to
comment/uncomment/recomment strings again and again and again while
trying to assemble complex rules like this.)
-kgd
_______________________________________________
Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation
https://docs.clamav.net/#mailing-lists-and-chat
