Errors analyzing several ELF binaries

[q2dg]

Description

I've trying last released capa on several standard binaries from my Fedora 43 system but results are very disappointing.

Steps to Reproduce

When doing capa /bin/ls I get this result, which is shocking ("parse credit card information??")...

...but well, I could be. What it's not normal is that doing capa /usr/bin/gimp , capa remains stuck indefinitely or doing _capa -v ./yr (where "yr" is this binary: https://github.com/VirusTotal/yara-x/releases/download/v1.10.0/yara-x-v1.10.0-aarch64-unknown-linux-gnu.gz) I get this fatal error:

Expected behavior:

I would like to see coherent results/no errors analyzing linux binary files. I think this scope (ELF files in general) needs a bit of your love. Thanks!

Versions

Capa: 9.3.1
Kernel: 6.17.8-300.fc43.x86_64
Fedora: 43

[mr-tz]

Hey, thanks for the report. The parse credit card is a rule false positive hit. The rule isn't great and we can definitely tweak that.

For the ELF error there is an issue with the underlying analysis backend vivisect. I'll report the error upstream.

[akshat4703]

@williballenthin i am drafting a proposal for the PR i pushed #2914. My appology for not getting to discussion first and start implementing, here's what i think of this issue.

What I noticed

While experimenting with ELF analysis, I ran into a few behaviors that might be worth discussing:

• capa /usr/bin/gimp can take a very long time to finish.
• Some ELF samples can trigger backend exceptions instead of exiting cleanly.
• capa /bin/ls sometimes reports capabilities that seem unexpected for a normal system binary.

Quick repro examples

• capa /bin/ls
• capa /usr/bin/gimp
• capa -vv /bin/ls
• capa --debug /usr/bin/gimp

Example sample that previously triggered backend issues:

• yara-x-v1.10.0-aarch64-unknown-linux-gnu (from the yara-x release artifacts)

Observations

From looking at debug output:

• ELF workspace creation and viv analysis can be expensive on large binaries.
• Some viv analysis stages seem to take a very long time on big userland programs.
• Architecture-specific viv imports can fail when the binary architecture isn’t supported.

Possible directions

A few approaches that might be worth considering:

• A: Add basic guardrails so backend failures produce clean errors instead of crashes.
• B: Add some limits or guardrails for very large ELF analyses so they don't appear to hang.
• C: Review whether some viv analysis modules should be limited or disabled for ELF.

@williballenthin since you suggested opening a discussion before proposing a PR, I wanted to check if this direction makes sense.

Do you think this is something worth addressing in capa, and if so, which direction (A/B/C above, or something else) would you recommend exploring first?

Happy to investigate further or prototype a small change once there’s alignment.

[Young-Lord]

I am trying to optimize the rules to reduce false positive rate, by testing it on several well-behaved binaries.
Or, is it more preferable to add good binaries to tests, in order to reduce overall false positive rate?