Root Detection в мобилните приложения — същност, методи за откриване и принцип на работа

Какво е Root Detection?

Root Detection — софтуерен механизъм, който определя наличието на root достъп на Android устройство. Root достъпът предоставя пълен контрол над операционната система, позволявайки на приложения и скриптове да изпълняват команди с UID 0. На руутнато устройство се губи изолацията на приложенията (Android Sandbox), което прави възможно прихващането на клавиатурен вход, четене на SQLite бази данни на други приложения, инжектиране на код в процеси и подмяна на SSL сертификати в довереното хранилище.

За финансови и корпоративни приложения работата на руутнато устройство представлява неприемлив риск: нападателят получава достъп до токени, сесийни ключове и лични данни. Регулаторите, включително PCI Security Standards Council, изискват от платежните приложения откриване и реакция на root достъп. В отговор на това Android разработчиците вграждат Root Detection като част от стратегията за проактивна защита.

Съществуват два подхода за откриване: статичен, анализиращ файловата система и инсталираните пакети, и динамичен, извършващ проверки в runtime. Комбинираният подход се счита за най-надежден, тъй като покрива различни вектори на заобикаляне. Според изследване на NowSecure (2025), 76% от банковите приложения в топ 100 на Google Play съдържат някаква форма на Root Detection.

Статични методи за откриване на root

Статичните методи се изпълняват при стартиране на приложението и проверяват признаци на root достъп, оставени от инструментите за руутване във файловата система. Тези методи не изискват изпълнение на привилегировани команди и работят в контекста на обикновено приложение.

Проверка за наличие на su бинарен файл

Основният признак на root достъп — наличието на изпълним файл su в стандартни пътища: /system/bin/su, /system/xbin/su, /sbin/su, /su/bin/su. Приложението проверява съществуването на файла чрез File.exists() или нативна реализация на access() от libc. Допълнително може да се опита изпълнение на su --version или su -c id и проверка на изходния код.

Търсене на root мениджъри

Типични приложения за управление на root достъп: Superuser, SuperSU, Magisk Manager, KingRoot. Тяхното наличие се проверява чрез PackageManager.getPackageInfo() или четене на директорията /data/app/. Пакети за проверка: com.topjohnwu.magisk, eu.chainfire.supersu, com.noshufou.android.su, com.thirdparty.superuser, com.koushikdutta.superuser, com.zacharee1.systemuituner.

Проверка на системни свойства

Android съхранява информация за състоянието на системата в системни свойства, достъпни чрез System.getProperty и Build.TAGS. Ако стойността на Build.TAGS съдържа test-keys вместо release-keys — това показва персонализиран firmware, често с root достъп. Допълнително се проверяват ro.build.tags, ro.debuggable и ro.secure чрез четене на /system/build.prop.

public class RootDetectionChecker {
    private static final String[] SU_PATHS = {
        "/system/bin/su",
        "/system/xbin/su",
        "/sbin/su",
        "/su/bin/su",
        "/system/sd/xbin/su"
    };

    public boolean checkRootByFiles() {
        for (String path : SU_PATHS) {
            if (new File(path).exists()) {
                return true;
            }
        }
        return false;
    }

    public boolean checkRootByPackages(Context ctx) {
        String[] packages = {
            "com.topjohnwu.magisk",
            "eu.chainfire.supersu",
            "com.noshufou.android.su",
            "com.koushikdutta.superuser"
        };
        for (String pkg : packages) {
            try {
                ctx.getPackageManager().getPackageInfo(pkg, 0);
                return true;
            } catch (PackageManager.NameNotFoundException e) {
                // пакетът не е намерен
            }
        }
        return false;
    }
}

Динамични методи за проверка

Динамичните методи се изпълняват по време на работа на приложението и анализират средата на изпълнение. За разлика от статичните, те могат да открият руутване, скрито чрез Magisk Hide или Zygisk, тъй като проверяват поведението на системата, а не само файловата структура.

Проверка на mount точки

При root достъп някои системни дялове се монтират с флаг rw (read-write) вместо ro (read-only). Приложението чете /proc/mounts и проверява дали /system е монтиран като ro. Ако /system е монтиран като rw — това е признак на модифицирана система. Допълнително се проверява наличието на монтиране на /su чрез Magisk.

Тест на безопасен режим

Android Safe Mode изключва приложения на трети страни, включително root мениджъри. Коректната реализация на Root Detection може да провери дали устройството работи в безопасен режим. Ако приложението открие, че root мениджърите не са видими, но su бинарният файл съществува — това е признак за Magisk Hide.

Проверка на изпълнение на команди

Опит за изпълнение на su -c id чрез ProcessBuilder или Runtime.exec — директен тест за root достъп. Въпреки това, Magisk може да прихване това извикване. По-надежден вариант — проверка чрез нативен код: отваряне на /proc/1/limits или /proc/self/maps и анализ на UID на работещите процеси. Ако приложението може да получи UID 0 или да чете файлове, достъпни само за root — устройството е компрометирано.

