DexGuard: cos'è, offuscamento e protezione delle applicazioni Android

Cos'è DexGuard?

DexGuard è un strumento commerciale per offuscare e proteggere applicazioni Android, sviluppato dallo stesso team che ha creato ProGuard (Eric Lafortune). Il prodotto è apparso nel 2012 come estensione per progetti in cui l'offuscamento standard di ProGuard è insufficiente. DexGuard opera nella fase post-compilazione, trasformando il bytecode DEX in una forma protetta prima del confezionamento dell'APK.

L'architettura di DexGuard è costruita su un modello di protezione a più livelli. Il primo livello è l'offuscamento dei nomi di classi, metodi e campi utilizzando overload induction. Il secondo è la crittografia delle costanti stringa e il loro caricamento tramite metodi stub in fase di esecuzione. Il terzo è il controllo di integrità dell'APK attraverso la verifica del checksum delle firme. Secondo un rapporto tecnico di Guardsquare (2025), l'uso combinato di questi livelli aumenta il tempo di analisi dell'applicazione da pochi minuti a diverse settimane.

DexGuard supporta tutti i tipi di progetti Android: applicazioni, librerie, SDK e progetti di giochi Unity. Lo strumento si integra nella pipeline standard di Gradle tramite il plugin com.guardsquare.dexguard e non richiede intervento manuale dopo la configurazione.

La differenza principale tra DexGuard e le alternative open source è la protezione attiva in fase di esecuzione. Lo strumento non si limita a offuscare il codice, ma aggiunge un agente che esegue controlli durante l'esecuzione dell'applicazione. Ciò consente di rilevare attacchi come l'iniezione di Frida, Xposed o il debugging JDWP e di rispondere con arresto, generazione di dati falsi o notifica al server.

Come funziona l'offuscamento in DexGuard

Il processo di offuscamento in DexGuard consiste in fasi sequenziali di trasformazione del bytecode, ciascuna mirata a un vettore di attacco specifico.

Offuscamento dei nomi con overload induction

Un offuscatore standard sostituisce i nomi con caratteri singoli a, b, c. DexGuard utilizza overload induction — assegna lo stesso nome breve a metodi diversi con firme diverse. Il decompilatore non può risolvere il sovraccarico e genera codice errato. Secondo i test di Guardsquare, il sovraccarico dei nomi aumenta gli errori di decompilazione del 78%.

Crittografia delle costanti

I letterali stringa, gli URL, le chiavi API e i token vengono crittografati con AES-256 in fase di compilazione. In fase di esecuzione, un metodo stub decifra la stringa prima dell'uso e azzera l'area di memoria dopo. Questo protegge dalla visualizzazione statica delle stringhe nel file DEX. Esempio di risultato senza crittografia: un attaccante esegue strings dexguard.apk e vede tutti gli endpoint API in chiaro.

Controllo di integrità del codice

DexGuard calcola un hash SHA-256 per ogni file DEX e memorizza il valore nel layer nativo. All'avvio dell'applicazione, l'agente confronta l'hash corrente con quello di riferimento. In caso di discrepanza (APK modificato), l'applicazione termina. Inoltre, è possibile configurare controlli di integrità per le risorse e il manifest.

// build.gradle (livello app)
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: differenze principali

Entrambi gli strumenti sono sviluppati dalla stessa azienda ma mirano a scenari diversi. ProGuard è un ottimizzatore open source e offuscatore minimo incluso di default nell'Android SDK. DexGuard è un prodotto commerciale che aggiunge livelli di protezione non disponibili nella versione gratuita.

La scelta tra gli strumenti è determinata dalla classe di informazioni da proteggere. Per un'applicazione mobile ordinaria, ProGuard è sufficiente. Per applicazioni bancarie, di pagamento e mediche in cui la divulgazione del codice comporta rischi finanziari o normativi, DexGuard è la soluzione raccomandata. Secondo OWASP Mobile Top 10 (2024), la mancanza di offuscamento nelle applicazioni con dati sensibili è considerata un rischio critico.

Configurazione di DexGuard in un progetto Gradle

L'integrazione di DexGuard inizia con l'aggiunta del repository Guardsquare nel build.gradle radice. Il plugin versione 9.x è compatibile con AGP 7.4–8.5 e Gradle 7.6–8.7. La configurazione di protezione è definita in un file separato dexguard-project.txt, dove vengono abilitate tecniche specifiche.

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

