Add "loop" feature to instructions in static extractors.

[larchchen]

Detecting API happening in a loop is an effective approach for exploits leveraging racing conditions.

A classic example is DirtyCow (CVE-2016-5195)
By detecting madvise calls inside a loop with MADV_DONTNEED argument.

  scopes:
    static: basic block
  features:
    - and:
      - api: madvise
      - number: 4 # Constant for MADV_DONTNEED
      - characteristic: inside loop

A more recent example CVE-2024-50066 can be covered by

  - and:
    - api: madvise
    - number: 25 # MADV_COLLAPSE
    - characteristic: inside loop

Checklist

• No CHANGELOG update needed

• No new tests needed

• No documentation update needed

• This submission includes AI-generated code and I have provided details in the description.

[github-actions]

Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed

CHANGELOG updated or no update needed, thanks! 😄

[github-actions]

Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed

[github-actions]

Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed

[github-actions]

Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed

[gemini-code-assist]

Code Review

This pull request introduces the 'inside loop' characteristic for basic blocks in the BinExport2 extractor. It adds a new utility module, capa/features/extractors/loops.py, which uses networkx to identify vertices within cycles. Feedback identifies a structural issue in the new loops module where code precedes the license header and lacks necessary imports. Additionally, suggestions were made to move a local import to the top level for PEP 8 compliance and to simplify edge collection logic using a list comprehension.

CHANGELOG updated or no update needed, thanks! 😄

[mike-hunhoff]

Thank you for iterating on this! After reviewing the implementation and thinking about how to best align this with capa's architecture and performance constraints, I suggest a unified path forward that simplifies the rule authoring experience and minimizes performance overhead.

Here is the suggested implementation strategy:

1. Reuse the existing loop characteristic

Instead of introducing a new name like inside loop at the basic block scope, let's just yield the existing Characteristic("loop") at the instruction scope for instructions contained within a cycle.

• Why: This avoids inflating the rule vocabulary and maintains perfect backward compatibility. By extracting it at the narrowest scope (instruction), it will automatically bubble up to basic block and function scopes properly.

2. Perform Graph Analysis Once Per Function (Performance)

To avoid the heavy performance penalty of running networkx graph analysis repeatedly, I suggest computing the loop vertices once at the function level and sharing them with the instruction extractor:

• In the function extractor (where we already build edges for the current has_loop check), use your SCC logic to extract the set of basic block addresses that participate in cycles.
• Store this set in the transient FunctionHandle.ctx dictionary (e.g., fh.ctx["cyclic_blocks"]).
• In the instruction extractor, simply check if the instruction's parent basic block address is in that set. This is a fast $O(1)$ lookup with no heavy object creation at the instruction level, and the memory is freed as soon as capa moves to the next function.

3. Cross-Backend Consistency

Since capa rules strive to be backend-agnostic, this pattern should be applied across all static backends (Vivisect, Ghidra, IDA, etc.) that already support the function-level loop characteristic.

This approach fits perfectly into capa's style of using transient handle contexts for performance optimization while keeping the rule language intuitive. Let me know what you think!

[larchchen]

Thanks for your comments @mike-hunhoff

I have made changes according to you suggestions, maybe you want to take a look again.

However, I have a few more questions:

1. If we are firing a "loop" characteristics for every instruction in a loop, wouldn't it resulting into too large feature spaces to match as well?
2. The instruction feature generation runs before the function feature generation inside static.py, so I need to calculate the cyclic_blocks at the time of FunctionContext __post_init__ instead of at the function iteration.

If it looks good to you, I'll make the similar changes to other extractors.

[williballenthin]

id be curious to see some examples of rules that use this new feature

[williballenthin]

we haven't used post_init yet in this codebase so i wonder if you could do this in a way that's more consistent.

perhaps via a constructor or from_foo(...) classmethod.

[williballenthin]

maybe this could be placed into AnalysisContext (as a dict keyed by vertex)?

[larchchen]

I don't think put it into AnalysisContext is a good idea for now, as AnalysisContext is more about global data can be repeated used, but this one is only used within a function scope. Depending on the program complexity, the data may not be very small if we keep the all loops information across the entire scan life-span.

Keeping it inside FunctionContext will just let the data in RAM within single function feature generation, and will be GC-ed right after.

Although I feel post_init is kinda standard approach for dataclass, I can also just put the code inside get_functions of BinExport2FeatureExtractor, make it part of the intialiser list.

How about that?

[larchchen]

id be curious to see some examples of rules that use this new feature

I gave out some snippets of rule examples in the first comment. How does it look to you?