morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #7244] [Feature] Project expected JNI/JNA symbol names and structural attack-surface facts from Android declarations #4311

New issue

Open

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

bsakaguchi commented

2026-10-31 00:48:48 +00:00

Owner

Originally created by @0xLLVEL on GitHub (Oct 26, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7244

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

Native analysis or decompilation

Current limitation

REA already parses an APK's manifest and DEX declarations, but two analyst questions still have to be re-derived by hand from raw text on every run:

Expected JNI/JNA symbol names. For a selected DEX class/method there is no operation that returns the symbol names native code would resolve (Java_pkg_Class_method, wide/short overloads, DEX shorty encoding). An agent re-derives these strings per call — token-expensive and inconsistent — or only discovers a mismatch when a symbol fails to resolve at load time.
Ranked exposure of manifest components. The component inventory is returned as declarations, but nothing ranks which exported components are reachable without a permission guard versus guarded versus unknown, nor builds the intent-action index, foreground-service-type, and provider-authority summaries needed for triage.

There is also no documented playbook for packed and split APKs: what REA can and cannot observe once the manifest or classes live outside the plain APK layout.

Use cases

Triage: an agent asks "what in this APK is externally reachable?" and needs the unguarded-export list before committing to deeper analysis.
Native bridge debugging: comparing the Java-side method signature against the symbol a bundled .so expects.

Both occur on every Android analysis session and both currently re-parse the same declarations ad hoc.

Desired outcome and success criteria

Two projection operations, project_android_jni_names and project_android_attack_surface, over caller-selected declarations (no APK re-read):

JNI projection returns per-method expected names, overload grouping, and explicit "string projection, not a runtime check" limitations.
Attack-surface projection returns exported-without-guard / guarded / unknown findings with permission provenance, an intent-action index, and propagates component coverage (complete/partial/unknown) instead of claiming absence.
Results are retained Evidence with derived confidence and analyst-inference authority; docs gain a packed/split APK playbook.

Success: an agent answers both questions with one tool call each, with coverage and unknowns visible in the answer.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

The new operations are pure string/schema projections over caller-selected facts: no APK execution, no injection, no network, no provider startup. The surrounding inspection workflow they feed reads local APK files only.

Verification available so far

I have a prototype or observed results

Verification details (optional)

Implementation exists on branch feat/android-component-inventory: unit tests for both projections (androidJniNames.test.ts, androidAttackSurface.test.ts) plus MCP boundary coverage. Locally executed: npm run check green (typecheck, lint, format, knip, metadata; architecture guards across 2105 source files) and focused android tests 4/4 files. Full-suite and real-JADX runs remain open proof gaps.

Alternatives considered

Deriving names ad hoc in the agent prompt on each call: repeated token cost, no retained Evidence, inconsistent overload handling.
Asking JADX for the symbols: it does not project JNI export names for selected methods.

Possible direction

Linking the projections into the inspect_android_package summary view later; not required for this request.

References

docs/android-analysis.md and docs/android-packed-analysis.md in the linked pull request.

Originally created by @0xLLVEL on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7244 ### 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 Native analysis or decompilation ### Current limitation REA already parses an APK's manifest and DEX declarations, but two analyst questions still have to be re-derived by hand from raw text on every run: 1. **Expected JNI/JNA symbol names.** For a selected DEX class/method there is no operation that returns the symbol names native code would resolve (`Java_pkg_Class_method`, wide/short overloads, DEX shorty encoding). An agent re-derives these strings per call — token-expensive and inconsistent — or only discovers a mismatch when a symbol fails to resolve at load time. 2. **Ranked exposure of manifest components.** The component inventory is returned as declarations, but nothing ranks which exported components are reachable without a permission guard versus guarded versus unknown, nor builds the intent-action index, foreground-service-type, and provider-authority summaries needed for triage. There is also no documented playbook for packed and split APKs: what REA can and cannot observe once the manifest or classes live outside the plain APK layout. ### Use cases - **Triage:** an agent asks "what in this APK is externally reachable?" and needs the unguarded-export list before committing to deeper analysis. - **Native bridge debugging:** comparing the Java-side method signature against the symbol a bundled `.so` expects. Both occur on every Android analysis session and both currently re-parse the same declarations ad hoc. ### Desired outcome and success criteria Two projection operations, `project_android_jni_names` and `project_android_attack_surface`, over caller-selected declarations (no APK re-read): - JNI projection returns per-method expected names, overload grouping, and explicit "string projection, not a runtime check" limitations. - Attack-surface projection returns exported-without-guard / guarded / unknown findings with permission provenance, an intent-action index, and propagates component coverage (`complete`/`partial`/`unknown`) instead of claiming absence. - Results are retained Evidence with `derived` confidence and analyst-inference authority; docs gain a packed/split APK playbook. Success: an agent answers both questions with one tool call each, with coverage and unknowns visible in the answer. ### Expected interaction with targets - Read existing files or captured data ### Target and scope details (optional) The new operations are pure string/schema projections over caller-selected facts: no APK execution, no injection, no network, no provider startup. The surrounding inspection workflow they feed reads local APK files only. ### Verification available so far - I have a prototype or observed results ### Verification details (optional) Implementation exists on branch `feat/android-component-inventory`: unit tests for both projections (`androidJniNames.test.ts`, `androidAttackSurface.test.ts`) plus MCP boundary coverage. Locally executed: `npm run check` green (typecheck, lint, format, knip, metadata; architecture guards across 2105 source files) and focused android tests 4/4 files. Full-suite and real-JADX runs remain open proof gaps. ### Alternatives considered - Deriving names ad hoc in the agent prompt on each call: repeated token cost, no retained Evidence, inconsistent overload handling. - Asking JADX for the symbols: it does not project JNI export names for selected methods. ### Possible direction Linking the projections into the `inspect_android_package` summary view later; not required for this request. ### References `docs/android-analysis.md` and `docs/android-packed-analysis.md` in the linked pull request.

bsakaguchi referenced this issue

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

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4311

No description provided.

Rows
Columns