The future of Analysis

Tagging @fmagin.

Our current system of analyses being classes which are silently partially initialized is a huge hack. We should have something at least a little bit nicer.

My suggestion is that analyses can be any callable, and the versions available on project.analyses are partial applications which apply project and kb kwargs. This enables all the same hackability of the current system while enabling running analyses outside of the project.analyses hub for purposes of type annotation, or simply just preferring the less-magic paradigm.

[fmagin]

That seems kinda limiting for future features. I’d push for having a more rigid interface and some extra methods/properties that an analysis is expected to provide. I am currently writing a few analyses for Ghidra, and their interface requires e.g. a function to check if you can even sensible analyze the binary, their Analysis class has a priority system so you can define the order and “stage” of the analysis.

That analysis order is something I am annoyed with our internal analyses (which aren’t angr analyses, but IMO should be): There is an implicit requirement tree between them, but at best there is some check at the start of the constructor, typically they just crash if some expected data was not available. Ghidra has some number based system with stages https://ghidra.re/ghidra_docs/api/ghidra/app/services/AnalysisPriority.html But there could also be a system where you can explicitly specify another Analysis that has to run first, with an option to resolve this dependency tree automatically when calling an Analysis that has more complex requirements.

[github-actions[bot]]

This issue has been marked as stale because it has no recent activity. Please comment or add the pinned tag to prevent this issue from being closed.