DexGuard: wat is het, obfuscatie en beveiliging van Android-applicaties

Wat is DexGuard?

DexGuard is een commercieel hulpmiddel voor obfuscatie en bescherming van Android-applicaties, ontwikkeld door hetzelfde team dat ProGuard heeft gemaakt (Eric Lafortune). Het product verscheen in 2012 als uitbreiding voor projecten waar standaard ProGuard-obfuscatie ontoereikend is. DexGuard werkt in de post-compilatiefase en transformeert DEX-bytecode naar een beveiligde vorm voordat deze in een APK wordt verpakt.

De architectuur van DexGuard is gebaseerd op een gelaagd beveiligingsmodel. De eerste laag is obfuscatie van klasse-, methode- en veldnamen met behulp van naamoverbelasting (overload induction). De tweede is versleuteling van tekenreeksconstanten en het laden ervan via stub-methoden in runtime. De derde is integriteitscontrole van de APK door verificatie van de controlesom van handtekeningen. Volgens het technisch rapport van Guardsquare (2025) verhoogt de gecombineerde toepassing van deze lagen de analysetijd van een applicatie van enkele minuten tot enkele weken.

DexGuard ondersteunt alle typen Android-projecten: applicaties, bibliotheken, SDK’s en spelprojecten op Unity. Het hulpmiddel integreert in de standaard Gradle-pijplijn via de plug-in com.guardsquare.dexguard en vereist geen handmatige interventie na configuratie.

Het belangrijkste verschil tussen DexGuard en open-source alternatieven is actieve runtime-bescherming. Het hulpmiddel verdoezelt niet alleen code, maar voegt een agent toe die controles uitvoert tijdens de werking van de applicatie. Hiermee kunnen aanvallen zoals Frida-injectie, Xposed of debuggen via JDWP worden gedetecteerd en kan erop worden gereageerd: noodstop, generatie van valse gegevens of servermelding.

Hoe werkt obfuscatie in DexGuard

Het obfuscatieproces in DexGuard bestaat uit opeenvolgende fasen van bytecodetransformatie, elk gericht op een specifieke aanvalsvector.

Naamobfuscatie met overbelasting

Een standaard obfuscator vervangt namen door enkelkarakter a, b, c. DexGuard gebruikt overload induction — wijst dezelfde korte naam toe aan verschillende methoden met verschillende handtekeningen. De decompiler kan de overbelasting niet oplossen en genereert onjuiste code. Volgens Guardsquare-tests verhoogt naamoverbelasting het aantal decompilatiefouten met 78%.

Versleuteling van constanten

Tekenreeksliterals, URL’s, API-sleutels en tokens worden versleuteld met het AES-256-algoritme tijdens de buildfase. In runtime ontsleutelt een stub-methode de tekenreeks voor gebruik en wist het geheugengebied erna. Dit beschermt tegen statische weergave van strings in het DEX-bestand. Voorbeeld zonder versleuteling: een aanvaller voert strings dexguard.apk uit en ziet alle API-eindpunten in platte tekst.

Code-integriteitscontrole

DexGuard berekent een SHA-256-hash voor elk DEX-bestand en slaat de waarde op in de native laag. Bij het starten van de applicatie vergelijkt de agent de huidige hash met de referentie. Bij afwijking (gewijzigde APK) wordt de applicatie beëindigd. Optioneel kan de integriteit van bronnen en het manifest worden gecontroleerd.

// build.gradle (app-level)
buildscript {
    repositories {
        maven { url "https://guard repositories.com/dexguard" }
    }
    dependencies {
        classpath "com.guardsquare:dexguard-gradle-plugin:9.1.05"
    }
}

apply plugin: "com.guardsquare.dexguard"

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            dexguard {
                config "dexguard-project.txt"
            }
        }
    }
}

DexGuard vs ProGuard: belangrijkste verschillen

Beide hulpmiddelen zijn ontwikkeld door hetzelfde bedrijf, maar gericht op verschillende scenario’s. ProGuard is een open-source optimizer en minimale obfuscator die standaard in de Android SDK is opgenomen. DexGuard is een commercieel product dat beveiligingslagen toevoegt die niet beschikbaar zijn in de gratis versie.

De keuze tussen de hulpmiddelen wordt bepaald door de klasse van te beschermen informatie. Voor een gewone mobiele applicatie is ProGuard voldoende. Voor bank-, betalings- en medische applicaties, waar openbaarmaking van code financiële of regelgevingsrisico’s met zich meebrengt, wordt DexGuard aanbevolen. Volgens OWASP Mobile Top 10 (2024) wordt het ontbreken van obfuscatie in applicaties met vertrouwelijke gegevens als een kritiek risico beschouwd.

DexGuard configureren in een Gradle-project

Integratie van DexGuard begint met het toevoegen van de Guardsquare-repository in de root build.gradle. Plug-in versie 9.x is compatibel met AGP 7.4–8.5 en Gradle 7.6–8.7. De beveiligingsconfiguratie wordt opgegeven in een apart dexguard-project.txt, waar specifieke technieken worden ingeschakeld.

