DexGuard: шта је то, обфускација и заштита Android примена

Шта је DexGuard?

DexGuard је комерцијални алат за обфускацију и заштиту Android примена, који је развио исти тим који је креирао ProGuard (Eric Lafortune). Производ се појавио 2012. године као проширење за пројекте где стандардна обфускација ProGuard-а није довољна. DexGuard ради у фази након компилације, претварајући DEX-бајткод у заштићену форму пре паковања APK-а.

Архитектура DexGuard-а је изграђена на вишеслојном моделу заштите. Први слој — обфускација имена класа, метода и поља коришћењем преоптерећења имена (overload induction). Други — шифровање низаних константи и њихово учитавање кроз stub методе у runtime-у. Трећи — контрола интегритета APK-а путем провере контролне суме потписа. Према техничком извештају Guardsquare (2025), комбинована примена ових слојева повећава време анализе апликације са неколико минута на неколико недеља.

DexGuard подржава све типове Android пројеката: апликације, библиотеке, SDK и игричке пројекте на Unity-ју. Алат се интегрише у стандардни Gradle пајплајн путем плагина com.guardsquare.dexguard и не захтева ручну интервенцију након подешавања.

Кључна разлика DexGuard-а од open-source аналога — активна заштита у runtime-у. Алат не само замрачује код, већ додаје агента који обавља провере током рада апликације. Ово омогућава откривање напада као што су убацивање Frida-е, Xposed-а или дебаговање путем JDWP-а и реаговање на њих: хитно заустављање, генеране лажних података или обавештавање сервера.

Како функционише обфускација у DexGuard-у

Процес обфускације у DexGuard-у састоји се од узастопних фаза трансформације бајткода, од којих се свака усмерена на одређени вектор напада.

Обфускација имена са преоптерећењем

Стандардни обфускатор замењује имена једнословним a, b, c. DexGuard користи overload induction — додјељуће исто кратко име различитим методама са различитим потписима. Декомпилатор не може да ријеши преоптерећење и генерише неисправан код. Према тестовима Guardsquare-а, преоптерећење имена повећава број грешака декомпилације за 78%.

Шифровање константи

Низани литерали, URL-ови, API кључеви и токени се шифрују AES-256 алгоритмом у фази компилације. У runtime-у, stub метода дешифрује низку пре употребе и брише меморијску област након. Ово штити од статичког прегледа низови у DEX датотеци. Пример без шифровања: нападач покреће strings dexguard.apk и види све API ендпоинте у отвореном облику.

Контрола интегритета кода

DexGuard израчунава SHA-256 хеш за сваку DEX датотеку и чува вриједност у нативном слоју. При покретању апликације, агент упореди тренутни хеш са еталоном. У случају одступања (измењен APK), апликација се зауставља. Додатно се може подесити провера интегритета ресурса и манифеста.

// build.gradle (ниво апликације)
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: кључне разлике

Оба алата је развила иста компанија, али су намењени за различите сценарије. ProGuard — open-source оптимизатор и минимални обфускатор који је подразумевано укључен у Android SDK. DexGuard — комерцијални производ који додаје нивое заштите недоступне у бесплатној верзији.

Избор између алата одређује класа заштићених информација. За обичну мобилну апликацију ProGuard је довољан. За банкарске, платне и медицинске апликације, где откривање кода повлачи финансијске или регулаторне ризике, DexGuard је препоручено решење. Према OWASP Mobile Top 10 (2024), одсуство обфускације у апликацијама са поверљивим подацима сматра се критичним ризиком.

Подешавање DexGuard-а у Gradle пројекту

Интеграција DexGuard-а почиње повезивањем Guardsquare репозиторијума у коренском build.gradle-у. Плагин верзије 9.x је компатибилан са AGP 7.4–8.5 и Gradle 7.6–8.7. Конфигурација заштите се поставља у засебној dexguard-project.txt датотеци, где се укључују одређене технике.

// коренски build.gradle
buildscript {
    repositories {
        maven { url "https://maven.guardsquare.com/dexguard" }
    }
}

