DexGuard: co to jest, obfuskacja i ochrona aplikacji Android

Co to jest DexGuard?

DexGuard — to komercyjne narzędzie do obfuskacji i ochrony aplikacji Android, opracowane przez ten sam zespół, który stworzył ProGuard (Eric Lafortune). Produkt pojawił się w 2012 roku jako rozszerzenie dla projektów, w których standardowa obfuskacja ProGuard jest niewystarczająca. DexGuard działa na etapie post-kompilacji, przekształcając DEX-bajtkod w zabezpieczoną formę przed pakowaniem APK.

Architektura DexGuard opiera się na wielopoziomowym modelu ochrony. Pierwszy poziom — obfuskacja nazw klas, metod i pól z wykorzystaniem przeciążania nazw (overload induction). Drugi — szyfrowanie stałych stringowych i ładowanie ich przez metody stub w runtime. Trzeci — kontrola integralności APK poprzez sprawdzanie sumy kontrolnej sygnatur. Według danych raportu technicznego Guardsquare (2025), połączone zastosowanie tych poziomów zwiększa czas analizy aplikacji z kilku minut do kilku tygodni.

DexGuard obsługuje wszystkie typy projektów Android: aplikacje, biblioteki, SDK i projekty gier na Unity. Narzędzie integruje się ze standardowym pipelinem Gradle przez plugin com.guardsquare.dexguard i nie wymaga ręcznej interwencji po konfiguracji.

Kluczowa różnica między DexGuard a open-source'owymi odpowiednikami — aktywna ochrona w runtime. Narzędzie nie tylko zaciemnia kod, ale dodaje agenta, który wykonuje sprawdzenia podczas działania aplikacji. Pozwala to wykrywać takie ataki jak wstrzyknięcie Frida, Xposed lub debugowanie przez JDWP i reagować na nie: awaryjne zakończenie, generowanie fałszywych danych lub powiadomienie serwera.

Jak działa obfuskacja w DexGuard

Proces obfuskacji w DexGuard składa się z kolejnych etapów transformacji bajtkodu, z których każdy jest ukierunkowany na konkretny wektor ataku.

Obfuskacja nazw z przeciążaniem

Standardowy obfusktor zastępuje nazwy jednoznakowymi a, b, c. DexGuard używa overload induction — przypisuje tę samą krótką nazwę różnym metodom z różnymi sygnaturami. Dekompilator nie może rozwiązać przeciążenia i generuje nieprawidłowy kod. Według testów Guardsquare, przeciążanie nazw zwiększa liczbę błędów dekompilacji o 78%.

Szyfrowanie stałych

Literały stringowe, URL-e, klucze API i tokeny są szyfrowane algorytmem AES-256 na etapie kompilacji. W runtime metoda stub odszyfrowuje string przed użyciem i zeruje obszar pamięci po. Chroni to przed statycznym przeglądaniem stringów w pliku DEX. Przykład skutku bez szyfrowania: atakujący uruchamia strings dexguard.apk i widzi wszystkie endpointy API w otwartej postaci.

Kontrola integralności kodu

DexGuard oblicza hash SHA-256 dla każdego pliku DEX i zapisuje wartość w warstwie natywnej. Przy uruchomieniu aplikacji agent porównuje bieżący hash z wzorcowym. W przypadku rozbieżności (zmodyfikowany APK) aplikacja jest zamykana. Dodatkowo można skonfigurować sprawdzanie integralności zasobów i manifestu.

// build.gradle (poziom aplikacji)
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: kluczowe różnice

Oba narzędzia są opracowane przez tę samą firmę, ale przeznaczone do różnych scenariuszy. ProGuard — to open-source'owy optymalizator i minimalny obfusktor, który jest domyślnie dołączony do Android SDK. DexGuard — produkt komercyjny, dodający poziomy ochrony niedostępne w darmowej wersji.

Wybór między narzędziami zależy od klasy chronionych informacji. Dla zwykłej aplikacji mobilnej ProGuard jest wystarczający. Dla aplikacji bankowych, płatniczych i medycznych, gdzie ujawnienie kodu pociąga za sobą ryzyka finansowe lub regulacyjne, DexGuard jest zalecanym rozwiązaniem. Według OWASP Mobile Top 10 (2024), brak obfuskacji w aplikacjach z danymi poufnymi jest uznawany za krytyczne ryzyko.

Konfiguracja DexGuard w projekcie Gradle

Integracja DexGuard rozpoczyna się od podłączenia repozytorium Guardsquare w głównym build.gradle. Plugin w wersji 9.x jest kompatybilny z AGP 7.4–8.5 i Gradle 7.6–8.7. Konfiguracja ochrony jest określana w osobnym pliku dexguard-project.txt, gdzie włącza się konkretne techniki.

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

