morluto/rea

Fork 0

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

[GH-ISSUE #2080] [Feature] Android APK unpacking support for Ijiami (爱加密) packer #690

New issue

Closed

opened 2026-10-15 18:27:24 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:24 +00:00

Owner

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

Originally assigned to: @N0zoM1z0 on GitHub.

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

REA has no workflow for Android APKs hardened with commercial packers. Apps packed with Ijiami (爱加密) encrypt/obfuscate the DEX and often add anti-debugging and anti-tampering checks, so standard static analysis tools (jadx, apktool) fail or return stub/placeholder code instead of real logic.

Today, an agent using REA has no path to go from a packed APK to analyzable DEX/smali — the investigation stalls at the very first step.

Use cases

Security research / authorized audit — analyzing a third-party Android app (own app, or one with explicit authorization) wrapped with Ijiami, to understand a specific feature's implementation before reimplementing it elsewhere.
Compatibility investigation — app behavior needs to be inspected because documentation is missing or outdated, but the packer blocks static inspection entirely.
Client app audit — a client's own app was packed by a vendor during the build pipeline, and the original source is no longer available internally.

Current tooling (manual Frida scripts, standalone unpackers) exists but lives outside REA's workflow, so there's no single agent-driven path from "packed APK" to "evidence-backed analysis."

Desired outcome and success criteria

REA detects that a given APK is packed with Ijiami (via manifest, .so signatures, or APK structure heuristics) and records this in its evidence trail.
REA drives an unpacking step (e.g. runtime DEX dump via hooks) and produces a recovered, loadable DEX/smali output.
The recovered DEX/smali is fed automatically into REA's existing decompilation/analysis tools — no manual handoff.
Evidence output clearly shows:
- which packer was detected
- which method was used to unpack
- confidence/limitations of the result (e.g. partial recovery, residual obfuscation)
Success = an agent can go from "here's a packed APK" to "here's the decompiled logic of feature X" in one REA-driven workflow.

Authority boundaries and non-goals

Must only operate on APKs the user has explicit authorization to analyze — same authority model as REA's existing process/target mutation work.
Out of scope: bypassing server-side license checks, DRM, or anything beyond local recovery of the app's own code for analysis purposes.
Out of scope (for now): other packers (Bangcle, Qihoo 360, Tencent Legu) — Ijiami is the primary ask, though a pluggable packer-detection design would ease future additions.
REA should not upload the target APK to any third-party service — consistent with REA's existing "no hosted analysis service" principle.

Alternatives considered

Running existing community unpackers or Frida-based DEX dump scripts manually, outside REA, then importing the resulting DEX separately for analysis. This works today but breaks REA's single-workflow, evidence-tracked experience — detection, method, and confidence aren't captured as part of REA's reasoning trail, and it requires the user (not the agent) to already know which approach to use.

Possible direction

Optional implementation idea — treat as a proposal, not a requirement.

Add an APK/packer fingerprinting step (manifest application class, embedded .so names, known Ijiami loader class names) as a new provider/capability-discovery check for Android targets.
Integrate a runtime-dump-based unpacking approach (hooking class-loading at the ART/Dalvik level) as an REA tool, gated behind the same authorization/mutation-boundary model REA uses elsewhere.
Normalize unpacked output into DEX/smali and route it into REA's existing native/decompilation pipeline — no separate tool-switching required.
Treat this as the first Android-packer integration, with an eye toward a pluggable interface for additional packers later.

References

AppSpear — universal, automated unpacking system for Dalvik and ART, covering most mainstream Android packers including Alibaba, Baidu, Bangcle, Ijiami, Qihoo360, Naga, and NetQin.
https://github.com/UchihaL/AppSpear
Checkpoint android_unpacker — generic unpacker for packed Android apps based on a patched AOSP build; runs the target in an emulator and dumps the unpacked DEX via runtime hooks. Presented at DEF CON 25 (2017).
https://github.com/checkpointsw/android_unpacker
MobSF (Mobile Security Framework) — all-in-one open-source mobile app pentesting framework (static + dynamic analysis), useful for the post-unpack analysis stage.
https://github.com/MobSF/Mobile-Security-Framework-MobSF
DexHunter — academic tool (ESORICS 2015, Zhang/Luo/Yin) for automatically extracting hidden DEX from packed Android apps; supports both Dalvik (DVM) and ART runtimes by patching the Android runtime source.
https://github.com/zyq8709/DexHunter (original) · published paper: DexHunter: Toward Extracting Hidden Code from Packed Android Applications, ESORICS 2015.
BlackDex — an Android unpacking (dexdump) tool that supports Android 5.0–12 without requiring any special environment, and can run on any phone or emulator, unpacking an APK in a few seconds. Distinguishes between "hook-based" dumps (unrepaired) and "cookie-based" dumps (repaired during deep unpacking). The project's own README states it's intended for security-analysis/study purposes only.
https://github.com/CodingGay/BlackDex
frida-dexdump (and Rust reimplementation Mufanc/DexHunter) — a lightweight, memory-probing DEX dump utility; the Rust version is non-invasive (doesn't attach/ptrace the target process directly), which helps avoid some anti-debug checks that detect parent/child ptrace relationships.
https://github.com/hluwa/FRIDA-DEXDump · Rust port: https://github.com/Mufanc/DexHunter
ZjDroid — older Xposed-module-based tool for dumping decrypted DEX from memory at runtime; frequently cited as prior art for memory-dump unpacking approaches predating Frida-based tooling.
FART (Frida-based ART Research Toolkit) — automated DEX-dump framework that hooks ART's class-loading internals across multiple Android/ART versions; commonly referenced alongside DexHunter/BlackDex as a generalized "dump-at-class-load-time" approach.

Note: the above are cited as prior art on the general unpacking approach (runtime DEX dump via hooks), not as drop-in dependencies. Both AppSpear and Checkpoint's unpacker target older AOSP/ART versions and are not actively maintained — compatibility with modern Android would need separate verification.

Originally created by @0xLLVEL on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2080 Originally assigned to: @N0zoM1z0 on GitHub. ### 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 REA has no workflow for Android APKs hardened with commercial packers. Apps packed with **Ijiami (爱加密)** encrypt/obfuscate the DEX and often add anti-debugging and anti-tampering checks, so standard static analysis tools (`jadx`, `apktool`) fail or return stub/placeholder code instead of real logic. Today, an agent using REA has no path to go from a packed APK to analyzable DEX/smali — the investigation stalls at the very first step. ### Use cases - **Security research / authorized audit** — analyzing a third-party Android app (own app, or one with explicit authorization) wrapped with Ijiami, to understand a specific feature's implementation before reimplementing it elsewhere. - **Compatibility investigation** — app behavior needs to be inspected because documentation is missing or outdated, but the packer blocks static inspection entirely. - **Client app audit** — a client's own app was packed by a vendor during the build pipeline, and the original source is no longer available internally. Current tooling (manual Frida scripts, standalone unpackers) exists but lives outside REA's workflow, so there's no single agent-driven path from *"packed APK"* to *"evidence-backed analysis."* ### Desired outcome and success criteria - REA **detects** that a given APK is packed with Ijiami (via manifest, `.so` signatures, or APK structure heuristics) and records this in its evidence trail. - REA **drives an unpacking step** (e.g. runtime DEX dump via hooks) and produces a recovered, loadable DEX/smali output. - The recovered DEX/smali is **fed automatically** into REA's existing decompilation/analysis tools — no manual handoff. - Evidence output clearly shows: - which packer was detected - which method was used to unpack - confidence/limitations of the result (e.g. partial recovery, residual obfuscation) - **Success** = an agent can go from *"here's a packed APK"* to *"here's the decompiled logic of feature X"* in one REA-driven workflow. ### Authority boundaries and non-goals - Must only operate on APKs the user has **explicit authorization** to analyze — same authority model as REA's existing process/target mutation work. - **Out of scope:** bypassing server-side license checks, DRM, or anything beyond local recovery of the app's own code for analysis purposes. - **Out of scope (for now):** other packers (Bangcle, Qihoo 360, Tencent Legu) — Ijiami is the primary ask, though a pluggable packer-detection design would ease future additions. - REA should **not** upload the target APK to any third-party service — consistent with REA's existing "no hosted analysis service" principle. ### Alternatives considered Running existing community unpackers or Frida-based DEX dump scripts manually, outside REA, then importing the resulting DEX separately for analysis. This works today but breaks REA's single-workflow, evidence-tracked experience — detection, method, and confidence aren't captured as part of REA's reasoning trail, and it requires the *user* (not the agent) to already know which approach to use. ### Possible direction > Optional implementation idea — treat as a proposal, not a requirement. - Add an APK/packer fingerprinting step (manifest application class, embedded `.so` names, known Ijiami loader class names) as a new provider/capability-discovery check for Android targets. - Integrate a runtime-dump-based unpacking approach (hooking class-loading at the ART/Dalvik level) as an REA tool, gated behind the same authorization/mutation-boundary model REA uses elsewhere. - Normalize unpacked output into DEX/smali and route it into REA's existing native/decompilation pipeline — no separate tool-switching required. - Treat this as the first Android-packer integration, with an eye toward a pluggable interface for additional packers later. ### References ### References - **AppSpear** — universal, automated unpacking system for Dalvik and ART, covering most mainstream Android packers including Alibaba, Baidu, Bangcle, Ijiami, Qihoo360, Naga, and NetQin. `https://github.com/UchihaL/AppSpear` - **Checkpoint `android_unpacker`** — generic unpacker for packed Android apps based on a patched AOSP build; runs the target in an emulator and dumps the unpacked DEX via runtime hooks. Presented at DEF CON 25 (2017). `https://github.com/checkpointsw/android_unpacker` - **MobSF (Mobile Security Framework)** — all-in-one open-source mobile app pentesting framework (static + dynamic analysis), useful for the post-unpack analysis stage. `https://github.com/MobSF/Mobile-Security-Framework-MobSF` - **DexHunter** — academic tool (ESORICS 2015, Zhang/Luo/Yin) for automatically extracting hidden DEX from packed Android apps; supports both Dalvik (DVM) and ART runtimes by patching the Android runtime source. `https://github.com/zyq8709/DexHunter` (original) · published paper: *DexHunter: Toward Extracting Hidden Code from Packed Android Applications*, ESORICS 2015. - **BlackDex** — an Android unpacking (dexdump) tool that supports Android 5.0–12 without requiring any special environment, and can run on any phone or emulator, unpacking an APK in a few seconds. Distinguishes between "hook-based" dumps (unrepaired) and "cookie-based" dumps (repaired during deep unpacking). The project's own README states it's intended for security-analysis/study purposes only. `https://github.com/CodingGay/BlackDex` - **frida-dexdump** (and Rust reimplementation `Mufanc/DexHunter`) — a lightweight, memory-probing DEX dump utility; the Rust version is non-invasive (doesn't attach/ptrace the target process directly), which helps avoid some anti-debug checks that detect parent/child ptrace relationships. `https://github.com/hluwa/FRIDA-DEXDump` · Rust port: `https://github.com/Mufanc/DexHunter` - **ZjDroid** — older Xposed-module-based tool for dumping decrypted DEX from memory at runtime; frequently cited as prior art for memory-dump unpacking approaches predating Frida-based tooling. - **FART (Frida-based ART Research Toolkit)** — automated DEX-dump framework that hooks ART's class-loading internals across multiple Android/ART versions; commonly referenced alongside DexHunter/BlackDex as a generalized "dump-at-class-load-time" approach. > Note: the above are cited as **prior art on the general unpacking approach** (runtime DEX dump via hooks), not as drop-in dependencies. Both AppSpear and Checkpoint's unpacker target older AOSP/ART versions and are not actively maintained — compatibility with modern Android would need separate verification.

bsakaguchi

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

closed this issue
added the
P3: low

enhancement
labels

bsakaguchi commented

2026-10-15 18:27:26 +00:00

Author

Owner

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

Policy & Scope Boundary Review

Unpacking commercial packers (such as Ijiami, Bangcle, SecNeo, etc.) involves protection defeat and dynamic unpacking techniques (dumping decrypted DEX from memory via Frida/Xposed hooks):

Fail-Closed Integration Policy: Per AGENTS.md and CONTRIBUTING.md#contribution-scope:

"For new providers or capabilities involving target execution, injection, mutation, or protection recovery, seek the required maintainer scope decision before substantial implementation for integration."
Current Recommendation: Automatic unpacking of proprietary protectors falls outside REA's core fail-closed boundaries. Analysts should unpack the DEX using external offline/memory-dump workflows and provide the unpacked classes/APK to REA as plain static inputs.

@matbrgz commented on GitHub (Oct 12, 2026): ### Policy & Scope Boundary Review Unpacking commercial packers (such as Ijiami, Bangcle, SecNeo, etc.) involves protection defeat and dynamic unpacking techniques (dumping decrypted DEX from memory via Frida/Xposed hooks): - **Fail-Closed Integration Policy:** Per `AGENTS.md` and `CONTRIBUTING.md#contribution-scope`: > *"For new providers or capabilities involving target execution, injection, mutation, or protection recovery, seek the required maintainer scope decision before substantial implementation for integration."* - **Current Recommendation:** Automatic unpacking of proprietary protectors falls outside REA's core fail-closed boundaries. Analysts should unpack the DEX using external offline/memory-dump workflows and provide the unpacked classes/APK to REA as plain static inputs.

bsakaguchi commented

2026-10-15 18:27:26 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 13, 2026):

Thanks for the detailed proposal and the examples. We understand why getting from a packed APK to usable analysis is a frustrating gap.

Our concern is with the capability REA would take on: automatically hooking a commercially protected app, recovering its hidden DEX, and feeding that into decompilation would make REA maintain and distribute a dedicated protection-recovery workflow. That falls outside the contribution scope we've adopted. This is a product and maintenance boundary, not a judgment about your intentions or the value of authorized research.

We're closing this request as not planned. Static packer identification, with clear evidence and limitations, remains a welcome separate proposal. Analysis of already available, ordinary DEX/APK artifacts also fits REA's scope. If you'd like to narrow the request to that detection-only part, we'd be happy to discuss it. Thanks again for bringing the use case to us.

@N0zoM1z0 commented on GitHub (Oct 13, 2026): Thanks for the detailed proposal and the examples. We understand why getting from a packed APK to usable analysis is a frustrating gap. Our concern is with the capability REA would take on: automatically hooking a commercially protected app, recovering its hidden DEX, and feeding that into decompilation would make REA maintain and distribute a dedicated protection-recovery workflow. That falls outside the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) we've adopted. This is a product and maintenance boundary, not a judgment about your intentions or the value of authorized research. We're closing this request as not planned. Static packer identification, with clear evidence and limitations, remains a welcome separate proposal. Analysis of already available, ordinary DEX/APK artifacts also fits REA's scope. If you'd like to narrow the request to that detection-only part, we'd be happy to discuss it. Thanks again for bringing the use case to us.

bsakaguchi referenced this issue

2026-10-15 18:28:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

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

[PR #690] [CLOSED] fix(native): preserve numeric-looking Mach-O identifiers #2171

bsakaguchi referenced this issue

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

[PR #705] [MERGED] fix: integrate 14 approved fix PRs (668,671,673,675,678-681,685-690) #2185

bsakaguchi added

enhancement

and removed