// root build.gradle
buildscript {
    repositories {
        maven { url "https://maven.guardsquare.com/dexguard" }
    }
}

// dexguard-project.txt — minimale configuratie
# Tekenreeksversleuteling
@stringEncryption

# Obfuscatie met naamoverbelasting
@overloadInduction

# APK-integriteitscontrole
@integrityCheck

# Bescherming tegen debuggen en emulator
@antiDebug
@antiEmulator

De richtlijnen @stringEncryption en @overloadInduction zijn essentieel voor de bescherming van commerciële code. Bij activering van alle annotaties neemt de buildtijd met 30–60 seconden toe, wat gerechtvaardigd is gezien het beschermingsniveau. De configuratie wordt opgeslagen in VCS en alleen toegepast voor de release-build.

Het is belangrijk om uitzonderingen te configureren voor klassen die via reflection worden gebruikt. DexGuard analyseert, net als ProGuard, reflection niet automatisch. In dexguard-project.txt moeten -keep-regels worden toegevoegd voor klassen van bibliotheken die worden geladen via Class.forName of @JavascriptInterface.

// dexguard-project.txt — keep-regels
# Gson-modelklassen behouden
-keep class com.example.model.** { *; }

# WebView-interfaces behouden
-keepclassmembers class * {
    @android.webkit.JavascriptInterface <methods>;
}

# Firebase crash-rapporten uitsluiten
-keep class com.google.firebase.** { *; }

Beschermingstechnieken van DexGuard

DexGuard omvat meer dan 20 beschermingstechnieken, verdeeld in statische (tijdens de buildfase) en dynamische (in runtime). De keuze van specifieke technieken hangt af van het bedreigingsmodel van de applicatie.

Statische bescherming

Bronversleuteling — afbeeldingen, assets en configuratiebestanden worden versleuteld en ontsleuteld bij de eerste toegang. Control flow obfuscation voegt dode code in en wijzigt de instructievolgorde, waardoor bytecode onleesbaar wordt voor decompilers zoals jadx. Constante verhulling (constant hiding) vervangt numerieke literals door rekenkundige expressies die in runtime worden berekend.

Dynamische bescherming (RASP)

Runtime Application Self-Protection — een agent in de applicatie die het gedrag van de uitvoeringsomgeving bewaakt. DexGuard RASP detecteert: Frida-verbinding via /proc/self/maps, aanwezigheid van Xposed Framework, uitvoering onder een debugger (JDWP), Android-emulator (QEMU). Bij detectie van een bedreiging wordt een beleid geactiveerd — crash of generatie van onjuiste gegevens. Volgens onderzoek van OWASP Mobile Security (2025) heeft RASP-bescherming 94% van de typische geautomatiseerde aanvallen gestopt.

Bescherming tegen time-based aanvallen

DexGuard voegt willekeurige vertragingen toe in kritieke codedelen, waardoor de doorlooptijd bij dynamische analyse toeneemt. De parameter wordt ingesteld in milliseconden en gerandomiseerd bij elke build. Dit bemoeilijkt het gebruik van fuzz-tools en automatische scanners.

Integratierichtlijnen en compatibiliteit

Bij het implementeren van DexGuard in een bestaand project moet rekening worden gehouden met achterwaartse compatibiliteit met bibliotheken en populaire SDK’s. Sommige bibliotheken zijn niet compatibel met extreme obfuscatie vanwege reflection-aanroepen.

Compatibiliteit met populaire SDK’s

DexGuard is compatibel met Firebase Crashlytics, Google Analytics, Google Play Services, Retrofit, OkHttp, Glide en Gson bij correcte keep-regels. Bibliotheken die annotaties en codegeneratie gebruiken (Dagger, Hilt, Room, DataBinding) vereisen expliciet behoud van gegenereerde klassen. Het Guardsquare-team geeft officiële configuratievoorbeelden voor populaire SDK’s.

Omgevingsvereisten

Minimale vereisten: Android Gradle Plugin 7.4, Gradle 7.6, JDK 11. DexGuard 9.1 ondersteunt targetSdk 34 en compileSdk 34. Voor Java 17 en AGP 8.2+ is DexGuard versie 9.2 en hoger vereist. Het hulpmiddel is niet compatibel met R8 in volledige optimalisatiemodus — bij gebruik van DexGuard wordt R8 automatisch uitgeschakeld.

Testen na obfuscatie

Na configuratie van DexGuard moet regressietesten worden uitgevoerd op alle paden die worden beïnvloed door reflection en dynamische klasselading. Het wordt aanbevolen om UI-autotests uit te voeren op een build met ingeschakelde beveiliging vóór de release. Guardsquare biedt het hulpprogramma DexGuard Tracer aan, dat ClassNotFoundException-fouten in runtime logt zonder de applicatie te laten crashen, waardoor het debuggen van keep-regels wordt vereenvoudigd.