[GH-ISSUE #3019] [Provider proposal] Rizin as a native deep-analysis provider #1057

New issue

Open

opened 2026-10-15 18:30:43 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:30:43 +00:00

Owner

Originally created by @Zfinix on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3019

Proposal: a Rizin deep-analysis provider

Problem and proposed first slice

REA's deep providers today are Ghidra, Hopper and IDA. Ghidra is the only free one, and it needs a JVM and a slow first analysis. Rizin is free (LGPL-3.0), native, and opens most binaries in about a second.

I propose an optional rizin provider that drives a user-installed rizin executable as an owned subprocess over its pipe protocol (rizin -q0, NUL-terminated replies, JSON commands). The first slice would match IDA's read-only set:

list_procedures, search_procedures (aflj)
list_strings, search_strings (izzj)
procedure_address, procedure_assembly, read_function_instructions (pdfj)
procedure_callers, procedure_callees, xrefs (axtj, axfj)
procedure_pseudo_code only when a decompiler plugin is installed (pdg from rz-ghidra, or pdc), reported as unavailable otherwise
analyze_function

No writes, no renames or comments, and no process launch beyond the owned rizin process.

Shape

src/rizin/ adapter implementing AnalysisProviderCandidate, registered in src/composition/binary.ts next to the others.
inspectAvailability reports executable_missing / unsupported_version without starting an analysis. The executable comes from PATH or an explicit setting, never installed automatically.
inspectTargetSupport uses Rizin's own format and architecture detection.
"rizin" added to DOCTOR_PROVIDER_IDS and the vitest provider glob.
Selection stays explicit (provider_id: "rizin" or REA_ANALYSIS_PROVIDER=rizin), so auto keeps its single-candidate rule.

Evidence available now

No REA code exists yet. In a downstream app (Eleven, which embeds REA), we already read Mach-O, ELF and PE files through a long-lived rizin process with the commands above. A run on macOS /bin/ls lists 135 functions and returns assembly for the entry point in about a second. Pseudocode works when rz-ghidra is installed. That is evidence for the command set, not for REA integration.

Verification planned before integration

Unit tests with a fake pipe, a composition test, and a tests/conformance/rizin/providerContracts.test.ts against the shared tool contracts.
A real-provider lane (verify:rizin) against the source-built conformance fixtures, with and without a decompiler plugin.
Missing executable, wrong version, unsupported format, malformed output, timeout and cleanup cases.
docs/rizin-provider.md, README provider section, and a third-party notice.

Maintainer decision requested

Is a Rizin provider in scope? Is IDA's read-only operation set the right first slice? Should pseudocode from a decompiler plugin be one provider or a separate capability flag?

Related: #2258 (recommends Rizin with rz-ghidra), #1389 (rsleigh provider candidate), #2300 (pseudocode from several providers).

Originally created by @Zfinix on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3019 # Proposal: a Rizin deep-analysis provider ## Problem and proposed first slice REA's deep providers today are Ghidra, Hopper and IDA. Ghidra is the only free one, and it needs a JVM and a slow first analysis. Rizin is free (LGPL-3.0), native, and opens most binaries in about a second. I propose an optional `rizin` provider that drives a user-installed `rizin` executable as an owned subprocess over its pipe protocol (`rizin -q0`, NUL-terminated replies, JSON commands). The first slice would match IDA's read-only set: - `list_procedures`, `search_procedures` (`aflj`) - `list_strings`, `search_strings` (`izzj`) - `procedure_address`, `procedure_assembly`, `read_function_instructions` (`pdfj`) - `procedure_callers`, `procedure_callees`, `xrefs` (`axtj`, `axfj`) - `procedure_pseudo_code` only when a decompiler plugin is installed (`pdg` from rz-ghidra, or `pdc`), reported as unavailable otherwise - `analyze_function` No writes, no renames or comments, and no process launch beyond the owned `rizin` process. ## Shape - `src/rizin/` adapter implementing `AnalysisProviderCandidate`, registered in `src/composition/binary.ts` next to the others. - `inspectAvailability` reports `executable_missing` / `unsupported_version` without starting an analysis. The executable comes from PATH or an explicit setting, never installed automatically. - `inspectTargetSupport` uses Rizin's own format and architecture detection. - `"rizin"` added to `DOCTOR_PROVIDER_IDS` and the vitest provider glob. - Selection stays explicit (`provider_id: "rizin"` or `REA_ANALYSIS_PROVIDER=rizin`), so `auto` keeps its single-candidate rule. ## Evidence available now No REA code exists yet. In a downstream app (Eleven, which embeds REA), we already read Mach-O, ELF and PE files through a long-lived `rizin` process with the commands above. A run on macOS `/bin/ls` lists 135 functions and returns assembly for the entry point in about a second. Pseudocode works when rz-ghidra is installed. That is evidence for the command set, not for REA integration. ## Verification planned before integration - Unit tests with a fake pipe, a composition test, and a `tests/conformance/rizin/providerContracts.test.ts` against the shared tool contracts. - A real-provider lane (`verify:rizin`) against the source-built conformance fixtures, with and without a decompiler plugin. - Missing executable, wrong version, unsupported format, malformed output, timeout and cleanup cases. - `docs/rizin-provider.md`, README provider section, and a third-party notice. ## Maintainer decision requested Is a Rizin provider in scope? Is IDA's read-only operation set the right first slice? Should pseudocode from a decompiler plugin be one provider or a separate capability flag? Related: #2258 (recommends Rizin with rz-ghidra), #1389 (rsleigh provider candidate), #2300 (pseudocode from several providers).

bsakaguchi added the

provider-request

area: native

enhancement

labels

2026-10-15 18:30:43 +00:00

bsakaguchi referenced this issue

2026-10-17 21:08:12 +00:00

[PR #1057] [MERGED] fix(process): stop failing captures on tokens macOS cannot expose #2610

bsakaguchi referenced this issue

2026-10-17 21:08:29 +00:00

[PR #1091] [MERGED] fix(ci): restore generated shard inputs and cleanup assertions #2639