5 层加固管线

VALLUM 的加固管线由一个 PowerShell 脚本编排，依次运行各个引擎。Step 0 检查环境，Step 1 确认 APK 已在构建期经过 R8 混淆，Step 2 到 Step 6 驱动五个加固引擎。每一步都通过 Server-Sent Events 上报进度，界面因此能显示 AndResGuard 25%、控制流 45%、dpt-shell 70%、RASP 90%、签名 95%。

第一层是资源层的 AndResGuard。它在 JDK 8 下运行，把 res/ 的路径和条目重命名为无意义短名，并用 7za 重新深度压缩，同时用白名单保留 ic_launcher 等启动图标以避免安装异常。这一层防的是资源窃取和按资源名的逆向定位，代价极小、往往还能缩小体积，兼容性也是所有层里最好的。

第二层是控制流层的 BlackObfuscator。它在设计上对 DEX 做控制流平坦化，把线性逻辑打散成分发式状态机来阻碍人工阅读。但实际上，对经过 R8 混淆的 APK，它的 dex2jar→jar2dex 往返会产出无效字节码；dx 虽然容忍，却让 DEX 字符串池膨胀约 7 倍并触发运行时 NPE 崩溃。因此它在 Standard、Enhanced、Maximum 三档中被暂时禁用。

第三层是函数抽取层的 dpt-shell，用内置的 JDK 11 运行 dpt.jar。它把方法体从 DEX 中抽空，运行时再由壳 ClassLoader 加 JNI 还原，jadx 只能看到 nop 空方法。安全模式会带上 --disable-anti-debug 与 --disable-frida-detect，并刻意不加 -vs 和 -S。代价是包体增大、首次加载有还原开销，并且对 native ABI 很敏感。

第四层是 RASP 阶段的 Abdal-DroidGuard，以 --all --verbose 注入。它在运行时检测调试器、Frida、模拟器和 root，一旦发现篡改就中止。由于它依赖 dpt-shell 产生的壳结构，脚本强制约束：跳过 dpt 就必须跳过 Abdal，二者绑定。这一层的代价是偶发误报和轻微的运行时开销。

第五层是签名。因为 dpt-shell 和 Abdal 各自用调试证书重签过，最终阶段先用 zip_clean.py 清除旧签名，再 zipalign 对齐，然后用 apksigner 做 V1+V2+V3 重签并校验。支持三档：platform（仅测试）、user（用户自己的 keystore）、none（产出未签名包）。签名一旦出错，APK 就无法安装或上架。