morluto/rea

Fork 0

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

[GH-ISSUE #717] [Feature] Integrate APK analysis tools into REA: research and roadmap #317

New issue

Open

opened 2026-10-15 18:23:49 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-15 18:23:49 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/717

Goal

Extend REA's positioning — One MCP for reverse engineering across binaries, applications, and runtime behavior — to Android applications by integrating established tools and returning evidence that agents can use directly.

This issue records the research and a staged roadmap. REA should own target identity, thin adapters, normalized results, and lifecycle management. Mature upstream tools should provide decompilation, resource decoding, signing, and instrumentation.

Related roadmap: #32.

Current baseline

Research snapshot: 2026-10-06, REA main af48fe879161.

APK already participates in package admission and the ZIP artifact inventory/extraction pipeline. Reuse that support.
The inspected catalog has no dedicated Android member/resource analysis contracts. ZIP support does not supply Android semantics.
DEX members need a distinct identity model; they are not native function addresses. Extracted .so files should reuse existing native analysis/Ghidra.

Relevant sources: target resolver, ZIP reader.

Recommended integrations

Tool	Useful capability	Integration decision
Android SDK apkanalyzer	Manifest, package/SDK metadata, DEX/resources	Initial Android inspection; normalize actual subcommand output
apksigner	Signature verification and certificate digests	Report the schemes and bytes actually verified
JADX	Java/smali, class/member search, references	First deep provider; on-demand headless queries
Apktool	Compiled resources/XML and smali, later rebuild	Complement JADX; provider-owned framework cache/workspace
bundletool	AAB/APKS and split relationships	Follow-up, with explicit module/device-spec selection
Androguard	Supplemental DEX/AXML/ARSC and bytecode analysis	Versioned spike only where it adds coverage
Google smali, APKiD	Bytecode fallback; compiler/packer signature evidence	Optional helpers

Research observed JADX v1.5.6, Apktool v3.0.3, and Androguard v4.1.4 as GitHub latest releases. Androguard's v5 default branch is a different architecture and must not be advertised as stable-package coverage. Bind adapters to actual installed versions and representative producer data. JADX JSON output is not automatically a complete inventory/xref protocol.

Existing MCP implementations worth studying

1013503897/jadx-headless-mcp: headless jadx-core, stdio, metadata indexing, lazy source lookup, method/xref queries, Java/smali result status. Source LICENSE is Apache-2.0. Its launcher defaults to MaxRAMPercentage=60; response truncation happens after class materialization. Verify actual cancellation before adopting its timeout behavior.
zinja-coder/jadx-ai-mcp + jadx-mcp-server: useful member/resource/annotation interfaces; GUI/HTTP state and paired versions require adaptation for headless REA.
zinja-coder/apktool-mcp-server: decode/build/sign workspace prior art.
mobilehackinglab/jadx-mcp-plugin: interface reference; root licensing remains unresolved in this research.

Choose between a reusable headless provider and a small jadx-core bridge through a focused experiment. Avoid rewriting the engine or copying an entire upstream MCP catalog into REA.

Staged work

First: package metadata, manifest/components/permissions, DEX/native ABI inventory, and signature evidence using SDK tools plus existing ZIP support.
First: on-demand class/member search, a selected method's Java/smali, and references through JADX.
First: resource ID/XML/locale inspection through Apktool.
Follow-up: AAB/APKS/base/split relationships through bundletool.
Follow-up: selected native-library handoff and JNI relationship evidence; distinguish observed bindings from naming-based inference.
Follow-up: evaluate versioned Androguard coverage for remaining DEX questions.
Follow-up: explicit resource/smali edits and rebuild into a new artifact, with signature changes and source immutability recorded.
Later: caller-selected device/process observation through ADB and Frida; optional local MobSF report/service integration.

Result and operational requirements

Shared CLI/MCP application workflows, named contracts, and generated catalog updates; inspect existing alternatives before introducing tools.
Member identity includes APK digest, DEX entry, class descriptor, name, and full parameter/return prototype. Preserve raw names and aliases.
Return useful results inline with Evidence, provider/version/options, source locations, failures, and explicit unknowns. Decompiled Java is derived analysis; failed/incomplete methods need a bytecode/smali fallback or a precise limitation.
Static xrefs do not establish complete reflection/dynamic-loading/JNI behavior. Certificate subjects do not establish trusted developer identity.
Bring-your-own tools; no automatic SDK/Java/Python installation or host-default changes. Keep provider caches/workspaces isolated.
Start with one worker and an explicit child JVM budget. Output caps do not bound computation; report resource-limited results and clean up owned descendants on cancellation. Preserve unrelated ADB sessions.
Check exact component licenses before copying/redistributing. APKiD has GPL/commercial dual licensing; GitHub NOASSERTION is not an absence of licensing.

Acceptance for the initial milestones

Source-built fixtures cover manifest/resources/locales, multidex, overloads/inner classes, cross-DEX references, native ABI inventory, and valid/modified signatures.
Assert exact member identity and evidence; cover decompiler failure, missing framework/tool, malformed inputs, replaced source/cache identity, and cancellation.
Exercise real SDK/JADX/Apktool through CLI and MCP with bounded resources. Focused tests validate adapters/contracts; mocks do not establish provider support.
Track fixture source/generators, not private APKs, credentials, or generated binaries. Report unverified platform/runtime coverage explicitly.

Research status: official documentation, selected upstream source, version/license metadata reviewed; tools and APK workflows have not yet been executed. Implement in small independently useful PRs.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/717 ## Goal Extend REA's positioning — **One MCP for reverse engineering across binaries, applications, and runtime behavior** — to Android applications by integrating established tools and returning evidence that agents can use directly. This issue records the research and a staged roadmap. REA should own target identity, thin adapters, normalized results, and lifecycle management. Mature upstream tools should provide decompilation, resource decoding, signing, and instrumentation. Related roadmap: #32. ## Current baseline Research snapshot: 2026-10-06, REA main `af48fe879161`. - APK already participates in package admission and the ZIP artifact inventory/extraction pipeline. Reuse that support. - The inspected catalog has no dedicated Android member/resource analysis contracts. ZIP support does not supply Android semantics. - DEX members need a distinct identity model; they are not native function addresses. Extracted `.so` files should reuse existing native analysis/Ghidra. Relevant sources: [target resolver](https://github.com/morluto/rea/blob/af48fe879161/src/application/BinaryTargetResolver.ts), [ZIP reader](https://github.com/morluto/rea/blob/af48fe879161/src/artifacts/ZipArtifactReader.ts). ## Recommended integrations | Tool | Useful capability | Integration decision | | --- | --- | --- | | [Android SDK apkanalyzer](https://developer.android.com/tools/apkanalyzer) | Manifest, package/SDK metadata, DEX/resources | Initial Android inspection; normalize actual subcommand output | | [apksigner](https://developer.android.com/tools/apksigner) | Signature verification and certificate digests | Report the schemes and bytes actually verified | | [JADX](https://github.com/skylot/jadx) | Java/smali, class/member search, references | First deep provider; on-demand headless queries | | [Apktool](https://github.com/iBotPeaches/Apktool) | Compiled resources/XML and smali, later rebuild | Complement JADX; provider-owned framework cache/workspace | | [bundletool](https://developer.android.com/tools/bundletool) | AAB/APKS and split relationships | Follow-up, with explicit module/device-spec selection | | [Androguard](https://github.com/androguard/androguard) | Supplemental DEX/AXML/ARSC and bytecode analysis | Versioned spike only where it adds coverage | | [Google smali](https://github.com/google/smali), [APKiD](https://github.com/rednaga/APKiD) | Bytecode fallback; compiler/packer signature evidence | Optional helpers | Research observed JADX `v1.5.6`, Apktool `v3.0.3`, and Androguard `v4.1.4` as GitHub latest releases. Androguard's v5 default branch is a different architecture and must not be advertised as stable-package coverage. Bind adapters to actual installed versions and representative producer data. JADX JSON output is not automatically a complete inventory/xref protocol. ### Existing MCP implementations worth studying - [1013503897/jadx-headless-mcp](https://github.com/1013503897/jadx-headless-mcp): headless jadx-core, stdio, metadata indexing, lazy source lookup, method/xref queries, Java/smali result status. Source LICENSE is Apache-2.0. Its launcher defaults to `MaxRAMPercentage=60`; response truncation happens after class materialization. Verify actual cancellation before adopting its timeout behavior. - [zinja-coder/jadx-ai-mcp](https://github.com/zinja-coder/jadx-ai-mcp) + [jadx-mcp-server](https://github.com/zinja-coder/jadx-mcp-server): useful member/resource/annotation interfaces; GUI/HTTP state and paired versions require adaptation for headless REA. - [zinja-coder/apktool-mcp-server](https://github.com/zinja-coder/apktool-mcp-server): decode/build/sign workspace prior art. - [mobilehackinglab/jadx-mcp-plugin](https://github.com/mobilehackinglab/jadx-mcp-plugin): interface reference; root licensing remains unresolved in this research. Choose between a reusable headless provider and a small jadx-core bridge through a focused experiment. Avoid rewriting the engine or copying an entire upstream MCP catalog into REA. ## Staged work - [ ] **First:** package metadata, manifest/components/permissions, DEX/native ABI inventory, and signature evidence using SDK tools plus existing ZIP support. - [ ] **First:** on-demand class/member search, a selected method's Java/smali, and references through JADX. - [ ] **First:** resource ID/XML/locale inspection through Apktool. - [ ] **Follow-up:** AAB/APKS/base/split relationships through bundletool. - [ ] **Follow-up:** selected native-library handoff and JNI relationship evidence; distinguish observed bindings from naming-based inference. - [ ] **Follow-up:** evaluate versioned Androguard coverage for remaining DEX questions. - [ ] **Follow-up:** explicit resource/smali edits and rebuild into a new artifact, with signature changes and source immutability recorded. - [ ] **Later:** caller-selected device/process observation through [ADB](https://developer.android.com/tools/adb) and [Frida](https://frida.re/docs/android/); optional local [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF) report/service integration. ## Result and operational requirements - Shared CLI/MCP application workflows, named contracts, and generated catalog updates; inspect existing alternatives before introducing tools. - Member identity includes APK digest, DEX entry, class descriptor, name, and full parameter/return prototype. Preserve raw names and aliases. - Return useful results inline with Evidence, provider/version/options, source locations, failures, and explicit unknowns. Decompiled Java is derived analysis; failed/incomplete methods need a bytecode/smali fallback or a precise limitation. - Static xrefs do not establish complete reflection/dynamic-loading/JNI behavior. Certificate subjects do not establish trusted developer identity. - Bring-your-own tools; no automatic SDK/Java/Python installation or host-default changes. Keep provider caches/workspaces isolated. - Start with one worker and an explicit child JVM budget. Output caps do not bound computation; report resource-limited results and clean up owned descendants on cancellation. Preserve unrelated ADB sessions. - Check exact component licenses before copying/redistributing. APKiD has GPL/commercial dual licensing; GitHub `NOASSERTION` is not an absence of licensing. ## Acceptance for the initial milestones - Source-built fixtures cover manifest/resources/locales, multidex, overloads/inner classes, cross-DEX references, native ABI inventory, and valid/modified signatures. - Assert exact member identity and evidence; cover decompiler failure, missing framework/tool, malformed inputs, replaced source/cache identity, and cancellation. - Exercise real SDK/JADX/Apktool through CLI and MCP with bounded resources. Focused tests validate adapters/contracts; mocks do not establish provider support. - Track fixture source/generators, not private APKs, credentials, or generated binaries. Report unverified platform/runtime coverage explicitly. **Research status:** official documentation, selected upstream source, version/license metadata reviewed; tools and APK workflows have not yet been executed. Implement in small independently useful PRs.

bsakaguchi added the

labels

2026-10-15 18:23:49 +00:00

bsakaguchi commented

2026-10-15 18:23:50 +00:00

Author

Owner

@JackLee992 commented on GitHub (Oct 9, 2026):

I'd like to pick up the two parts of the First milestone that need no SDK installation and can be verified deterministically on the host, since they give the later JADX/apksigner lanes their Android semantics: native ABI inventory and APK signature-scheme evidence. Both stay execution-free and reuse the existing ZIP/inventory pipeline, as the issue asks.

Slice 1 — native ABI inventory (pure projection; no new IO or interface change). Today projectAndroidApplication (src/domain/android/androidApplication.ts) classifies lib/<abi>/<name>.so into a flat components.native_libraries list, but the <abi> path segment is never captured, so there is no per-ABI inventory. I'd add a structured native_abi_inventory: the set of ABIs present (normalized to armeabi-v7a, arm64-v8a, x86, x86_64, riscv64; unrecognized lib/<dir> entries reported explicitly rather than guessed), the libraries under each ABI with their digests, and path-level cross-ABI presence differences, plus a limitation that ABI is read from the ZIP path and is not yet confirmed from ELF machine/flags (that confirmation belongs to the native provider). Deterministic projection tests via source-built inventory fixtures only — no private APKs.

Slice 2 — APK Signing Block v2/v3 evidence (needs a small reader capability). The current signing components only cover v1 JAR files under META-INF/. The v2/v3 APK Signing Block sits just before the central directory and is not a ZIP entry, so it is currently invisible. ZipArtifactReader already has a bounded random byte read internally (NodeFileReader.readUint8Array(index, length)), but the ArtifactReader interface exposes only entries/open. I'd parse EOCD → central-directory offset → signing block (magic, size, pair IDs 0x7109871a v2 / 0xf05368c0 v3 / 0x1b93ad61 v3.1) and report which schemes are present, their byte ranges, and truncated/modified structure, covered by source-built fixtures. This layer reports structural evidence only — no cryptographic verification, certificate chain, or trust decision; actual verification stays with a bring-your-own apksigner lane ("report the schemes and bytes actually verified"; certificate subjects do not establish trusted developer identity).

Questions before I start:

Is Slice 1 a good first PR, and should native_abi_inventory live under components or as a top-level projection field?
For Slice 2, would you prefer a generic bounded/cancellable read-only readRange(offset, length) on ArtifactReader, or a narrow ZIP/APK-specific tail (signing-block) reader? Any hard length cap you'd mandate?
Is the evidence-vs-verification boundary above correct (structural presence here; apksigner cryptographic verification in a later SDK lane)?
Should the normalized ABI set include riscv64 now, and how should non-standard lib/<dir> directories be surfaced?

I'll keep both as small independently useful PRs with source-built fixtures, explicit unknowns/limitations, no auto-installed SDK/JDK, and no private binaries. Happy to open focused implementation issues for the two slices if you'd rather track them that way.

@JackLee992 commented on GitHub (Oct 9, 2026): I'd like to pick up the two parts of the **First** milestone that need no SDK installation and can be verified deterministically on the host, since they give the later JADX/apksigner lanes their Android semantics: **native ABI inventory** and **APK signature-scheme evidence**. Both stay execution-free and reuse the existing ZIP/inventory pipeline, as the issue asks. **Slice 1 — native ABI inventory (pure projection; no new IO or interface change).** Today `projectAndroidApplication` (`src/domain/android/androidApplication.ts`) classifies `lib/<abi>/<name>.so` into a flat `components.native_libraries` list, but the `<abi>` path segment is never captured, so there is no per-ABI inventory. I'd add a structured `native_abi_inventory`: the set of ABIs present (normalized to `armeabi-v7a`, `arm64-v8a`, `x86`, `x86_64`, `riscv64`; unrecognized `lib/<dir>` entries reported explicitly rather than guessed), the libraries under each ABI with their digests, and path-level cross-ABI presence differences, plus a limitation that ABI is read from the ZIP path and is not yet confirmed from ELF machine/flags (that confirmation belongs to the native provider). Deterministic projection tests via source-built inventory fixtures only — no private APKs. **Slice 2 — APK Signing Block v2/v3 evidence (needs a small reader capability).** The current `signing` components only cover v1 JAR files under `META-INF/`. The v2/v3 APK Signing Block sits just before the central directory and is not a ZIP entry, so it is currently invisible. `ZipArtifactReader` already has a bounded random byte read internally (`NodeFileReader.readUint8Array(index, length)`), but the `ArtifactReader` interface exposes only `entries`/`open`. I'd parse EOCD → central-directory offset → signing block (magic, size, pair IDs `0x7109871a` v2 / `0xf05368c0` v3 / `0x1b93ad61` v3.1) and report which schemes are present, their byte ranges, and truncated/modified structure, covered by source-built fixtures. This layer reports **structural evidence only — no cryptographic verification, certificate chain, or trust decision**; actual verification stays with a bring-your-own apksigner lane ("report the schemes and bytes actually verified"; certificate subjects do not establish trusted developer identity). Questions before I start: 1. Is Slice 1 a good first PR, and should `native_abi_inventory` live under `components` or as a top-level projection field? 2. For Slice 2, would you prefer a generic bounded/cancellable read-only `readRange(offset, length)` on `ArtifactReader`, or a narrow ZIP/APK-specific tail (signing-block) reader? Any hard length cap you'd mandate? 3. Is the evidence-vs-verification boundary above correct (structural presence here; apksigner cryptographic verification in a later SDK lane)? 4. Should the normalized ABI set include `riscv64` now, and how should non-standard `lib/<dir>` directories be surfaced? I'll keep both as small independently useful PRs with source-built fixtures, explicit unknowns/limitations, no auto-installed SDK/JDK, and no private binaries. Happy to open focused implementation issues for the two slices if you'd rather track them that way.

bsakaguchi commented

2026-10-15 18:23:50 +00:00

Author

Owner

@Han-Shen-math commented on GitHub (Oct 13, 2026):

I'd like to contribute a focused first slice of the resource/smali edits and rebuild follow-up in this roadmap: resource and manifest edits for a single APK, producing a new artifact while preserving the source. Smali/code editing would remain a separate follow-up.

The current Apktool operation is intentionally inspection-only (d --no-src) and removes its decoded workspace. I propose keeping that contract unchanged and adding a separate, explicitly mutating edit/rebuild workflow after scope agreement. Inputs would include the selected APK and explicit edits with expected previous values; output evidence would identify the source/result digests, exact edits, provider/version/options, validation results, and remaining unknowns.

I have prepared a small local, unregistered fixture-only prototype, without changing production src, CLI/MCP registration, or the package allowlist. On macOS arm64 with Apktool 3.0.3 it passed baseline build → decode → string/manifest-metadata edits → rebuild. AAPT2 read back both changes, original APK and fixture hashes stayed unchanged, the preserved asset digest matched, and workspace cleanup completed. Three boundary tests cover refusing arbitrary APK/raw-flag inputs, preserving existing output, and cancelling a simulated builder.

These results are deliberately limited: the fixture has no executable code; AAPT2 comes from the same toolchain; no APK was signed, installed, or run; no cryptographic signature verification or real companion-app compatibility was established. The prototype is not a general APK editor or production lifecycle implementation.

For the first integration I propose caller-supplied tools, owned workspaces/framework caches, new-output-only publication, and reuse of REA's existing process, immutable-input and safe-output primitives. It would execute local build tools and write copied/new files, with no signing, device operations, raw-command passthrough, or protection/integrity bypass. Splits/AABs and code editing are out of this initial scope. Code-bearing inputs would require additional fixtures proving preservation of unedited DEX, native libraries and assets.

Before substantial implementation intended for integration, could a maintainer confirm whether this scope fits #717, whether edits/build should be one bounded operation or an explicitly owned persistent workspace, and what minimum signature-state and real-provider checks the first PR should require? I can share the small experiment as a draft PR to support that decision.

@Han-Shen-math commented on GitHub (Oct 13, 2026): I'd like to contribute a focused first slice of the **resource/smali edits and rebuild** follow-up in this roadmap: **resource and manifest edits for a single APK, producing a new artifact while preserving the source**. Smali/code editing would remain a separate follow-up. The current Apktool operation is intentionally inspection-only (`d --no-src`) and removes its decoded workspace. I propose keeping that contract unchanged and adding a separate, explicitly mutating edit/rebuild workflow after scope agreement. Inputs would include the selected APK and explicit edits with expected previous values; output evidence would identify the source/result digests, exact edits, provider/version/options, validation results, and remaining unknowns. I have prepared a small **local, unregistered fixture-only prototype**, without changing production `src`, CLI/MCP registration, or the package allowlist. On macOS arm64 with Apktool 3.0.3 it passed baseline build → decode → string/manifest-metadata edits → rebuild. AAPT2 read back both changes, original APK and fixture hashes stayed unchanged, the preserved asset digest matched, and workspace cleanup completed. Three boundary tests cover refusing arbitrary APK/raw-flag inputs, preserving existing output, and cancelling a simulated builder. These results are deliberately limited: the fixture has no executable code; AAPT2 comes from the same toolchain; no APK was signed, installed, or run; no cryptographic signature verification or real companion-app compatibility was established. The prototype is not a general APK editor or production lifecycle implementation. For the first integration I propose caller-supplied tools, owned workspaces/framework caches, new-output-only publication, and reuse of REA's existing process, immutable-input and safe-output primitives. It would execute local build tools and write copied/new files, with no signing, device operations, raw-command passthrough, or protection/integrity bypass. Splits/AABs and code editing are out of this initial scope. Code-bearing inputs would require additional fixtures proving preservation of unedited DEX, native libraries and assets. Before substantial implementation intended for integration, could a maintainer confirm whether this scope fits #717, whether edits/build should be one bounded operation or an explicitly owned persistent workspace, and what minimum signature-state and real-provider checks the first PR should require? I can share the small experiment as a draft PR to support that decision.

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:28:59 +00:00

bsakaguchi commented

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

Author

Owner

@arielfikru commented on GitHub (Oct 21, 2026):

Real-lane data point for the Android/JADX lane: a ProGuard-obfuscated, pure-Java game APK on macOS.

Setup: macOS (Darwin 25.6.0), Node 24.18.0, OpenJDK 21.0.12.1, REA from upstream main, jadx-headless-mcp 0.7.1 JAR (pinned SHA-256 verified). APK: a small commercial Java game (v1.0.9, ProGuard names, single dex).

Problem it solved: the JADX text of class b.a.f has two overloads, a(int, int) (integer power) and a(long, long) (percent). JADX prints call sites as b.a.f.a(x, y) with int arguments and hides the int-to-long widening. Reading the Java alone, the call looks like the power overload. We had this marked as unresolved for days while porting the game logic.

What I ran: inspect-android-class b.a.f, trace-android-references b.a.f a with overload_index 1 and 6, and inspect-android-method on the two disputed callers. Every call exited 0 and took about 4-5 s.

Result: inspect-android-class lists dex_descriptor per overload ((II)I = overload 1, (JJ)I = overload 6). The reference trace per overload shows both disputed callers under (JJ)I, so they call the percent overload. Across the dex, (JJ)I has 52 invoke sites in 42 methods and (II)I has 2 sites in 1 class. An independent DEX scan (a small stdlib parser over classes.dex) matched REA exactly. It showed int-to-long on both arguments right before each invoke-static.

So dex_descriptor + overload_index resolved an ambiguity that the plain JADX text hides. That is a good argument for keeping descriptors first-class in the lane.

Gaps hit:

inspect-android-method returns smali only as a fallback when there is no Java body. With a Java body, the widening (the actual evidence) is not visible through REA. An opt-in include_smali (or a bytecode view of a call site) would close that.
The reference trace gives the callee descriptor and the caller, not the argument conversions at the call site.
total in the trace counts calling methods (42), not invoke records (52). It is documented in docs/android-analysis.md, but easy to misread when counting call sites.

@arielfikru commented on GitHub (Oct 21, 2026): Real-lane data point for the Android/JADX lane: a ProGuard-obfuscated, pure-Java game APK on macOS. **Setup:** macOS (Darwin 25.6.0), Node 24.18.0, OpenJDK 21.0.12.1, REA from upstream main, jadx-headless-mcp 0.7.1 JAR (pinned SHA-256 verified). APK: a small commercial Java game (v1.0.9, ProGuard names, single dex). **Problem it solved:** the JADX text of class `b.a.f` has two overloads, `a(int, int)` (integer power) and `a(long, long)` (percent). JADX prints call sites as `b.a.f.a(x, y)` with int arguments and hides the `int-to-long` widening. Reading the Java alone, the call looks like the power overload. We had this marked as unresolved for days while porting the game logic. **What I ran:** `inspect-android-class b.a.f`, `trace-android-references b.a.f a` with `overload_index` 1 and 6, and `inspect-android-method` on the two disputed callers. Every call exited 0 and took about 4-5 s. **Result:** `inspect-android-class` lists `dex_descriptor` per overload (`(II)I` = overload 1, `(JJ)I` = overload 6). The reference trace per overload shows both disputed callers under `(JJ)I`, so they call the percent overload. Across the dex, `(JJ)I` has 52 invoke sites in 42 methods and `(II)I` has 2 sites in 1 class. An independent DEX scan (a small stdlib parser over `classes.dex`) matched REA exactly. It showed `int-to-long` on both arguments right before each `invoke-static`. So `dex_descriptor` + `overload_index` resolved an ambiguity that the plain JADX text hides. That is a good argument for keeping descriptors first-class in the lane. **Gaps hit:** 1. `inspect-android-method` returns smali only as a fallback when there is no Java body. With a Java body, the widening (the actual evidence) is not visible through REA. An opt-in `include_smali` (or a bytecode view of a call site) would close that. 2. The reference trace gives the callee descriptor and the caller, not the argument conversions at the call site. 3. `total` in the trace counts calling methods (42), not invoke records (52). It is documented in docs/android-analysis.md, but easy to misread when counting call sites.

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

No description provided.

Rows
Columns