Root Detection sa Mga Mobile App — esensya, mga paraan ng pagtuklas, at prinsipyo ng paggana

Ano ang Root Detection?

Root Detection — mekanismo ng software na tumutukoy sa pagkakaroon ng root access sa isang Android device. Ang root access ay nagbibigay ng buong kontrol sa operating system, na nagpapahintulot sa mga app at script na magsagawa ng mga command na may UID 0. Sa isang naka-root na device, nawawala ang isolasyon ng app (Android Sandbox), na ginagawang posible ang pagharang ng input mula sa keyboard, pagbabasa ng SQLite database ng iba pang app, pag-inject ng code sa mga proseso, at pagpapalit ng SSL certificates sa pinagkakatiwalaang imbakan.

Para sa mga financial at corporate app, ang pagtakbo sa isang naka-root na device ay kumakatawan sa isang hindi katanggap-tanggap na panganib: ang attacker ay nakakakuha ng access sa mga token, session key, at personal na data. Ang mga regulator, kabilang ang PCI Security Standards Council, ay nangangailangan ng mga payment app na makita at tumugon sa root access. Bilang tugon, isinasama ng mga Android developer ang Root Detection bilang bahagi ng proactive na diskarte sa seguridad.

Mayroong dalawang diskarte sa pagtuklas: static, na sinusuri ang file system at mga naka-install na package, at dynamic, na nagsasagawa ng mga pagsusuri sa runtime. Ang pinagsamang diskarte ay itinuturing na pinaka-maaasahan dahil sinasaklaw nito ang iba't ibang vector ng paglampas. Ayon sa pananaliksik ng NowSecure (2025), 76% ng mga banking app sa top 100 ng Google Play ay naglalaman ng ilang anyo ng Root Detection.

Mga static na paraan ng pagtuklas ng root

Ang mga static na pamamaraan ay isinasagawa sa pagsisimula ng app at sinusuri ang mga palatandaan ng root access na naiwan ng mga root tool sa file system. Ang mga pamamaraang ito ay hindi nangangailangan ng pagpapatupad ng mga privileged command at gumagana sa konteksto ng isang ordinaryong app.

Pagsusuri ng pagkakaroon ng su binary

Ang pangunahing palatandaan ng root access — ang pagkakaroon ng executable file su sa mga karaniwang path: /system/bin/su, /system/xbin/su, /sbin/su, /su/bin/su. Sinusuri ng app ang pagkakaroon ng file sa pamamagitan ng File.exists() o native implementation ng access() mula sa libc. Bukod pa rito, maaaring subukang patakbuhin ang su --version o su -c id at suriin ang exit code.

Paghahanap ng mga root manager

Mga tipikal na app para sa pamamahala ng root access: Superuser, SuperSU, Magisk Manager, KingRoot. Ang kanilang presensya ay sinusuri sa pamamagitan ng PackageManager.getPackageInfo() o pagbabasa ng /data/app/ directory. Mga package na susuriin: com.topjohnwu.magisk, eu.chainfire.supersu, com.noshufou.android.su, com.thirdparty.superuser, com.koushikdutta.superuser, com.zacharee1.systemuituner.

Pagsusuri ng mga system property

Ang Android ay nag-iimbak ng impormasyon tungkol sa estado ng system sa mga system property na accessible sa pamamagitan ng System.getProperty at Build.TAGS. Kung ang halaga ng Build.TAGS ay naglalaman ng test-keys sa halip na release-keys — ito ay nagpapahiwatig ng custom na firmware, kadalasang may root access. Bukod pa rito, sinusuri ang ro.build.tags, ro.debuggable, at ro.secure sa pamamagitan ng pagbabasa ng /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) {
                // hindi natagpuan ang pakete
            }
        }
        return false;
    }
}

Mga dynamic na paraan ng pagsusuri

Ang mga dynamic na pamamaraan ay isinasagawa habang tumatakbo ang app at sinusuri ang kapaligiran ng pagpapatupad. Hindi tulad ng mga static na pamamaraan, maaari nilang makita ang root na nakatago sa pamamagitan ng Magisk Hide o Zygisk, dahil sinusuri nila ang gawi ng system, hindi lamang ang istraktura ng file.

Pagsusuri ng mga mount point

Sa root access, ang ilang mga partisyon ng system ay naka-mount na may flag na rw (read-write) sa halip na ro (read-only). Binabasa ng app ang /proc/mounts at sinusuri kung ang /system ay naka-mount bilang ro. Kung ang /system ay naka-mount bilang rw — ito ay palatandaan ng isang binagong system. Bukod pa rito, sinusuri ang pagkakaroon ng pag-mount ng /su sa pamamagitan ng Magisk.

Pagsubok ng safe mode

Ang Android Safe Mode ay nagdi-disable ng mga third-party na app, kabilang ang mga root manager. Ang tamang implementation ng Root Detection ay maaaring suriin kung ang device ay tumatakbo sa safe mode. Kung natukoy ng app na hindi nakikita ang mga root manager, ngunit umiiral ang su binary — ito ay palatandaan ng Magisk Hide.

Pagsusuri ng pagpapatupad ng command

Pagtatangka na patakbuhin ang su -c id sa pamamagitan ng ProcessBuilder o Runtime.exec — isang direktang pagsubok ng root access. Gayunpaman, maaaring harangin ng Magisk ang tawag na ito. Isang mas maaasahang opsyon — pagsusuri sa pamamagitan ng native code: pagbubukas ng /proc/1/limits o /proc/self/maps at pagsusuri ng UID ng mga tumatakbong proseso. Kung ang app ay maaaring makakuha ng UID 0 o magbasa ng mga file na accessible lamang sa root — ang device ay nakompromiso.

