morluto/rea

Fork 0

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

[GH-ISSUE #3374] [Feature] `rea doctor` readiness check for the JADX (Android) provider #1242

New issue

Open

opened 2026-10-16 21:03:13 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

Originally created by @Rinkia on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3374

Before submitting

I searched the open and closed issues and pull requests for a related proposal. (Searched "doctor jadx"; nothing found.)
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

rea doctor --provider accepts only the native providers. Asking for JADX fails validation:

$ rea doctor --provider jadx
code: VALIDATION_ERROR
message: Invalid option: expected one of "hopper"|"ghidra"|"ida"

(rea-agents@6.4.0, Linux x64 container, JDK 21.)

This means I can't check, before running an analysis, whether Android analysis is ready:

whether REA_JADX_MCP_JAR is set, absolute and readable;
whether the JAR matches the pinned jadx-headless-mcp 0.7.1 sha256;
whether the selected Java (JAVA_HOME or PATH) is a full JDK 17 or newer with the compiler module, as docs/android-analysis.md requires;
whether a procps-compatible ps is on PATH (Linux).

Today the only way to find out is to run a real operation such as inspect-android-package on an APK and read the failure.

Use cases

First-time setup, or a container image build: a single command to confirm the Android toolchain, just as --provider ghidra does for Ghidra.
Agents deciding whether Android tools are worth calling before they spend a session on a target.

Desired outcome and success criteria

rea doctor --provider jadx (or a separately named Android check) reports scoped checks in the same shape as the Ghidra ones: JAR path present, JAR digest matches the pinned release, a full JDK of an accepted version, and ps available on Linux.
A mismatched digest or a JRE-only Java produces a specific classification and remediation, not a generic failure.
If adding jadx to --provider is the wrong fit (it isn't a native deep-analysis provider), any discoverable equivalent would meet the need.

Expected interaction with targets

Read existing files or captured data (the JAR and the JDK installation only; no target is needed).

Verification available so far

I can suggest a sample or manual check.

Verification details

Observed on rea-agents@6.4.0 in Docker (Ubuntu 24.04, eclipse-temurin:21-jdk, REA_JADX_MCP_JAR set to the pinned JAR):

rea doctor --provider jadx returns the VALIDATION_ERROR above.
With the same environment, rea inspect-android-package /targets/editor.apk succeeds (JADX 0.7.1 bridge, jar_sha256 6e5eacf5…, 163 classes). So the environment is ready, but doctor has no way to say so.

Manual check for the new behaviour: run doctor with REA_JADX_MCP_JAR unset, then pointing at a modified copy of the JAR, then with a JRE-only JAVA_HOME. Expect three distinct, actionable failures.

Alternatives considered

rea capabilities. In the same environment it lists 18 operations and none of them are Android operations, whether or not REA_JADX_MCP_JAR is set. It doesn't cover this case today.
Running a real APK operation as a smoke test. That works, but it needs a sample APK and starts the JVM.

Possible direction

Reuse the pinned release metadata in src/android/JadxRelease.ts for the digest check, and the Ghidra installation's JDK validation for the Java check.

References

docs/android-analysis.md (JDK 17+ requirement, pinned JAR and sha256, the Linux ps prerequisite)
src/android/JadxRelease.ts

Originally created by @Rinkia on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3374 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. (Searched "doctor jadx"; nothing found.) - [x] I understand the 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 `rea doctor --provider` accepts only the native providers. Asking for JADX fails validation: ```text $ rea doctor --provider jadx code: VALIDATION_ERROR message: Invalid option: expected one of "hopper"|"ghidra"|"ida" ``` (`rea-agents@6.4.0`, Linux x64 container, JDK 21.) This means I can't check, before running an analysis, whether Android analysis is ready: - whether `REA_JADX_MCP_JAR` is set, absolute and readable; - whether the JAR matches the pinned `jadx-headless-mcp` 0.7.1 sha256; - whether the selected Java (`JAVA_HOME` or `PATH`) is a full JDK 17 or newer with the compiler module, as `docs/android-analysis.md` requires; - whether a procps-compatible `ps` is on `PATH` (Linux). Today the only way to find out is to run a real operation such as `inspect-android-package` on an APK and read the failure. ### Use cases - First-time setup, or a container image build: a single command to confirm the Android toolchain, just as `--provider ghidra` does for Ghidra. - Agents deciding whether Android tools are worth calling before they spend a session on a target. ### Desired outcome and success criteria - `rea doctor --provider jadx` (or a separately named Android check) reports scoped checks in the same shape as the Ghidra ones: JAR path present, JAR digest matches the pinned release, a full JDK of an accepted version, and `ps` available on Linux. - A mismatched digest or a JRE-only Java produces a specific classification and remediation, not a generic failure. - If adding `jadx` to `--provider` is the wrong fit (it isn't a native deep-analysis provider), any discoverable equivalent would meet the need. ### Expected interaction with targets Read existing files or captured data (the JAR and the JDK installation only; no target is needed). ### Verification available so far I can suggest a sample or manual check. ### Verification details Observed on `rea-agents@6.4.0` in Docker (Ubuntu 24.04, `eclipse-temurin:21-jdk`, `REA_JADX_MCP_JAR` set to the pinned JAR): - `rea doctor --provider jadx` returns the `VALIDATION_ERROR` above. - With the same environment, `rea inspect-android-package /targets/editor.apk` succeeds (JADX 0.7.1 bridge, `jar_sha256` 6e5eacf5…, 163 classes). So the environment is ready, but `doctor` has no way to say so. Manual check for the new behaviour: run doctor with `REA_JADX_MCP_JAR` unset, then pointing at a modified copy of the JAR, then with a JRE-only `JAVA_HOME`. Expect three distinct, actionable failures. ### Alternatives considered - `rea capabilities`. In the same environment it lists 18 operations and none of them are Android operations, whether or not `REA_JADX_MCP_JAR` is set. It doesn't cover this case today. - Running a real APK operation as a smoke test. That works, but it needs a sample APK and starts the JVM. ### Possible direction Reuse the pinned release metadata in `src/android/JadxRelease.ts` for the digest check, and the Ghidra installation's JDK validation for the Java check. ### References - `docs/android-analysis.md` (JDK 17+ requirement, pinned JAR and sha256, the Linux `ps` prerequisite) - `src/android/JadxRelease.ts`

bsakaguchi commented

2026-10-16 21:03:15 +00:00

Author

Owner

@Rinkia commented on GitHub (Oct 14, 2026):

Update from rea-agents@6.5.0 (Linux x64 container): rea doctor --provider jadx now exists, which covers most of this request. Thanks!

Verified behaviour:

Setup	`doctor --provider jadx`
Normal (`REA_JADX_MCP_JAR` set, JDK 21)	`healthy`: "JADX MCP bridge JAR validated at …"
`REA_JADX_MCP_JAR=/nonexistent.jar`	`jadx: config_drift` (ENOENT)
`JAVA_HOME=/nope`, no `java` on `PATH`	`jadx: missing_dependency`
`REA_JADX_HEAP_MIB=64`	`healthy`, while `inspect-android-package` on a public APK fails with `Java heap space`

So the JAR and Java checks from the original ask are covered. What's left is that the effective JADX heap isn't reported, so a heap that's too small looks healthy. I've filed that with a public reproduction as #3517. Unless you'd like to keep this issue open for the heap or JDK-version detail, #3517 could track the remainder.

@Rinkia commented on GitHub (Oct 14, 2026): Update from `rea-agents@6.5.0` (Linux x64 container): `rea doctor --provider jadx` now exists, which covers most of this request. Thanks! Verified behaviour: | Setup | `doctor --provider jadx` | |---|---| | Normal (`REA_JADX_MCP_JAR` set, JDK 21) | `healthy`: "JADX MCP bridge JAR validated at …" | | `REA_JADX_MCP_JAR=/nonexistent.jar` | `jadx: config_drift` (ENOENT) | | `JAVA_HOME=/nope`, no `java` on `PATH` | `jadx: missing_dependency` | | `REA_JADX_HEAP_MIB=64` | `healthy`, while `inspect-android-package` on a public APK fails with `Java heap space` | So the JAR and Java checks from the original ask are covered. What's left is that the effective JADX heap isn't reported, so a heap that's too small looks healthy. I've filed that with a public reproduction as #3517. Unless you'd like to keep this issue open for the heap or JDK-version detail, #3517 could track the remainder.

bsakaguchi referenced this issue

2026-10-17 21:09:49 +00:00

[PR #1268] [MERGED] fix(ghidra): preserve decoded return flow evidence #2750

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#1242

No description provided.

Rows
Columns

[GH-ISSUE #3374] [Feature] rea doctor readiness check for the JADX (Android) provider #1242