Complications

Root Detection in Android device

Check for Test-Keys

Test-Keys has to do with how the kernel is signed when it is compiled. By default, stock Android ROMs from Google are built with release-keys tags. Test-Keys means it is signed with a custom key generated by a third-party developer. Specifically, it will check in build properties(“android.os.Build.TAGS”) for test-keys.

private boolean detectTestKeys() {
    String buildTags = android.os.Build.TAGS;
    return buildTags != null && buildTags.contains("test-keys");
}

Check for “su” binary:

Su binary check is to identify the superuser in the device. This binary is installed when you try to root your phone using apps like kinguser or via fastboot in Android. These files are necessary so that one can root their phone and become the superuser. The existence of this binary can be checked from the following paths.

private boolean checkForSuBinary() {
    return checkForBinary("su"); // function is available below
}

Check for “busybox” binary

If a device has been rooted, more often than not Busybox has been installed as well. Busybox is a binary that provides many common Linux commands. Running busybox is a good indication that a device has been rooted.

private boolean checkForBusyBoxBinary() {
   return checkForBinary("busybox");//function is available below
}

Check for SuExists

Different file system check for the su binary.

private boolean checkSuExists() {
    Process process = null;
    try {
        process = Runtime.getRuntime().exec(new String[]
                {"/system /xbin/which", "su"});
        BufferedReader in = new BufferedReader(
                new InputStreamReader(process.getInputStream()));
        String line = in.readLine();
        process.destroy();
        return line != null;
    } catch (Exception e) {
        if (process != null) {
            process.destroy();
        }
        return false;
    }
}

The following paths, Su and busybox binaries are often looked for on rooted devices.

private String[] binaryPaths= {
        "/data/local/",
        "/data/local/bin/",
        "/data/local/xbin/",
        "/sbin/",
        "/su/bin/",
        "/system/bin/",
        "/system/bin/.ext/",
        "/system/bin/failsafe/",
        "/system/sd/xbin/",
        "/system/usr/we-need-root/",
        "/system/xbin/",
        "/system/app/Superuser.apk",
        "/cache",
        "/data",
        "/dev"
};

Emulator Detection

First you need to check the the pre-decompiled source code and check for functions that contains strings like “generic | emulator | google_sdk” and functions like “isEmulator | emulatorDetection…etc” … use your searching skills and read the code well.

SSL Pinning

Is a technique that we use in the client side to avoid man-in-the-middle attack by validating the server certificates again even after SSL handshaking. The developers embed (or pin) a list of trustful certificates to the client application during development, and use them to compare against the server certificates during runtime. If there is a mismatch between the server and the local copy of certificates, the connection will simply be disrupted, and no further user data will be even sent to that server. This enforcement ensures that the user devices are communicating only to the dedicated trustful servers.

After you have taken in the illustration above, note that certificate pinning attempts to ensure that the client is not exchanging messages with any other server than the one they hold a public key for. Therefore, the client is not exposed to attacks where a rogue Certificate Authority (CA) validates the authenticity of a malicious host serving content with a sham certificate.