// dexguard-project.txt — minimalna konfiguracja
# Szyfrowanie stringów
@stringEncryption

# Obfuskacja z przeciążaniem nazw
@overloadInduction

# Kontrola integralności APK
@integrityCheck

# Ochrona przed debugowaniem i emulatorem
@antiDebug
@antiEmulator

Dyrektywy @stringEncryption i @overloadInduction — kluczowe dla ochrony kodu komercyjnego. Przy aktywacji wszystkich adnotacji czas kompilacji zwiększa się o 30–60 sekund, co jest uzasadnione poziomem ochrony. Konfiguracja jest przechowywana w VCS i stosowana tylko dla wydania produkcyjnego.

Ważne jest skonfigurowanie wyjątków dla klas używanych przez refleksję. DexGuard, podobnie jak ProGuard, nie analizuje refleksji automatycznie. W dexguard-project.txt należy dodać reguły -keep dla klas bibliotek ładowanych przez Class.forName lub @JavascriptInterface.

// dexguard-project.txt — reguły keep
# Zachowaj klasy modelu Gson
-keep class com.example.model.** { *; }

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

# Wyklucz raporty awarii Firebase
-keep class com.google.firebase.** { *; }

Techniki ochrony DexGuard

DexGuard zawiera ponad 20 technik ochrony, podzielonych na statyczne (na etapie kompilacji) i dynamiczne (w runtime). Wybór konkretnych technik zależy od modelu zagrożeń aplikacji.

Ochrona statyczna

Szyfrowanie zasobów — obrazy, assety i pliki konfiguracyjne są szyfrowane i odszyfrowywane przy pierwszym dostępie. Zaciemnianie przepływu sterowania (control flow obfuscation) wstawia martwy kod i zmienia kolejność instrukcji, czyniąc bajtkod nieczytelnym dla dekompilatorów takich jak jadx. Ukrywanie stałych (constant hiding) zastępuje literały liczbowe wyrażeniami arytmetycznymi obliczanymi w runtime.

Ochrona dynamiczna (RASP)

Runtime Application Self-Protection — agent wewnątrz aplikacji monitorujący zachowanie środowiska wykonawczego. DexGuard RASP wykrywa: podłączenie Frida przez /proc/self/maps, obecność Xposed Framework, uruchomienie pod debuggerem (JDWP), emulator Android (QEMU). Po wykryciu zagrożenia uruchamiana jest polityka — crash lub generowanie nieprawidłowych danych. Według badania OWASP Mobile Security (2025), ochrona RASP zatrzymała 94% typowych zautomatyzowanych ataków.

Ochrona przed atakami czasowymi

DexGuard dodaje losowe opóźnienia w krytycznych fragmentach kodu, zwiększając czas prób przy analizie dynamicznej. Parametr jest określany w milisekundach i randomizowany przy każdej kompilacji. Utrudnia to korzystanie z narzędzi fuzzingowych i automatycznych skanerów.

Zasady integracji i kompatybilność

Przy wdrażaniu DexGuard w istniejącym projekcie należy uwzględnić wsteczną kompatybilność z bibliotekami i popularnymi SDK. Niektóre biblioteki są niekompatybilne z ekstremalną obfuskacją ze względu na wywołania refleksyjne.

Kompatybilność z popularnymi SDK

DexGuard jest kompatybilny z Firebase Crashlytics, Google Analytics, Google Play Services, Retrofit, OkHttp, Glide i Gson przy odpowiednich regułach keep. Biblioteki używające adnotacji i code generation (Dagger, Hilt, Room, DataBinding) wymagają jawnego zachowania wygenerowanych klas. Zespół Guardsquare publikuje oficjalne przykłady konfiguracji dla popularnych SDK.

Wymagania środowiskowe

Minimalne wymagania: Android Gradle Plugin 7.4, Gradle 7.6, JDK 11. DexGuard 9.1 obsługuje targetSdk 34 i compileSdk 34. Dla Java 17 i AGP 8.2+ wymagana jest wersja DexGuard 9.2 i wyższa. Narzędzie jest niekompatybilne z R8 w trybie pełnej optymalizacji — przy użyciu DexGuard R8 jest wyłączany automatycznie.

Testowanie po obfuskacji

Po konfiguracji DexGuard należy przeprowadzić testy regresyjne wszystkich ścieżek objętych refleksją i dynamicznym ładowaniem klas. Zaleca się uruchamianie testów automatycznych UI na buildzie z włączoną ochroną przed wydaniem. Firma Guardsquare udostępnia narzędzie DexGuard Tracer, które loguje błędy ClassNotFoundException w runtime bez crashowania aplikacji, ułatwiając debugowanie reguł keep.