// dexguard-project.txt — минимална конфигурација
# Шифровање низови
@stringEncryption

# Обфускација са преоптерећењем имена
@overloadInduction

# Контрола интегритета APK-а
@integrityCheck

# Заштита од дебага и емулатора
@antiDebug
@antiEmulator

Директиве @stringEncryption и @overloadInduction су кључне за заштиту комерцијалног кода. При активацији свих анотација, време компилације се повећава за 30–60 секунди, што је оправдано нивоом заштите. Конфигурација се чува у VCS-у и примењује само за release билд.

Важно је подесити изузетке за класе који се користе кроз reflection. DexGuard, као и ProGuard, не анализира reflection аутоматски. У dexguard-project.txt треба додати -keep правила за класе библиотека које се учитавају кроз Class.forName или @JavascriptInterface.

// dexguard-project.txt — keep правила
# Сачувај Gson модел класе
-keep class com.example.model.** { *; }

# Сачувај WebView интерфејсе
-keepclassmembers class * {
    @android.webkit.JavascriptInterface <methods>;
}

# Изузеи Firebase краш извештаје
-keep class com.google.firebase.** { *; }

Технике заштите DexGuard-а

DexGuard садржи више од 20 техника заштите, подељених на статичке (у фази компилације) и динамичке (у runtime-у). Избор одређених техника зависи од модела претњи апликације.

Статичка заштита

Шифровање ресурса — слике, асети и конфигурациони фајлови се шифрују и дешифрују при првом приступу. Замрачивање тока контроле (control flow obfuscation) умеће мртви код и мења редослед инструкција, чинећи бајткод нечитљивим за декомпилаторе као што је jadx. Скривање константи (constant hiding) замењује бројчане литерале аритметичким изразима који се израчунавају у runtime-у.

Динамичка заштита (RASP)

Runtime Application Self-Protection — агент унутар апликације који прати понашање окружења извршавања. DexGuard RASP открива: повезивање Frida-е кроз /proc/self/maps, присуство Xposed Framework-а, покретање под дебагером (JDWP), Android емулатор (QEMU). При откривању претње, покреће се политика — crash или генеране неисправних података. Према истраживању OWASP Mobile Security (2025), RASP заштита је зауставила 94% типичних аутоматизованих напада.

Заштита од Time-based напада

DexGuard додаје произвољне кашњења у критичним деловима кода, повећавајући време проба при динамичкој анализи. Параметар се поставља у милисекундама и рандомизује се при свакој компилацији. Ово отежава коришћење алата за fuzzing и аутоматских скенера.

Правила интеграције и компатибилност

При увођењу DexGuard-а у постојећи пројекат потребно је узети у обзир повратну компатибилност са библиотекама и популарним SDK-овима. Неке библиотеке су некомпатибилне са екстремном обфускацијом због reflection позива.

Компатибилност са популарним SDK-овима

DexGuard је компатибилан са Firebase Crashlytics, Google Analytics, Google Play Services, Retrofit, OkHttp, Glide и Gson уз правилне кееп правила. Библиотеке које користе анотације и генерацију кода (Dagger, Hilt, Room, DataBinding) захтевају експлицитно чување генерисаних класа. Guardsquare тим објављује званичне конфигурационе примјерке за популарне SDK.

Захтеви окружења

Минимални захтеви: Android Gradle Plugin 7.4, Gradle 7.6, JDK 11. DexGuard 9.1 подржава targetSdk 34 и compileSdk 34. За Java 17 и AGP 8.2+ потребна је верзија DexGuard 9.2 и више. Алат је некомпатибилан са R8 у режиму пуне оптимизације — при коришћењу DexGuard-а, R8 се аутоматски искључује.

Тестирање након обфускације

Након подешавања DexGuard-а потребно је извршити регресионо тестирање свих путава које су погођени reflection-ом и динамичким учитавањем класа. Препоручује се покретање UI аутотестова на билду са укљученом заштитом пре издавања. Guardsquare обезбјеђује алат DexGuard Tracer који логује ClassNotFoundException грешке у runtime-у без падања апликације, олакшавајући дебаговање keep правила.