[GH-ISSUE #5198] Would you accept borer as a native analysis provider? #3188

New issue

Open

opened 2026-10-31 00:37:39 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:37:39 +00:00

Owner

Originally created by @imjustprism on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5198

Before submitting

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

Decision needed

Would you accept borer as a native analysis provider, limited to static, read-only analysis? If yes, should REA call it through a CLI with JSON output (like Kuna) or over MCP via stdio?

Context and evidence

borer is a decompiler written in Rust that ships as one executable, with no Java, Ghidra or IDA needed. It reads x86/x64 PE and ELF and runs on Windows, macOS and Linux, which could cover Windows and PE where Kuna doesn't yet.

Expected interaction with targets

Read existing files or captured data

Boundary details

Only static, read-only tools would be exposed: functions, pseudocode, assembly, callers/callees, strings and xrefs. Nothing that runs or attaches to a process.

Verification available so far

Not sure yet

Success criteria and open questions

If you're open to it, I'm happy to build the provider and send a PR.

Originally created by @imjustprism on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5198 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [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 discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Would you accept [borer](https://github.com/imjustprism/borer) as a native analysis provider, limited to static, read-only analysis? If yes, should REA call it through a CLI with JSON output (like Kuna) or over MCP via stdio? ### Context and evidence borer is a decompiler written in Rust that ships as one executable, with no Java, Ghidra or IDA needed. It reads x86/x64 PE and ELF and runs on Windows, macOS and Linux, which could cover Windows and PE where Kuna doesn't yet. ### Expected interaction with targets - Read existing files or captured data ### Boundary details Only static, read-only tools would be exposed: functions, pseudocode, assembly, callers/callees, strings and xrefs. Nothing that runs or attaches to a process. ### Verification available so far Not sure yet ### Success criteria and open questions If you're open to it, I'm happy to build the provider and send a PR.

bsakaguchi commented

2026-10-31 00:37:40 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

Strong +1 for a static read-only decompiler provider. The single-executable, no-Java/Ghidra/IDA dependency is a big win, and PE/Windows coverage where Kuna doesn't reach makes it complementary rather than overlapping. On integration, I'd lean toward CLI with JSON output (consistent with Kuna): borer's standalone binary maps naturally to a subprocess call, and the boundary stays simple since you're only exposing read-only queries. If the provider framework already standardizes on MCP stdio for uniform client handling, matching that is fair too — but for a purely static tool the CLI route seems lower-friction to start. Would love to see this land.//

@XinwangTao commented on GitHub (Oct 19, 2026): Strong +1 for a static read-only decompiler provider. The single-executable, no-Java/Ghidra/IDA dependency is a big win, and PE/Windows coverage where Kuna doesn't reach makes it complementary rather than overlapping. On integration, I'd lean toward CLI with JSON output (consistent with Kuna): borer's standalone binary maps naturally to a subprocess call, and the boundary stays simple since you're only exposing read-only queries. If the provider framework already standardizes on MCP stdio for uniform client handling, matching that is fair too — but for a purely static tool the CLI route seems lower-friction to start. Would love to see this land.//

bsakaguchi referenced this issue

2026-10-31 00:37:40 +00:00

[GH-ISSUE #5195] [Bug] compare-application-versions reports unchanged module exports as removed and added #3187

bsakaguchi referenced this issue

2026-10-31 00:38:40 +00:00

[GH-ISSUE #5406] [Bug] compare-application-versions pairs unresolved endpoints by equal expression text #3276

bsakaguchi referenced this issue

2026-10-31 00:44:47 +00:00

[GH-ISSUE #6456] [Bug] compare-source-to-bundle counts one JavaScript file as split or duplicated #3868

bsakaguchi referenced this issue

2026-11-01 21:43:10 +00:00

[PR #5196] [MERGED] fix(javascript): match unchanged module exports across application versions #6808