What changes in a DexGuard build
DexGuard is a compiler-based Android protection product. Guardsquare lists name obfuscation, control-flow obfuscation, data encryption, code virtualization, native hardening and runtime application self-protection. Its checks can cover root access, emulators, debuggers, hooks, tampering and signing certificates. The exact mix depends on the build configuration.
That mix changes the shape of the work. Renamed classes remove labels. Optimization and control-flow changes break the structure a decompiler expects. Encrypted or virtualized code may appear only when the app reaches it. Runtime checks can stop the process before the target screen sends a request.
How we identify the active layers
We inspect the manifest, DEX layout, resources and native libraries, then compare those findings with runtime behavior. A small readable shell around missing business classes points toward class encryption or runtime loading. Dense synthetic branches point toward control-flow work. Repeated environment checks around sensitive methods point toward injected RASP.
- Trace the application flow from the UI into its network client.
- Record code and libraries loaded before that action.
- Map the checks that can alter or stop the request path.
- Capture the final URL, headers, body and session state.
What the finished work contains
The output covers the full application flow in Python, JavaScript/TypeScript, Postman and documented HTTP calls. It includes token handling, request signing, serialization and the order of calls. It does not depend on retaining DexGuard’s protected runtime unless a device-backed value makes that dependency real.
Reviewed 30 August 2026 · SReverse research desk