[GH-ISSUE #5072] Support read-only inventory of APKM and split-APK bundles #3111

New issue

Closed

opened 2026-10-31 00:36:45 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:36:45 +00:00

Owner

Originally created by @aszoubir on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5072

Problem

REA's Android analysis workflow accepts an individual APK, while real-world Android distribution downloads can be ZIP-based APKM bundles containing base.apk and multiple split_config.*.apk members. Manually unpacking them makes it easy to omit a split or accidentally present base-only findings as full-package coverage.

Proposed outcome

Add a read-only inventory workflow for APKM-style bundles (a ZIP containing exactly one root-level base.apk and optional root-level split APKs).

The inventory should return machine-readable evidence for the container and each member, including member name, size, SHA-256, ZIP-integrity result, DEX count, native-library inventory, and whether an Android manifest is present. A follow-on option could run existing Android inspections against selected individual APK members while retaining separate artifact identity and provenance.

Boundaries

Do not treat Android App Bundles (.aab) as interchangeable with APKM; scope them separately.
Do not merge manifests, DEX, or resources by assumption. Report exactly which split(s) each result covers.
Do not install or execute target code, patch/sign packages, bypass integrity or licensing controls, or alter the input archive.
Apply explicit limits to archive entry count, decompressed size, nesting, duplicate paths, and compression expansion; reject path traversal and ambiguous duplicate base.apk entries.
Keep partial provider output and unsupported split semantics explicit instead of claiming complete bundle coverage.

Acceptance criteria

Valid base-plus-splits fixture yields stable JSON and per-member hashes/counts.
Missing or duplicate base.apk, duplicate member paths, nested/path-traversal entries, oversized members, malformed ZIPs, and invalid embedded APKs fail closed.
Base-only Android analysis is labelled as base-only; split members retain independent artifact hashes.
CLI and MCP, if both added, share the same application workflow and schemas.
Tests use synthetic or appropriately licensed fixtures; no private APKs or credentials are needed.

Would maintainers consider this within the existing static archive/Android-analysis scope, and what evidence/provenance contract should a bundle workflow use before implementation?

Originally created by @aszoubir on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5072 ## Problem REA's Android analysis workflow accepts an individual APK, while real-world Android distribution downloads can be ZIP-based APKM bundles containing `base.apk` and multiple `split_config.*.apk` members. Manually unpacking them makes it easy to omit a split or accidentally present base-only findings as full-package coverage. ## Proposed outcome Add a read-only inventory workflow for APKM-style bundles (a ZIP containing exactly one root-level `base.apk` and optional root-level split APKs). The inventory should return machine-readable evidence for the container and each member, including member name, size, SHA-256, ZIP-integrity result, DEX count, native-library inventory, and whether an Android manifest is present. A follow-on option could run existing Android inspections against selected individual APK members while retaining separate artifact identity and provenance. ## Boundaries - Do not treat Android App Bundles (`.aab`) as interchangeable with APKM; scope them separately. - Do not merge manifests, DEX, or resources by assumption. Report exactly which split(s) each result covers. - Do not install or execute target code, patch/sign packages, bypass integrity or licensing controls, or alter the input archive. - Apply explicit limits to archive entry count, decompressed size, nesting, duplicate paths, and compression expansion; reject path traversal and ambiguous duplicate `base.apk` entries. - Keep partial provider output and unsupported split semantics explicit instead of claiming complete bundle coverage. ## Acceptance criteria 1. Valid base-plus-splits fixture yields stable JSON and per-member hashes/counts. 2. Missing or duplicate `base.apk`, duplicate member paths, nested/path-traversal entries, oversized members, malformed ZIPs, and invalid embedded APKs fail closed. 3. Base-only Android analysis is labelled as base-only; split members retain independent artifact hashes. 4. CLI and MCP, if both added, share the same application workflow and schemas. 5. Tests use synthetic or appropriately licensed fixtures; no private APKs or credentials are needed. Would maintainers consider this within the existing static archive/Android-analysis scope, and what evidence/provenance contract should a bundle workflow use before implementation?

bsakaguchi closed this issue

2026-10-31 00:36:45 +00:00

bsakaguchi commented

2026-10-31 00:36:46 +00:00

Author

Owner

@aszoubir commented on GitHub (Oct 18, 2026):

Closing this as a duplicate of the existing design discussion, #1813 — Android split APK sets: set identity and relationship evidence before a bundletool lane. That issue is broader and already covers the key evidence/provenance and scope questions. The local static-inventory prototype and report from my current task remain separate handoff artifacts; no APK was uploaded here.

@aszoubir commented on GitHub (Oct 18, 2026): Closing this as a duplicate of the existing design discussion, [#1813 — Android split APK sets: set identity and relationship evidence before a bundletool lane](https://github.com/morluto/rea/issues/1813). That issue is broader and already covers the key evidence/provenance and scope questions. The local static-inventory prototype and report from my current task remain separate handoff artifacts; no APK was uploaded here.

bsakaguchi referenced this issue

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

[GH-ISSUE #5237] [Windows native] Private DACL contains unexpected trustees (Win32 5) blocks Android inspection before JADX #3202

bsakaguchi referenced this issue

2026-10-31 01:08:08 +00:00

[PR #3129] feat(ghidra): admit ELF and thin Mach-O targets on Windows #5634

bsakaguchi referenced this issue

2026-11-01 21:12:46 +00:00

[GH-ISSUE #8499] Windows x64: JADX bridge JVM stalls opening engine.jar, MCP connect times out (6.8.0) #6625