public boolean checkRootDynamically() {
    // Pagsusuri ng mga flag ng compilation
    String buildTags = Build.TAGS;
    if (buildTags != null && buildTags.contains("test-keys")) {
        return true;
    }

    // Pagsusuri ng pag-mount ng /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) {
        // error sa pagbabasa ng mount
    }

    return false;
}

Native implementation ng Root Detection sa C++

Ang Root Detection na ipinatupad sa Java ay madaling nalalampasan sa pamamagitan ng Xposed modules o Frida, na humaharang sa mga Java method at nagpapalit ng mga return value. Ang native implementation sa C++ sa pamamagitan ng JNI ay mas matibay: ang mga dynamic analysis tool na gumagana sa antas ng Java ay hindi nakikita ang mga native na tawag ng libc tulad ng stat, access, popen, at 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;
}

Ang native na pagsusuri ay hindi gumagamit ng Java API, ginagawa itong hindi nakikita ng mga tool sa paglampas na gumagana sa antas ng Dalvik/ART. Para sa karagdagang proteksyon, inirerekomenda na mag-imbak ng mga constant (listahan ng mga path) hindi sa read-only na seksyon, kundi kalkulahin ang mga ito sa pamamagitan ng mga simpleng reversible function. Ang tawag na stat mula sa libc ay direktang pumupunta sa Linux kernel, lumalampas sa Java wrappers, at hindi maaaring harangin sa pamamagitan ng Xposed.

Mga paraan ng paglampas sa Root Detection

Kailangang maunawaan ng mga developer ng seguridad ang mga umiiral na paraan ng paglampas upang makabuo ng isang matibay na sistema ng pagtuklas. Ang bawat paraan ng paglampas ay nangangailangan ng countermeasure sa naaangkop na antas.

Paglampas sa pamamagitan ng Magisk Hide at Zygisk

Magisk — ang pinakasikat na root tool sa Android 9–14. Itinatago ng Magisk Hide ang presensya ng su mula sa /proc at pinapalitan ang mga resulta ng pagsusuri ng path. Ang Magisk ay gumagana sa antas ng kernel at humaharang sa stat() at access() bago makita ng app. Countermeasure: pagsusuri ng pagkakaroon ng Magisk mismo sa pamamagitan ng /sbin/.magisk o pagsusuri sa pamamagitan ng pagbabasa ng sariling maps — ini-embed ng Magisk ang library nito sa bawat proseso.

Paglampas sa pamamagitan ng Frida

Frida — isang dynamic instrumentation tool na maaaring humarang ng native function sa pamamagitan ng Ptrace o Dobby. Pinapalitan ng Frida ang return value ng bawat pagsusuri, pinapalitan ang resulta ng stat ng ENOENT. Countermeasure: pagsusuri ng integridad ng native function sa pamamagitan ng pagkalkula ng checksum ng mga instruction sa memory at pagtuklas ng Frida sa pamamagitan ng pagsusuri ng /proc/self/maps para sa pagkakaroon ng frida-agent.so o frida-helper.

Paglampas sa pamamagitan ng APK patch

Ang Root Detection na ipinatupad sa Java ay tinatanggal sa loob ng 2–3 minuto: ang APK ay binubuksan sa pamamagitan ng apktool, sa smali code ang return value ng method ay binago sa false, ang APK ay muling binuo at pinipirmahan. Countermeasure: paglipat ng kritikal na lohika sa native code at pagsusuri ng digital signature ng app sa runtime sa pamamagitan ng Signature API o paghahambing ng hash ng APK sa reference sa server.

Mga rekomendasyon para sa maaasahang proteksyon

Ang epektibong Root Detection ay binuo sa multi-layered na arkitektura. Walang iisang pamamaraan ang nagbibigay ng sapat na antas ng proteksyon. Ang kombinasyon ng static at dynamic na pagsusuri, native code, at server verification ay nagbibigay ng maximum na tibay.

Pagpapatunay ng server

Huwag umasa lamang sa client-side na pagsusuri. Ipadala ang mga resulta ng Root Detection kasama ng one-time session token sa server. Ang server ang gumagawa ng desisyon tungkol sa pagharang o paglilimita ng functionality. Pinipigilan nito ang mga pag-atake sa antas ng API, kung saan ang client app ay maaaring mabago, ngunit ang server ay nananatiling pinagkakatiwalaang partido.

Obfuscation ng code ng pagsusuri

Ang Root Detection code ay dapat na obfuscated. Kung ang attacker ay makakita sa jadx ng malinaw na pagkakasunod-sunod ng pagsusuri ng mga su path — ang paglampas ay tatagal ng ilang minuto. Gamitin ang ProGuard o DexGuard para guluhin ang control flow at i-encrypt ang mga string. Ang obfuscation ay nagpapataas ng oras ng pagsusuri ng security code mula sa ilang minuto hanggang ilang oras.

Regular na pag-update ng mga signature

Ang listahan ng mga path, package, at indicator na sinusuri ay dapat na i-update sa bawat release ng app. Ang mga bagong root at bypass tool ay lumalabas buwan-buwan. Ang isang static na listahan na hindi nagbago sa loob ng isang taon ay hindi nakakakita ng mga modernong pamamaraan. Inirerekomenda na mag-load ng kasalukuyang mga signature mula sa server sa pagsisimula ng app bago magsagawa ng mga pagsusuri.