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-метод розшифровує рядок перед використанням і обнуляє область пам'яті після. Це захищає від статичного перегляду strings у DEX-файлі. Приклад результату без шифрування: зловмисник запускає strings dexguard.apk і бачить всі API-ендпоїнти у відкритому вигляді.

Контроль цілісності коду

DexGuard обчислює хеш SHA-256 для кожного DEX-файлу та зберігає значення в нативному шарі. При запуску додатка агент порівнює поточний хеш з еталонним. При розбіжності (змінений APK) додаток завершується. Додатково можна налаштувати перевірку цілісності ресурсів і маніфесту.

// 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: ключові відмінності

Обидва інструменти розроблені однією компанією, але націлені на різні сценарії. 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 і застосовується тільки для релізної збірки.

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

// dexguard-project.txt — keep правила
# Зберегти Gson model класи
-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. Приховування констант замінює числові літерали на арифметичні вирази, що обчислюються в 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 додає довільні затримки в критичні ділянки коду, збільшуючи час перебору при динамічному аналізі. Параметр задається в мілісекундах і рандомізується при кожній збірці. Це ускладнює використання фаззинг-інструментів та автоматичних сканерів.

Правила інтеграції та сумісність

При впровадженні DexGuard у існуючий проєкт потрібно враховувати зворотну сумісність з бібліотеками та популярними SDK. Деякі бібліотеки несумісні з екстремальною обфускацією через reflection-виклики.

Сумісність з популярними SDK

DexGuard сумісний з Firebase Crashlytics, Google Analytics, Google Play Services, Retrofit, OkHttp, Glide та Gson при коректних keep-правилах. Бібліотеки, що використовують анотації та code generation (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-правил.