rea/docs/provider-evaluation.md

6.8 KiB

Static-analysis provider evaluation

Status: research for issue #26; no provider implementation is approved by this note.

REA should add another analysis provider only after the provider-neutral capability contracts, Evidence v2 metadata, ownership rules, and multi-fixture conformance suite are complete. A provider is not a drop-in replacement for Hopper: every capability must be mapped explicitly, with truthful unavailable results where the engine cannot provide equivalent semantics.

Shortlist

Provider License / automation surface What it brings REA fit and blockers
Ghidra Apache-2.0 source license; analyzeHeadless, Java APIs, and PyGhidra Broad static analysis, many processors and formats, scripting, and project/database workflows Strong candidate for a full provider. Requires a Java/JDK runtime, isolated project/cache directories, process supervision, and a stable adapter for Ghidra's project-oriented model.
Rizin / rz-pipe Rizin repository contains LGPL-3.0 and GPL-3.0 components; rizin, rz-bin, and language bridges through rzpipe Portable CLI analysis, disassembly/debugging, many architectures and file formats, JSON command output Good candidate for a process-backed Linux provider and fast metadata fallback. License/component inventory must be preserved; command output needs version-pinned parsers and semantic conformance before evidence is trusted.
LIEF Apache-2.0; C++, Python, and other bindings Deterministic parsing and modification of ELF, PE, Mach-O, COFF, and related executable formats; headers, sections, symbols, relocations, and functions Best near-term complement, not a decompiler replacement. It can cover format metadata and artifact evidence without a long-lived analysis process; function semantics, pseudocode, CFG, and cross-reference parity remain out of scope unless separately demonstrated.
Binary Ninja API/documentation components are MIT, while the analysis product is licensed by edition; commercial, Ultimate, or Headless license is required for headless automation Python/Core/C++/Rust APIs, headless loading, IL layers, function analysis, plugins, and configurable analysis Strong technical fit for a native provider, especially function dossiers. Commercial licensing, license-secret handling, native runtime packaging, and multithreaded lifecycle rules are material deployment blockers.
  1. Use LIEF first for provider-neutral binary metadata where the current contracts already describe headers, sections, symbols, and relocations.
  2. Evaluate Rizin as a separate process provider for portable disassembly and command-backed queries, with JSON-only parsing and fixture assertions.
  3. Evaluate Ghidra or Binary Ninja for decompilation and richer function semantics only after the conformance fixtures can compare evidence by capability rather than by provider-specific output text.

Required admission gate

Before implementation, an adapter proposal must provide:

  • a capability matrix covering supported, unsupported, and degraded results;
  • provider identity, version, target digest, authority, limitations, and deterministic locations in every Evidence v2 record;
  • bounded subprocess or library lifetime, cancellation, timeouts, and cleanup;
  • sanitized diagnostics that do not expose license material, host paths, or provider tracebacks;
  • the same source-owned fixture corpus across architectures and formats;
  • repeatable checks for function identity, addresses, strings, names, xrefs, CFG, and pseudocode wherever those capabilities are claimed.

This keeps issue #26 a decision record rather than prematurely committing REA to an engine whose semantics or redistribution terms have not been verified.

Primary-source notes