[GH-ISSUE #1451] [Feature] support droidasc for REA Android reverse feature #493

New issue

Open

opened 2026-10-15 18:25:34 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:25:34 +00:00

Owner

Originally created by @MG1937 on GitHub (Oct 10, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1451

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Current limitation

jadx headless mcp is too slow for real work. jadx on APKs over 100MB is painfully slow and eats tons of memory. Large scale APK reversing is basically blocked. Even headless mcp is no exception. When you need to continuously monitor hundreds of APKs in a pipeline, it's basically unusable. The environment OOMs constantly.

Use cases

Analyze dozens to hundreds of large commercial APKs in a pipeline at once.
Analyze dozens to hundreds of preinstalled APKs from a phone ROM to hunt bugs.
Global xref on a 300MB APK.
Large scale bug bounty scanning.

Desired outcome and success criteria

droidasc supported as an alternative backend for REA Android reverse.

Analysis in milliseconds, not tens of minutes.
Global xref on a 300MB APK in 1.5s worst case.
No memory bloat or parsing slowdown.
Scales to hundreds of APKs without lag.

Authority boundaries and non-goals

No target mutation. No credential or sensitive data handling changes. Licensing and provenance stay as-is. Not asking to remove jadx support, only to add droidasc.

Alternatives considered

jadx mcp and jadx headless mcp. Both too slow and too memory hungry for large scale work. Headless does not fix the preprocessing cost.

Possible direction

Add droidasc as a pluggable backend for the Android reverse feature. Keep jadx as fallback.

References

https://github.com/MG1937/ASC

Used droidasc with codex to analyze phones from 3 different brands. Found 2 RCEs and 5 root bugs in a few days. Details planned for Black Hat Asia 2027.
A friend used droidasc to scan bug bounty targets at scale and found 10+ RCEs.
Literally hundreds of times faster than jadx.

Originally created by @MG1937 on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1451 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Current limitation jadx headless mcp is too slow for real work. jadx on APKs over 100MB is painfully slow and eats tons of memory. Large scale APK reversing is basically blocked. Even headless mcp is no exception. When you need to continuously monitor hundreds of APKs in a pipeline, it's basically unusable. The environment OOMs constantly. ### Use cases - Analyze dozens to hundreds of large commercial APKs in a pipeline at once. - Analyze dozens to hundreds of preinstalled APKs from a phone ROM to hunt bugs. - Global xref on a 300MB APK. - Large scale bug bounty scanning. ### Desired outcome and success criteria droidasc supported as an alternative backend for REA Android reverse. - Analysis in milliseconds, not tens of minutes. - Global xref on a 300MB APK in 1.5s worst case. - No memory bloat or parsing slowdown. - Scales to hundreds of APKs without lag. ### Authority boundaries and non-goals No target mutation. No credential or sensitive data handling changes. Licensing and provenance stay as-is. Not asking to remove jadx support, only to add droidasc. ### Alternatives considered jadx mcp and jadx headless mcp. Both too slow and too memory hungry for large scale work. Headless does not fix the preprocessing cost. ### Possible direction Add droidasc as a pluggable backend for the Android reverse feature. Keep jadx as fallback. ### References https://github.com/MG1937/ASC - Used droidasc with codex to analyze phones from 3 different brands. Found 2 RCEs and 5 root bugs in a few days. Details planned for Black Hat Asia 2027. - A friend used droidasc to scan bug bounty targets at scale and found 10+ RCEs. - Literally hundreds of times faster than jadx. <img width="3784" height="414" alt="Image" src="https://github.com/user-attachments/assets/954d856c-ca80-43af-9f1d-f1598415278d" /> <img width="2186" height="1619" alt="Image" src="https://github.com/user-attachments/assets/22aff815-c419-43bd-badf-f2edd825c71d" />

bsakaguchi added the

area: runtime

P3: low

enhancement

labels

2026-10-15 18:25:34 +00:00

bsakaguchi commented

2026-10-15 18:25:35 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Provider Proposal & Resource Boundary Review

Evaluating droidasc as a fast indexer for massive Android APKs addresses real-world memory and execution timeouts seen with pure JADX decompilation on 100MB+ APKs:

Provider Boundary: Per AGENTS.md and CONTRIBUTING.md#contribution-scope:
- New providers require an explicit maintainer scope decision before deep integration.
- REA does not bundle third-party compiled binaries; integration must follow the bring-your-own model with external PATH/env detection.
Contract Mapping: If droidasc provides fast method indexing, string references, and class hierarchies, it could serve as a lightweight indexing provider before delegating focused method decompilation to JADX.

@matbrgz commented on GitHub (Oct 12, 2026): ### Provider Proposal & Resource Boundary Review Evaluating `droidasc` as a fast indexer for massive Android APKs addresses real-world memory and execution timeouts seen with pure JADX decompilation on 100MB+ APKs: - **Provider Boundary:** Per `AGENTS.md` and `CONTRIBUTING.md#contribution-scope`: - New providers require an explicit maintainer scope decision before deep integration. - REA does not bundle third-party compiled binaries; integration must follow the bring-your-own model with external PATH/env detection. - **Contract Mapping:** If `droidasc` provides fast method indexing, string references, and class hierarchies, it could serve as a lightweight indexing provider before delegating focused method decompilation to JADX.

bsakaguchi referenced this issue

2026-10-16 21:13:29 +00:00

[PR #493] [MERGED] docs: prioritize reusable analysis primitives #2025

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:15 +00:00