Obfuscapk Deep Dive: Control-Flow Obfuscation

BlackObfuscator is the control-flow obfuscator in VALLUM's stack, in the spirit of Obfuscapk. Where name obfuscation only renames symbols, control-flow obfuscation rewrites the shape of the code so that a human reader cannot follow the branches even with symbols intact.

The core technique is control-flow flattening. The original sequence of if/else and loop blocks is replaced by a single dispatcher switch driven by a state variable, so linear execution becomes a loop that jumps between opaque blocks. Combined with string encryption, reflective call replacement, and resource-name obfuscation, static reading of the DEX becomes a slow, painful puzzle.

String encryption matters because hard-coded tokens - API keys, URLs, class names - survive name obfuscation untouched. By encrypting string constants and decrypting them lazily, BlackObfuscator removes the low-hanging fruit that attackers grep for first.

The blocker is the clash with R8. VALLUM's APKs are already minified by R8 at build time, and running BlackObfuscator afterward triggers a runtime NullPointerException. Internally its dex2jar-to-jar2dex round trip emits invalid bytecode that dx tolerates but the ART runtime rejects, inflating the string pool roughly sevenfold before the NPE fires.

Until that pipeline is fixed we keep BlackObfuscator disabled across the Standard, Enhanced, and Maximum profiles. The static layers that remain - AndResGuard resource obfuscation and dpt-shell function extraction - already raise the bar substantially, and RASP covers the runtime side.

If you need control-flow obfuscation today, do it inside your own R8 or ProGuard config, or a dedicated build-time tool, before handing the APK to VALLUM - not as a post-step. We track the BlackObfuscator fix as a follow-up and will re-enable it once the NPE is resolved.