Malformed module DEX can crash release daemon during JNI DEX obfuscation

[starsalt0124]

Steps to reproduce/复现步骤

1. Use Vector/LSPosed source at commit cf1153e025318045d76ba64d0667e2a41c58ceaf.
2. Build a minimal native harness against the vendored external/lsplant/.../dex_builder/slicer sources with release-compatible flags, especially -DNDEBUG.
3. Feed the harness a malformed DEX-like input that contains the obfuscation target signature Lorg/matrix/vector/core/, sets class_defs_size = 1, and sets class_defs_off outside the file.
4. Run the same harness in debug, release-compatible, and ASAN release-compatible modes.

I attached vector_dex_obfuscation_verification.zip, which contains the local verification log, ASAN output, harness source, build script, PoC generator, and the minimal malformed DEX-like input. The input is only a malformed parser trigger and contains no executable payload.

Expected behaviour/预期行为

Malformed module DEX data should be rejected safely.

The daemon should skip the invalid module or report a recoverable module load/obfuscation error. Native DEX parser failures should not terminate the daemon process.

Actual behaviour/实际行为

In release-compatible mode, the native DEX parser dereferences an invalid class definition pointer and crashes.

Observed results from a local harness using the vendored slicer sources:

• Debug harness: aborts via SLICER_CHECK, return code 134.
• Release-compatible harness with -DNDEBUG: crashes with SIGSEGV, return code 139.
• Release-compatible ASAN harness: reports AddressSanitizer: SEGV.

ASAN stack:

dex::Reader::ParseClass(unsigned int)
dex::Reader::GetClass(unsigned int)
dex::Reader::CreateFullIr()
main

The root cause appears to be that SLICER_CHECK bounds checks are compiled out under NDEBUG, while ObfuscationManager.obfuscateDex passes module-controlled DEX bytes into dex::Reader::CreateFullIr() after only a signature memmem gate.

Xposed Module List/Xposed 模块列表

N/A for this report. This is a native parser robustness/security issue reproduced with a local harness. The attacker-controlled input would be a malformed enabled module APK.

Root implementation/Root 方案

N/A for local harness reproduction. The affected runtime scenario is the Vector/LSPosed daemon processing an enabled module APK in a rooted environment.

System Module List/系统模块列表

N/A for local harness reproduction.

LSPosed version/LSPosed 版本

3043

Android version/Android 版本

N/A

Version requirement/版本要求

• I am using the latest debug build from GitHub Actions./我正在使用 GitHub Actions 中最新的调试版本。

Logs/日志

This is not a usage/activation issue, but I also attached vector_dex_obfuscation_verification.zip, which contains the local verification log, ASAN output, harness source, build script, PoC generator, and the minimal malformed DEX-like input.

vector_dex_obfuscation_verification.zip

[JingMatrix]

Thanks for the harness and the ASAN output. The problem is the threat model: only modules with enabled = 1 reach this path — the daemon parses classes*.dex for modules the user has explicitly enabled. Enabling a module already grants it code execution in system_server and in every app process, so a hostile module has no reason to go through a malformed DEX. There's no boundary here for it to cross.

Unless I'm missing something, I intend to close this. Happy to wait for your reply first.