360 加固 APK 的识别、运行时 DEX 恢复与常见坑
一个 APK 的 Manifest 把 Application 指向 com.stub.StubApp,JADX 只反编译出 6 个 Java 文件,包内还出现一组 libjiagu。静态分析到这里,基本可以判断业务 DEX 被壳接管了。下一步的难点有三个,先确认壳的家族特征,再触发业务代码加载,最后从一堆内存候选中找出能用的 DEX。
本文用一个 Android 14 样本走完这条路线。静态反编译只剩壳,直接从 VDEX 抽出的 15 MB DEX 仍然只有 4 个类。切换到 x86_64 userdebug 环境并读取运行进程后,共找到 11 份 DEX 候选。去掉重复壳和极小文件,再按包名识别业务与依赖,JADX 最终生成约 18,027 个 Java 文件,目标应用目录下有 613 个。
这套方法适用于业务代码会以标准 DEX 形态进入 ART 的样本。方法级解密、DEX 虚拟化和大规模 native 化可能不会留下可直接切出的完整文件,文末会单独说明边界。