public boolean checkRootDynamically() {
    // Проверка на flags за компилация
    String buildTags = Build.TAGS;
    if (buildTags != null && buildTags.contains("test-keys")) {
        return true;
    }

    // Проверка на монтирането на /system
    try {
        BufferedReader reader = new BufferedReader(
            new InputStreamReader(new FileInputStream("/proc/mounts"))
        );
        String line;
        while ((line = reader.readLine()) != null) {
            if (line.contains("/system")
                && line.contains("rw")) {
                reader.close();
                return true;
            }
        }
        reader.close();
    } catch (IOException e) {
        // грешка при четене на mount
    }

    return false;
}

Нативна реализация на Root Detection на C++

Root Detection, реализиран на Java, лесно се заобикаля чрез Xposed модули или Frida, които прихващат Java методи и подменят връщаните стойности. Нативната реализация на C++ чрез JNI е значително по-устойчива: инструментите за динамичен анализ, работещи на Java ниво, не виждат нативните извиквания на libc като stat, access, popen и dlopen.

#include <unistd.h>
#include <sys/stat.h>
#include <cstring>
#include <vector>

extern "C"
JNIEXPORT jboolean JNICALL
Java_com_example_checker_RootCheck_nativeCheck(
    JNIEnv* env, jobject instance) {

    std::vector<const char*> paths = {
        "/system/bin/su",
        "/system/xbin/su",
        "/sbin/su",
        "/data/local/su"
    };

    struct stat st;
    for (const char* path : paths) {
        if (stat(path, &st) == 0) {
            return JNI_TRUE;
        }
    }
    return JNI_FALSE;
}

Нативната проверка не използва Java API, което я прави невидима за инструментите за заобикаляне, работещи на Dalvik/ART ниво. За допълнителна защита се препоръчва съхраняване на константите (списък с пътища) не в read-only секция, а изчисляването им чрез прости обратими функции. Извикването stat от libc директно се обръща към ядрото на Linux, заобикаляйки Java обвивки, и не може да бъде прихванато чрез Xposed.

Методи за заобикаляне на Root Detection

Разработчиците на защита трябва да разбират съществуващите методи за заобикаляне, за да изградят устойчива система за откриване. Всеки метод за заобикаляне изисква контрамярка на съответното ниво.

Заобикаляне чрез Magisk Hide и Zygisk

Magisk — най-популярният инструмент за руутване на Android 9–14. Magisk Hide скрива присъствието на su от /proc и подменя резултатите от проверката на пътища. Magisk работи на ядрено ниво и прихваща stat() и access(), преди приложението да ги види. Контрамярка: проверка на присъствието на самия Magisk чрез наличие на /sbin/.magisk или проверка чрез четене на собствените maps — Magisk вгражда своята библиотека във всеки процес.

Заобикаляне чрез Frida

Frida — инструмент за динамична инструментация, който може да прихваща нативни функции чрез Ptrace или Dobby. Frida заменя връщаната стойност на всяка проверка, подменяйки резултата от stat на ENOENT. Контрамярка: проверка на целостта на нативните функции чрез изчисляване на контролна сума на инструкциите в паметта и откриване на Frida чрез анализ на /proc/self/maps за наличие на frida-agent.so или frida-helper.

Заобикаляне чрез кръпка на APK

Root Detection, реализиран на Java, се премахва за 2–3 минути: APK се разопакова чрез apktool, в smali кода се променя връщаната стойност на метода на false, APK се сглобява отново и се подписва. Контрамярка: преместване на критичната логика в нативен код и проверка на цифровия подпис на приложението в runtime чрез Signature API или сравняване на хеша на APK с еталона на сървъра.

Препоръки за надеждна защита

Ефективният Root Detection се изгражда върху многослойна архитектура. Никой метод поотделно не осигурява достатъчно ниво на защита. Комбинацията от статични и динамични проверки, нативен код и сървърна проверка дава максимална устойчивост.

Сървърна проверка

Не разчитайте само на проверка от клиентска страна. Изпращайте на сървъра резултатите от Root Detection заедно с еднократен сесиен токен. Сървърът взема решение за блокиране или ограничаване на функционалността. Това предотвратява атаки на API ниво, където клиентското приложение може да бъде модифицирано, но сървърът остава доверена страна.

Обфускация на кода за проверка

Кодът на Root Detection трябва да бъде обфусциран. Ако нападателят вижда в jadx ясна последователност от проверки на su пътища — заобикалянето ще отнеме минути. Използвайте ProGuard или DexGuard за заплитане на контролния поток и криптиране на низове. Обфускацията увеличава времето за анализ на защитния код от няколко минути до няколко часа.

Редовно обновяване на сигнатурите

Списъкът на проверяваните пътища, пакети и индикатори трябва да се обновява с всяка версия на приложението. Нови инструменти за руутване и заобикаляне се появяват всеки месец. Статичен списък, непроменян от година, не открива съвременните методи. Препоръчва се зареждане на актуални сигнатури от сървъра при стартиране на приложението преди извършване на проверки.