[GH-ISSUE #8139] [Feature] Consider IDASQL as an additional IDA backend #4685

New issue

Open

opened 2026-10-31 00:52:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:52:26 +00:00

Owner

Originally created by @w-o0 on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8139

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Provider or capability discovery

Current limitation

Users who already use IDASQL with IDA cannot currently reuse that integration as a backend for REA's own binary-analysis workflows. Orchestrating REA and IDASQL separately from the same coding agent is useful, but does not make IDASQL available to REA itself.

Would you consider supporting IDASQL as an additional IDA backend?

Use cases

Reuse an already-open IDA database and its existing analysis/annotations for REA workflows, without configuring a second IDA integration stack. This is an expected usability benefit; no performance or adoption measurements are available.

Desired outcome and success criteria

Allow REA to connect to IDASQL and return its normal analysis results for binary identity/input hash/image base, functions, strings, disassembly, pseudocode when a compatible decompiler is available, and cross-references/caller/callee queries.

An initial version could focus on read-only access to an already-open database. Unsupported capabilities should be reported explicitly.

Expected interaction with targets

Read existing files or captured data, Contact network services, Not sure yet

Target and scope details (optional)

Initial proposal: static analysis of a user-selected, already-open IDA database through an existing IDASQL service. No automatic target launch/attach, debugger control, database editing, or arbitrary SQL/Python passthrough is requested. Local HTTP communication is expected; upstream initialization, caching and any incidental persistence would need to be reviewed before integration.

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

Idea only: no adapter has been implemented or validated. Proposed checks would compare REA results against a small known sample through a real IDASQL connection, verify input hash/image base and 64-bit address preservation, distinguish call edges from ordinary code references, and check pagination, truncation and missing-decompiler errors.

Alternatives considered

Call REA and IDASQL independently from the same coding agent, or configure an existing supported REA IDA backend. These do not let REA itself consume IDASQL-backed analysis.

Possible direction

An optional native provider or a documented compatibility bridge could translate REA's IDA operations into IDASQL queries through its actual HTTP/MCP integration. This is a possible direction, not a required design. Automatic database lifecycle management and write operations could be considered separately.

Would an IDASQL backend, or an extension interface for such an adapter, fit REA's direction?

References

IDASQL: https://github.com/allthingsida/idasql (SQL access to live IDA tables; HTTP and MCP integration options)
REA IDA provider guide: https://github.com/morluto/rea/blob/main/docs/ida-provider.md

This is a feature suggestion, not a claim of an existing working integration.

Originally created by @w-o0 on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8139 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Provider or capability discovery ### Current limitation Users who already use IDASQL with IDA cannot currently reuse that integration as a backend for REA's own binary-analysis workflows. Orchestrating REA and IDASQL separately from the same coding agent is useful, but does not make IDASQL available to REA itself. Would you consider supporting IDASQL as an additional IDA backend? ### Use cases Reuse an already-open IDA database and its existing analysis/annotations for REA workflows, without configuring a second IDA integration stack. This is an expected usability benefit; no performance or adoption measurements are available. ### Desired outcome and success criteria Allow REA to connect to IDASQL and return its normal analysis results for binary identity/input hash/image base, functions, strings, disassembly, pseudocode when a compatible decompiler is available, and cross-references/caller/callee queries. An initial version could focus on read-only access to an already-open database. Unsupported capabilities should be reported explicitly. ### Expected interaction with targets Read existing files or captured data, Contact network services, Not sure yet ### Target and scope details (optional) Initial proposal: static analysis of a user-selected, already-open IDA database through an existing IDASQL service. No automatic target launch/attach, debugger control, database editing, or arbitrary SQL/Python passthrough is requested. Local HTTP communication is expected; upstream initialization, caching and any incidental persistence would need to be reviewed before integration. ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) Idea only: no adapter has been implemented or validated. Proposed checks would compare REA results against a small known sample through a real IDASQL connection, verify input hash/image base and 64-bit address preservation, distinguish call edges from ordinary code references, and check pagination, truncation and missing-decompiler errors. ### Alternatives considered Call REA and IDASQL independently from the same coding agent, or configure an existing supported REA IDA backend. These do not let REA itself consume IDASQL-backed analysis. ### Possible direction An optional native provider or a documented compatibility bridge could translate REA's IDA operations into IDASQL queries through its actual HTTP/MCP integration. This is a possible direction, not a required design. Automatic database lifecycle management and write operations could be considered separately. Would an IDASQL backend, or an extension interface for such an adapter, fit REA's direction? ### References - IDASQL: https://github.com/allthingsida/idasql (SQL access to live IDA tables; HTTP and MCP integration options) - REA IDA provider guide: https://github.com/morluto/rea/blob/main/docs/ida-provider.md This is a feature suggestion, not a claim of an existing working integration.

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:52:26 +00:00

bsakaguchi referenced this issue

2026-10-31 01:14:06 +00:00

[PR #4755] [MERGED] fix(javascript): report malformed runtime context events as excluded #6389