fix logic after dynamic update

[mr-tz]

fixes for #855

when generating subscope rules (in the format of rule/uuid) we emit subrules at all scopes, when matching in static flavor this includes dynamic subscopes which can never be matched if static and dynamic are both required, so e.g. file-system/read/read-file-via-mapping.yml before this update could not match.

https://github.com/mandiant/capa/blob/51ddadbc87b113dda18495b49e490f8452292b87/capa/rules/__init__.py#L925-L928

@yelhamer is this intended behavior or a bug? I think our current documentation calls this out differently (and I assumed it works differently since I created these faulty rules in the first place 😄 )

[mr-tz]

The doc (updated in https://github.com/mandiant/capa-rules/pull/851/files) doesn't mention that scopes get just ignored so maybe I just misunderstood how it's implemented.

[yelhamer]

Sorry for the late reply.

I believe that this was intended behavior. I can't pull the exact discussion on this, but I think the main points supporting this design choice were:

• by emitting all features and subscopes regardless of the flavor, we end up not having to cache two different versions of capa rules (one for each flavor). We also end up avoiding the added complexity which we might end up removing later anyways (see the next 2 point for a potential motivation for this).
• we had the case in mind that some debugger-based extractors might be able to support the instruction scope. S, emitting it from the get-go and ignoring it (like we do with irrelevant features) made more sense than not doing that, and then having to go back and modify any rules that were written with that logic — capa not emitting instruction in dynamic flavor —.
• I think we had in mind a future version of capa wherein we could do static and dynamic analysis both at the same time (see example use cases below). Emitting the same rules' features block (including features and subscopes) helps make this simpler/easier). Example use cases:
  • if the user specifies it, we could run dynamic capa with the CAPE backend and then use static capa on the dropped samples.
  • once we add TTD, Pin, or debugger-based extractors, we might want to give users the ability to do both static and dynamic analysis on a sample in a single capa run.

point 4 of issue mandiant/capa#1672 talks a bit about this.

[yelhamer]

For this rule, we could pull the optional node out of both static and dynamic blocks, which would make the rule shorter in size, remove repetition, but would add an extra level of depth to the rule (introduction of an or between the basic block and call subscopes). I prefer how it is now... but maybe we should some syntactic sugar in the future for:

- or:
  - basic block:
    - featureA
    - featureB
    - featureC
  - call:
    - featureA
    - featureB

maybe something like:

- basic block | call:
  - featureA
  - featureB
  - featureC

[mr-tz]

yeah, this could be nice

[mr-tz]

Thanks for the details. That all makes sense and is much clearer now to me (again? :))