// dexguard-project.txt — configurazione minima
# Crittografia delle stringhe
@stringEncryption

# Offuscamento con overload induction
@overloadInduction

# Controllo di integrità dell'APK
@integrityCheck

# Protezione da debugger ed emulatore
@antiDebug
@antiEmulator

Le direttive @stringEncryption e @overloadInduction sono fondamentali per proteggere il codice commerciale. Quando tutte le annotazioni sono attivate, il tempo di compilazione aumenta di 30–60 secondi, giustificato dal livello di protezione. La configurazione è memorizzata nel VCS e applicata solo per i build di release.

È importante configurare eccezioni per le classi che utilizzano la riflessione. DexGuard, come ProGuard, non analizza automaticamente la riflessione. In dexguard-project.txt, è necessario aggiungere regole -keep per le classi di librerie caricate tramite Class.forName o @JavascriptInterface.

// dexguard-project.txt — regole keep
# Mantenere classi modello Gson
-keep class com.example.model.** { *; }

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

# Escludere rapporti di crash Firebase
-keep class com.google.firebase.** { *; }

Tecniche di protezione di DexGuard

DexGuard include oltre 20 tecniche di protezione, divise in statiche (in fase di compilazione) e dinamiche (in fase di esecuzione). La scelta delle tecniche specifiche dipende dal modello di minaccia dell'applicazione.

Protezione statica

Crittografia delle risorse — immagini, asset e file di configurazione vengono crittografati e decifrati al primo accesso. L'offuscamento del flusso di controllo inserisce codice morto e modifica le sequenze di istruzioni, rendendo il bytecode illeggibile per decompilatori come jadx. L'occultamento delle costanti sostituisce i letterali numerici con espressioni aritmetiche calcolate in fase di esecuzione.

Protezione dinamica (RASP)

Runtime Application Self-Protection — un agente all'interno dell'applicazione che monitora il comportamento dell'ambiente di esecuzione. DexGuard RASP rileva: connessione Frida tramite /proc/self/maps, presenza di Xposed Framework, esecuzione sotto un debugger (JDWP), emulatore Android (QEMU). Al rilevamento di una minaccia, viene attivata una politica — arresto o generazione di dati errati. Secondo la ricerca OWASP Mobile Security (2025), la protezione RASP ha fermato il 94% degli attacchi automatizzati tipici.

Protezione dagli attacchi basati sul tempo

DexGuard aggiunge ritardi casuali in sezioni critiche del codice, aumentando il tempo di brute force durante l'analisi dinamica. Il parametro è impostato in millisecondi e randomizzato ad ogni build. Questo complica l'uso di strumenti di fuzzing e scanner automatici.

Linee guida per l'integrazione e compatibilità

Quando si integra DexGuard in un progetto esistente, è necessario considerare la compatibilità all'indietro con librerie e SDK popolari. Alcune librerie sono incompatibili con l'offuscamento estremo a causa di chiamate di riflessione.

Compatibilità con SDK popolari

DexGuard è compatibile con Firebase Crashlytics, Google Analytics, Google Play Services, Retrofit, OkHttp, Glide e Gson con corrette regole keep. Le librerie che utilizzano annotazioni e generazione di codice (Dagger, Hilt, Room, DataBinding) richiedono la conservazione esplicita delle classi generate. Il team di Guardsquare pubblica esempi di configurazione ufficiali per SDK popolari.

Requisiti ambientali

Requisiti minimi: Android Gradle Plugin 7.4, Gradle 7.6, JDK 11. DexGuard 9.1 supporta targetSdk 34 e compileSdk 34. Per Java 17 e AGP 8.2+, è richiesta la versione 9.2 o successiva di DexGuard. Lo strumento è incompatibile con R8 in modalità di ottimizzazione completa — quando si utilizza DexGuard, R8 viene automaticamente disabilitato.

Test dopo l'offuscamento

Dopo aver configurato DexGuard, è necessario eseguire test di regressione su tutti i percorsi interessati dalla riflessione e dal caricamento dinamico delle classi. Si consiglia di eseguire test di automazione dell'interfaccia utente su un build con protezione abilitata prima del rilascio. Guardsquare fornisce l'utilità DexGuard Tracer, che registra gli errori ClassNotFoundException in fase di esecuzione senza arrestare l'applicazione, semplificando il debug delle regole keep.