Root Detection i mobilappar — essensen, detektionsmetoder och funktionsprincip

Vad är Root Detection?

Root Detection — en programvarumekanism som avgör förekomsten av root-åtkomst på en Android-enhet. Root-åtkomst ger fullständig kontroll över operativsystemet, vilket gör att appar och skript kan köra kommandon med UID 0. På en rotad enhet går isoleringen av appar (Android Sandbox) förlorad, vilket gör det möjligt att avlyssna tangentbordsinmatning, läsa SQLite-databaser från andra appar, injicera kod i processer och förfalska SSL-certifikat i det betrodda lagret.

För finansiella och företagsappar utgör drift på en rotad enhet en oacceptabel risk: angriparen får tillgång till token, sessionsnycklar och personuppgifter. Reglerande myndigheter, inklusive PCI Security Standards Council, kräver att betalappar upptäcker och reagerar på root-åtkomst. Som svar på detta integrerar Android-utvecklare Root Detection som en del av en proaktiv skyddsstrategi.

Det finns två tillvägagångssätt för detektion: statisk, som analyserar filsystemet och installerade paket, och dynamisk, som utför kontroller i runtime. Det kombinerade tillvägagångssättet anses vara mest tillförlitligt eftersom det täcker olika kringgåendvektorer. Enligt forskning från NowSecure (2025) innehåller 76% av bankapparna i topp 100 på Google Play någon form av Root Detection.

Statiska metoder för rootdetektion

Statiska metoder körs vid appstart och kontrollerar tecken på root-åtkomst som lämnats av rootverktyg i filsystemet. Dessa metoder kräver inte exekvering av privilegierade kommandon och fungerar i en vanlig apps kontext.

Kontroll av förekomst av su-binär

Huvudtecknet på root-åtkomst — förekomsten av den körbara filen su på standardvägar: /system/bin/su, /system/xbin/su, /sbin/su, /su/bin/su. Appen kontrollerar filens existens via File.exists() eller en native implementering av access() från libc. Dessutom kan man försöka köra su --version eller su -c id och kontrollera utgångskoden.

Sökning efter root-hanterare

Typiska appar för hantering av root-åtkomst: Superuser, SuperSU, Magisk Manager, KingRoot. Deras förekomst kontrolleras via PackageManager.getPackageInfo() eller läsning av katalogen /data/app/. Paket att kontrollera: com.topjohnwu.magisk, eu.chainfire.supersu, com.noshufou.android.su, com.thirdparty.superuser, com.koushikdutta.superuser, com.zacharee1.systemuituner.

Kontroll av systemegenskaper

Android lagrar information om systemets tillstånd i systemegenskaper som är tillgängliga via System.getProperty och Build.TAGS. Om värdet på Build.TAGS innehåller test-keys istället för release-keys — indikerar detta anpassad firmware, ofta med root-åtkomst. Dessutom kontrolleras ro.build.tags, ro.debuggable och ro.secure genom att läsa /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) {
                // paketet hittades inte
            }
        }
        return false;
    }
}

Dynamiska kontrollmetoder

Dynamiska metoder utförs under appens drift och analyserar exekveringsmiljön. Till skillnad från statiska metoder kan de upptäcka root som göms via Magisk Hide eller Zygisk, eftersom de kontrollerar systemets beteende, inte bara filstrukturen.

Kontroll av monteringspunkter

Vid root-åtkomst monteras vissa systempartitionerna med flaggan rw (read-write) istället för ro (read-only). Appen läser /proc/mounts och kontrollerar om /system är monterat som ro. Om /system är monterat som rw — är detta ett tecken på ett modifierat system. Dessutom kontrolleras förekomsten av montering av /su via Magisk.

Test av säkert läge

Android Safe Mode inaktiverar tredjepartsappar, inklusive root-hanterare. En korrekt implementering av Root Detection kan kontrollera om enheten fungerar i säkert läge. Om appen upptäcker att root-hanterare inte är synliga, men su-binären finns — är detta ett tecken på Magisk Hide.

Kontroll av kommandokörning

Försök att köra su -c id via ProcessBuilder eller Runtime.exec — ett direkt test av root-åtkomst. Magisk kan dock fånga upp detta anrop. Ett mer tillförlitligt alternativ — kontroll via native kod: öppna /proc/1/limits eller /proc/self/maps och analysera UID för aktiva processer. Om appen kan få UID 0 eller läsa filer som endast är tillgängliga för root — är enheten komprometterad.

public boolean checkRootDynamically() {
    // Kontroll av kompileringsflaggor
    String buildTags = Build.TAGS;
    if (buildTags != null && buildTags.contains("test-keys")) {
        return true;
    }

    // Kontroll av montering av /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) {
        // fel vid läsning av mount
    }

    return false;
}

Native implementation av Root Detection i C++

Root Detection implementerad i Java kringgås enkelt via Xposed-moduler eller Frida, som fångar upp Java-metoder och förfalskar returvärden. Native implementation i C++ via JNI är betydligt mer motståndskraftig: dynamiska analysverktyg som arbetar på Java-nivå ser inte de nativen libc-anropen som stat, access, popen och 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;
}

Native kontroll använder inte Java API, vilket gör den osynlig för kringgåendeverktyg som arbetar på Dalvik/ART-nivå. För extra skydd rekommenderas att lagra konstanter (väglista) inte i read-only-sektionen, utan att beräkna dem via enkla reversibla funktioner. Stat-anropet från libc vänder sig direkt till Linux-kärnan, förbi Java-wrapper och kan inte fångas upp via Xposed.

Metoder för att kringgå Root Detection

Säkerhetsutvecklare måste förstå befintliga kringgåendemetoder för att bygga ett motståndskraftigt detektionssystem. Varje kringgåendemetod kräver en motåtgärd på lämplig nivå.

Kringgående via Magisk Hide och Zygisk

Magisk — det mest populära rootverktyget på Android 9–14. Magisk Hide döljer förekomsten av su från /proc och förfalskar resultaten av vägkontroller. Magisk arbetar på kärnnivå och fångar upp stat() och access() innan appen ser dem. Motåtgärd: kontroll av förekomsten av själva Magisk via /sbin/.magisk eller kontroll via läsning av egna maps — Magisk bäddar in sitt bibliotek i varje process.

Kringgående via Frida

Frida — ett dynamiskt instrumenteringsverktyg som kan fånga upp nativen funktioner via Ptrace eller Dobby. Frida ersätter returvärdet för varje kontroll och förfalskar resultatet av stat till ENOENT. Motåtgärd: kontroll av integriteten hos nativen funktioner genom beräkning av kontrollsumma för instruktioner i minnet och detektering av Frida via analys av /proc/self/maps för förekomst av frida-agent.so eller frida-helper.

Kringgående via APK-patch

Root Detection implementerad i Java tas bort på 2–3 minuter: APK packas upp via apktool, i smali-koden ändras metodens returvärde till false, APK återmonteras och signeras. Motåtgärd: flytta kritisk logik till native kod och kontrollera appens digitala signatur i runtime via Signature API eller jämför APK-hash med referensen på servern.

Rekommendationer för tillförlitligt skydd

Effektiv Root Detection bygger på en flerskiktad arkitektur. Ingen enskild metod ger tillräckligt skydd. Kombinationen av statiska och dynamiska kontroller, native kod och serververifiering ger maximal motståndskraft.

Serververifiering

Förlita dig inte enbart på kontroll på klientsidan. Skicka resultaten från Root Detection tillsammans med en engångssessionstoken till servern. Servern fattar beslut om blockering eller begränsning av funktionalitet. Detta förhindrar attacker på API-nivå, där klientappen kan modifieras men servern förblir den betrodda parten.

Obfuskering av kontrollkod

Root Detection-koden måste obfuskeras. Om angriparen ser i jadx en tydlig sekvens av su-vägkontroller — tar kringgående minuter. Använd ProGuard eller DexGuard för att förvirra kontrollflödet och kryptera strängar. Obfuskering ökar analystiden för säkerhetskoden från några minuter till flera timmar.

Regelbunden uppdatering av signaturer

Listan över kontrollerade vägar, paket och indikatorer måste uppdateras med varje app-release. Nya root- och kringgåendeverktyg dyker upp månatligen. En statisk lista som inte ändrats på ett år upptäcker inte moderna metoder. Det rekommenderas att ladda aktuella signaturer från servern vid appstart innan kontroller utförs.